Comments 54
Извините, а для кого эта статья?
Классно, но, ваши проблемы с esb от того, что все хотят быть "архитекторами", а думать и за "дисциплиной" следить некому.
И с этой точки зрения "а давайте микросервисы теперь!" — ровно тоже самое что "а давайте все перепишем!", но проблемы ваши не решит.
Вы точно так же "намесите" и с микросервисами и придёте ровно к тем же проблемам (правда это случится не сразу и скорее всего ура-реформаторы успеют покинуть проект с повышением)
Полностью согласен.
Перегруженная «логикой» шина и ETL функциями — не повод уходить из SOA в MSA.
Перегруженные логикой бэки — аналогично, зачем ж вы изначально туда её в таком количестве погрузили?
MSA вообще достаточно спорная тема. Всем известен предмет, преимущества… Но не смысл.
Конечно (тут спору нет) проще делать с нуля и красиво, чем исправлять. Но правильнее ли?
Разделяем шины на Транспорт с ограниченным ETL (например, по объёму и количеству потоков) и BPM часть {тут если говорить именно о SOA и работе с ESB} и уже видим снижение нагрузки и управляемость.
Полный регресс — хорошо, да. А как насчёт автотестов? Они решат и эту проблему.
ИМХО, для каждой из описанных проблем есть решение. элегантное и красивое.
Провести полную перестройку ландшафта под этим флагом можно. Но нужно ли?
вопрос необходимости.
Перегруженная «логикой» шина и ETL функциями — не повод уходить из SOA в MSA.
Перегруженные логикой бэки — аналогично, зачем ж вы изначально туда её в таком количестве погрузили?
MSA вообще достаточно спорная тема. Всем известен предмет, преимущества… Но не смысл.
Конечно (тут спору нет) проще делать с нуля и красиво, чем исправлять. Но правильнее ли?
Разделяем шины на Транспорт с ограниченным ETL (например, по объёму и количеству потоков) и BPM часть {тут если говорить именно о SOA и работе с ESB} и уже видим снижение нагрузки и управляемость.
Полный регресс — хорошо, да. А как насчёт автотестов? Они решат и эту проблему.
ИМХО, для каждой из описанных проблем есть решение. элегантное и красивое.
Провести полную перестройку ландшафта под этим флагом можно. Но нужно ли?
вопрос необходимости.
Перегруженные логикой бэки — аналогично, зачем ж вы изначально туда её в таком количестве погрузили?
Сам работаю в банке и не раз задавался данным вопросом, даже задавал его руководителям различных профильных департаментов… Если усреднить ответ, то он звучал: «Так исторически сложилось.»
Стоп, давайте-ка разберёмся.
В данном контексте «бэк» — это бэк-офисная система. И логика там должна быть и есть — это как «отче наш». Или предлагается РКО, РЦ, ГК делать на «хипстерских» механизмах? :)
Если же вы имеете в виду, что бизнес-логику запихнули в шину (ESB), то это действительно исторически сложилось, потому что даже в 15-м году ещё маститые гуру советовали её в ESB заносить. На тот момент ESB никто как только транспорт не рассматривал. Она потому и называлась «Сервисная шина предприятия», что выполняла:
— транспортную функцию;
— оркестровку сервисов;
— хореографию сервисов;
— у многих (даже OpenSource) ESB-решений были встроенные BPM-компоненты;
То есть ESB подавалась как «серебрянная пуля», решающая все проблемы связности остальных инфраструктурных компонент и систем.
Это чуть позже выяснилось, что:
— в таком режиме она ресурсы жрёт как не в себя;
— не сильно много специалистов умеют ESB готовить;
— специфичные фреймворки.
— и т.п.
Столкнувшись с этим начали искать выходы. Одним из которых и является МСА.
Главное не делать из МСА той же самой «серебрянной пули» и всё будет нормально.
Каждому овощу — своё место.
Чем мне и понравилось решение ребят из РК — чувствуется сбалансированный подход.
В данном контексте «бэк» — это бэк-офисная система. И логика там должна быть и есть — это как «отче наш». Или предлагается РКО, РЦ, ГК делать на «хипстерских» механизмах? :)
Если же вы имеете в виду, что бизнес-логику запихнули в шину (ESB), то это действительно исторически сложилось, потому что даже в 15-м году ещё маститые гуру советовали её в ESB заносить. На тот момент ESB никто как только транспорт не рассматривал. Она потому и называлась «Сервисная шина предприятия», что выполняла:
— транспортную функцию;
— оркестровку сервисов;
— хореографию сервисов;
— у многих (даже OpenSource) ESB-решений были встроенные BPM-компоненты;
То есть ESB подавалась как «серебрянная пуля», решающая все проблемы связности остальных инфраструктурных компонент и систем.
Это чуть позже выяснилось, что:
— в таком режиме она ресурсы жрёт как не в себя;
— не сильно много специалистов умеют ESB готовить;
— специфичные фреймворки.
— и т.п.
Столкнувшись с этим начали искать выходы. Одним из которых и является МСА.
Главное не делать из МСА той же самой «серебрянной пули» и всё будет нормально.
Каждому овощу — своё место.
Чем мне и понравилось решение ребят из РК — чувствуется сбалансированный подход.
Вы точно так же «намесите» и с микросервисами и придёте ровно к тем же проблемамСкорее всего, проблемы даже усугубятся.
По поводу обновления доработок сервисов SOA, согласен. Порой требуется регрессить все процессы. На сколько я знаю, шина на ренессансе под IBM websphere. У нас на проекте оракл soa suite. анализ транзакцтй все же проще. Но с микросервисами на сколько я знаю, возникают сложности анализа транзакций.
Хорошая статья, спасибо.
На мой взгляд грамотно продуманная стратегия и хороший вариант TO BE. Безусловно есть ряд спорных, на мой взгляд, моментов.
Например:
Как в этом случае будет осуществляться сопровождение продуктов в АБС? То есть да — TTM по продукту Вы минимизируете, будете их довольно быстро выбрасывать на рынок. А дальше? Бэк не начнёт плакать горючими слезами на таких раскладах? :)
Они же неповоротливые, и им на взятие выпущенного за неделю и (предположим) хорошо и широко проданного продукта на сопровождение к примеру в Core АБС может потребоваться квартал, а то и полгода :)
Вот это:
— очень хорошо. Но вижу опять проблемы с бэком, если только не подвязывать к каждому продукту свою АБС :)
На мой взгляд грамотно продуманная стратегия и хороший вариант TO BE. Безусловно есть ряд спорных, на мой взгляд, моментов.
Например:
Что меняется? Изначально на уровне бэк-офиса любая АБС имеет бизнес-логику и источник данных. Мы стремимся к тому, чтобы бэк-офисные системы свелись исключительно к хранению и «ядерному» функционалу, где изменения были бы редкими. А продуктовая логика ушла на уровень микросервисов, позволяющих гибко менять и создавать продукты, разделенные по доменам.
Как в этом случае будет осуществляться сопровождение продуктов в АБС? То есть да — TTM по продукту Вы минимизируете, будете их довольно быстро выбрасывать на рынок. А дальше? Бэк не начнёт плакать горючими слезами на таких раскладах? :)
Они же неповоротливые, и им на взятие выпущенного за неделю и (предположим) хорошо и широко проданного продукта на сопровождение к примеру в Core АБС может потребоваться квартал, а то и полгода :)
Вот это:
Домены соответствуют продуктам банка. Это позволяет отойти от классического разделения на фронт, бэк и интеграцию, прийти к единству с продуктовыми командами.
— очень хорошо. Но вижу опять проблемы с бэком, если только не подвязывать к каждому продукту свою АБС :)
А это всё решается легко путём внедрения продуктового каталога.
Вот прямо так легко и прямо решается? :)
Вынужден не согласиться, так как наблюдал как минимум три СУПП, которые не могли решить данный вопрос никоим образом.
Вариант продуктового домена — казалось бы ведёт к решению данной темы. Но:
1. Резко увеличивает ТТМ.
2. Вносит рассогласованность в изменения, вносимые в core АБС.
3. Требует наличия арбитража по междоменным изменениям.
И продуктовый каталог тут почти никаким боком, если только перечень продуктов банка показать :)
Вынужден не согласиться, так как наблюдал как минимум три СУПП, которые не могли решить данный вопрос никоим образом.
Вариант продуктового домена — казалось бы ведёт к решению данной темы. Но:
1. Резко увеличивает ТТМ.
2. Вносит рассогласованность в изменения, вносимые в core АБС.
3. Требует наличия арбитража по междоменным изменениям.
И продуктовый каталог тут почти никаким боком, если только перечень продуктов банка показать :)
Не совсем так. Но всю логику раскрывать не буду, нужен ещё 1 сервис «сбоку» :) и ТТМ уменьшится, не будет рассинхрона по логике обработки и прочему.
Не будем раскрывать все тайны.
Да и увы, идеальной архитектуры не существует. Проблемы всегда будут. И для их решения всегда будут нужны хорошие умы.
Алексею — спасибо за статью :)
Не будем раскрывать все тайны.
Да и увы, идеальной архитектуры не существует. Проблемы всегда будут. И для их решения всегда будут нужны хорошие умы.
Алексею — спасибо за статью :)
Тайны никогда не стоит раскрывать :)
Я там чуть про другое писал — дело не в ОБРАБОТКЕ, это как раз решаемо.
Дело в организации.
Детализирую:
1. Проактивный бизнес придумал новый кредитный продукт. «Просто бомба! Нужно завтра на рынок!»
2. Хипстеры :) на продающем фронте его реализовали вот на раз два (на самом деле за неделю, но это не важно :)).
3. Бэк-энд тоже поднапрягся, за пару недель напилил сервисов, реализующих логику и конвейер.
4. И вот тут мы приходим в core АБС (пусть даже мы умные и красивые, и пришли прямо в п.1), а они нам — «парни, да вы что? нам чтобы реализовать обслуживание такого кредита как вы нарисовали нужно полгода! да и ресурсов у нас сейчас нет, вон МФСО-9 на носу». И всё — скандал в благородном семействе :)
P.S. Присоединяюсь к благодарности в адрес Алексея.
Я там чуть про другое писал — дело не в ОБРАБОТКЕ, это как раз решаемо.
Дело в организации.
Детализирую:
1. Проактивный бизнес придумал новый кредитный продукт. «Просто бомба! Нужно завтра на рынок!»
2. Хипстеры :) на продающем фронте его реализовали вот на раз два (на самом деле за неделю, но это не важно :)).
3. Бэк-энд тоже поднапрягся, за пару недель напилил сервисов, реализующих логику и конвейер.
4. И вот тут мы приходим в core АБС (пусть даже мы умные и красивые, и пришли прямо в п.1), а они нам — «парни, да вы что? нам чтобы реализовать обслуживание такого кредита как вы нарисовали нужно полгода! да и ресурсов у нас сейчас нет, вон МФСО-9 на носу». И всё — скандал в благородном семействе :)
P.S. Присоединяюсь к благодарности в адрес Алексея.
Ну тут видишь ещё что — agile рулит(да, но с корректировками), DevOps как пилоты… и классический waterfall как фабрика.
замес :) лишних «артефактов» и неиспользуемых микросервисов будет просто тьма.
+нужен будет эксперт по «всем версиям микросервиса НомерДва» (если мы говорим о модели переиспользования с корректировками). А уйди он куда (ну схантили эксперта) и всё, кирдык. Классический чёрный ящик.
замес :) лишних «артефактов» и неиспользуемых микросервисов будет просто тьма.
+нужен будет эксперт по «всем версиям микросервиса НомерДва» (если мы говорим о модели переиспользования с корректировками). А уйди он куда (ну схантили эксперта) и всё, кирдык. Классический чёрный ящик.
Больше трэша! :)
Описанный процесс имеет отрицательную сходимость, а в разработку в части АБС agile не заходит от слова совсем.
Касаемо микросервисов — не всё так печально, ибо капитализм есть учёт и контроль. Так что если:
а) Архитектура всей системы контролируется из одной точки.
б) Выстроен процесс сохранения артефактов проектов и разработки.
в) В agile-командах есть пишущие архитекторы.
то не всё так смертельно. МСА может жить и будет жить лучше чем пакет из полтыщи сервисов на ESB. Которая однозначно становится узким местом в большинстве случаев.
Описанный процесс имеет отрицательную сходимость, а в разработку в части АБС agile не заходит от слова совсем.
Касаемо микросервисов — не всё так печально, ибо капитализм есть учёт и контроль. Так что если:
а) Архитектура всей системы контролируется из одной точки.
б) Выстроен процесс сохранения артефактов проектов и разработки.
в) В agile-командах есть пишущие архитекторы.
то не всё так смертельно. МСА может жить и будет жить лучше чем пакет из полтыщи сервисов на ESB. Которая однозначно становится узким местом в большинстве случаев.
Мы, надеюсь, оба понимаем что выполнение этих Если — трудоёмкий вопрос.
Ну и собстно если бы эти Если были в рамках создания текущей SOA модели, то многих проблем бы и не было. Наверное.
Ну и собстно если бы эти Если были в рамках создания текущей SOA модели, то многих проблем бы и не было. Наверное.
Легко только пивко после бани трескать да советы давать, как говорил мой хороший знакомый :)
Естественно, что выстраивание процесса управления изменениями в системах такого уровня это не прогулка по набережной :)
В модели SOA эти «Если» вряд-ли помогут, так как там всё очень по-своему и весьма своеобразно.
Всё-таки разработка под ESB намного ближе к разработке для АБС. Это полноценный конвейер, фабрика. С очередями, приоритетами, нехваткой ресурсов и сопутствующей нервотрёпкой. Даже если мы туда не запихнули бизнес-логику, то есть «от большого ума» не используем её как BPM.
И в этом случае бизнеса начинают стонать: «наше ИТ такое плохое, медленное, у них всё криво».
Следующий шаг: «мы вот тут нашли клёвых стартаперов, они нам занедораХа на php напилили клёвый продукт! Берите его на сопровождение!». У вменяемого CIO при таком заходе либо просыпается внутренний зверь, либо волосы встают дыбом в различных местах организма.
Но задача дать бизнесу короткий ТТМ — есть, наш CIO это понимает и поэтому начинает вытаскивать из ESB-спагетти то что можно и отдавать в те самые домены. Под чутким контролем ДИТ или как оно называется в РК. Не самое плохое решение, хочу заметить.
При этом решается вопрос с дефицитными специалистами под WS или иной какой дюжий энтерпрайс. Так как при соблюдении контракта взаимодействия, микросервисы можно делать хоть на питоне :)
Естественно, что выстраивание процесса управления изменениями в системах такого уровня это не прогулка по набережной :)
В модели SOA эти «Если» вряд-ли помогут, так как там всё очень по-своему и весьма своеобразно.
Всё-таки разработка под ESB намного ближе к разработке для АБС. Это полноценный конвейер, фабрика. С очередями, приоритетами, нехваткой ресурсов и сопутствующей нервотрёпкой. Даже если мы туда не запихнули бизнес-логику, то есть «от большого ума» не используем её как BPM.
И в этом случае бизнеса начинают стонать: «наше ИТ такое плохое, медленное, у них всё криво».
Следующий шаг: «мы вот тут нашли клёвых стартаперов, они нам занедораХа на php напилили клёвый продукт! Берите его на сопровождение!». У вменяемого CIO при таком заходе либо просыпается внутренний зверь, либо волосы встают дыбом в различных местах организма.
Но задача дать бизнесу короткий ТТМ — есть, наш CIO это понимает и поэтому начинает вытаскивать из ESB-спагетти то что можно и отдавать в те самые домены. Под чутким контролем ДИТ или как оно называется в РК. Не самое плохое решение, хочу заметить.
При этом решается вопрос с дефицитными специалистами под WS или иной какой дюжий энтерпрайс. Так как при соблюдении контракта взаимодействия, микросервисы можно делать хоть на питоне :)
Не существует идеальной технологии управления сложностью, в одних случаях надо логику переносить ближе к данным (в БД), в другом выносить на уровень пользовательского интерфейса. С шиной у Вас были одни проблемы (бутылочное горлышко), а с кучей микросервисов появятся другие (например дублирование алгоритмов). Посмотрите в человеческое тело — например сердечная мышца управляется нейронами, имплементированными прямо в мышцу, хотя по всем методичкам — субъект управления должен быть отделен от объекта, но тогда при ударе по голове человек бы умирал от гипоксии :)
Вот про логику на уровне пользовательского интерфейса — категорически не согласен. Нечего ей там делать.
Опять плюсик. Фронт это Фронт.
отделять мух от котлет — норм затея.
отделять мух от котлет — норм затея.
ERP-система, пользовательские контроли (поля по умолчанию, взаимосвязи ссылочных атрибутов) — что в DAX, что в 1C реализованы на формах, SAP не смотрел. Технически это проще сделать, так как при установки какой-нибудь галочки приходится открывать часть полей, другую часть скрывать, и обновлять лукап-списки. При запихивании в модель придется писать кучу интерфейсов.
Это всё решается SPA и грамотным бэк-эндом.
На интерфейсе может быть только простейшая валидация и исполнение контракта безопасности. Ну и «скрыть поля при установке галочки» (что в принципе относится к той же валидации). Это не логика, это просто модель поведения формы.
На интерфейсе может быть только простейшая валидация и исполнение контракта безопасности. Ну и «скрыть поля при установке галочки» (что в принципе относится к той же валидации). Это не логика, это просто модель поведения формы.
Добавляем ролевую модель доступа и вуаля элегантность.
Скорее не саму ролевую модель, а её отображение и исполнение.
Фронт должен в этом плане быть «простым как выстрел» :)
Да, он должен быть красивым, удобным, с максимальным юзабилити.
Но — с минимум логики, а лучше вообще без неё.
Ибо с точки зрения СИБ — недоверенный контур.
Фронт должен в этом плане быть «простым как выстрел» :)
Да, он должен быть красивым, удобным, с максимальным юзабилити.
Но — с минимум логики, а лучше вообще без неё.
Ибо с точки зрения СИБ — недоверенный контур.
Простой вопрос — где нужно проверять ключевание счетов по БИК — на фронте или в бэке (сервере приложений)?
Правильный ответ — и там, и там.
На фронте, что бы пользователь сразу видел ошибку.
В бэке, чтобы не доверять фронту.
Правильный ответ — и там, и там.
На фронте, что бы пользователь сразу видел ошибку.
В бэке, чтобы не доверять фронту.
Ну давайте углубимся в тему :)
Введённый на форме фронта счёт, на мой взгляд, не должен там же и проходить проверку на ключевание (хотя технически безусловно может), а должен передать (при смене фокуса формы или по иному событию) введённое значение в бэк, в единый сервис проверки ключа. Который должен естественно при этом быть максимально отзывчивым.
Таким образом мы убиваем следующих зайцев:
— уменьшаем сложность фронта (проверка на ключевание не такой уж простой алгоритм);
— имеем единый механизм проверки ключа счёта для всех компонент системы;
— упрощаем логику или даже совсем убираем с фронта не свойственную ему логику.
А вот простая валидация безусловно должна быть на фронте (проверка на число, разрядность, даты и т.п.)
«Я так думаю» (С) :)
Введённый на форме фронта счёт, на мой взгляд, не должен там же и проходить проверку на ключевание (хотя технически безусловно может), а должен передать (при смене фокуса формы или по иному событию) введённое значение в бэк, в единый сервис проверки ключа. Который должен естественно при этом быть максимально отзывчивым.
Таким образом мы убиваем следующих зайцев:
— уменьшаем сложность фронта (проверка на ключевание не такой уж простой алгоритм);
— имеем единый механизм проверки ключа счёта для всех компонент системы;
— упрощаем логику или даже совсем убираем с фронта не свойственную ему логику.
А вот простая валидация безусловно должна быть на фронте (проверка на число, разрядность, даты и т.п.)
«Я так думаю» (С) :)
Во-первых, очевидно, что тем самым вы грузите бэк логикой интерфейса.
Во-вторых, даже проверив при смене фокуса формы, эту же проверку придется выполнять бэку при сохранении всего документа.
В-третьих, простую валидацию (проверка на число, разрядность, даты и т.п.) в силу предыдущего пункта, также придется выполнять на бэке.
Во-вторых, даже проверив при смене фокуса формы, эту же проверку придется выполнять бэку при сохранении всего документа.
В-третьих, простую валидацию (проверка на число, разрядность, даты и т.п.) в силу предыдущего пункта, также придется выполнять на бэке.
Во-первых, очевидно, что тем самым вы грузите бэк логикой интерфейса.
Не уверен, что именно так. Проверка введённых значений на соответствие логическим критериям, а не формальным — это занятие для бэка. Пример:
— проверка что в форму для числа введено число, а не срока — это чистый фронт;
— проверка по КЛАДР -однозначный бэк;
Как и ключевание. Зачем тиражировать единый алгоритм проверки в нескольких местах?
NB: Кстати, возможно мы с вами по разному трактуем понятие бэк-энда :). Например в случае node.js понятно что модуль проверки ключа может быть на нём. И дёргаться тоже и разных мест, включая и из бэк-сервисов.
Во-вторых, даже проверив при смене фокуса формы, эту же проверку придется выполнять бэку при сохранении всего документа.
Вопрос доверия. Если у нас есть чёткий контракт взаимодействия фронт — бэк, то бэк может доверять фронту в части как минимум того, что проведена первичная валидация. Обычно доверяют. Ну после того как наловят ошибок на тестировании :)
В-третьих, простую валидацию (проверка на число, разрядность, даты и т.п.) в силу предыдущего пункта, также придется выполнять на бэке.
Зачем?
Зачем?
Не верю фронту. Самое простое для злоумышленников — внедриться во фронт, или сэмулировать посылку запроса от фронта.
Как и ключевание. Зачем тиражировать единый алгоритм проверки в нескольких местах?
А почему нет? Он простой, не намного сложнее валидации даты.
Тут недоверие скорее не злоумышленникам, а разработчикам фронта — накосячат с типами передаваемых в вызов данных легко и непринуждённо :)
А если злоумышленники, то это приводит нас к тому, чтобы вообще убрать всю логику с фронта.
О чём я и говорил :)
P.S. Именно поэтому весь банковский СИБ сейчас стоит на ушах и требует при МСА взаимодействие только по https минимум.
А если злоумышленники, то это приводит нас к тому, чтобы вообще убрать всю логику с фронта.
О чём я и говорил :)
P.S. Именно поэтому весь банковский СИБ сейчас стоит на ушах и требует при МСА взаимодействие только по https минимум.
микросервисы полезны иногда, но переводить всё на микросервисы бред, разве что это поможет технически запретить делать некоторые действия которые программисты могут начать делать в монолитном куске, но тут сразу возникает куча других проблем, например перформанс, вот надо мне загрузить и переделать 100 мегов данных из базы, эти данные могут пройти через 3-4 микросервиса, а потом вернуться обратно, затраты по трафику, памяти и процессорному времени будут довольно большие да и медленно это всё, а если таких запросов много да и надо чтоб меньше секунды на обработку пошло, получается надо опять в одну кучу всё пихать, если только нельзя распаралелить, но всё равно надо железо мощнее да и писать это сложнее, вот и получается, что архитектура которая должна была упростить, всё усложняет в монолитном куске можно одни и теже куски передавать между разными участками кода и это будет моментально
не скажу что микросервисы плохи, они от слова «микро» то и должны работать с маленькими независимыми кусочками данных, с ними они идеально справляются и легко маштабировать
не скажу что микросервисы плохи, они от слова «микро» то и должны работать с маленькими независимыми кусочками данных, с ними они идеально справляются и легко маштабировать
UFO just landed and posted this here
UFO just landed and posted this here
Есть такая вещь как распределенная транзакция. Но это требует определеногго подхода и при проектировании хранилища. Идея в том, что сервис сохраняет текущее состояние, и ждет подтверждения от другого сервиса(кому было передано сообщение), что и он отработал успешно. Если такое подтверждение получено не будет то будет послано новое сообщение, которое отменяет предыдущее действие. Есть и специальные паттерны для выполнения таких транзакций, например Saga.
UFO just landed and posted this here
Если вы про организацию хранилища, то да, это EventSourcing. Тут правда надо понимать что хранилищем может быть и обычная SQL база, тут дело в самом подходе его организации. Насчет Saga паттерна можно почитать здесь.
UFO just landed and posted this here
Ну про СУБД вы немного заблуждаетесь, на малых объемах данные её возможно будет достаточно, но как только данные станут более существенны прибегают к созданию ещё одной подобной БД — OLAP. При этом проектируют её оптимизированной под специальные запросы.
Ну если вам надо дергать данные с разных хранилищ, то тут ничего не поделаешь, придется делать несколько запросов. Есть конечно вариант хранить все же данные в SQL, но тут необходимо придерживаться нескольких правил, не должно быть связей между таблицами по вторичному ключу у разных сервисов, а также они должны быть с разными схемами. Так можно будет легко разделить данный на две различный базы, если того потребуется.
Ну если вам надо дергать данные с разных хранилищ, то тут ничего не поделаешь, придется делать несколько запросов. Есть конечно вариант хранить все же данные в SQL, но тут необходимо придерживаться нескольких правил, не должно быть связей между таблицами по вторичному ключу у разных сервисов, а также они должны быть с разными схемами. Так можно будет легко разделить данный на две различный базы, если того потребуется.
UFO just landed and posted this here
Не совсем понял суть задачи. Если дело в организации хранения, то было бы неплохо организовать хранение всех менеджеров пучками(группами). Из моей практики, выглядит как довольно подходящий кейс для использования AzureTable. Там как раз можно организовать такое хранение. Плохо то, что там индекс как таковой, только один, и он распространяется на PartionKey, что в данном случае является регионом. А если у вас критерии организации данных постоянно меняются, то это точно не ваш случай. А и зачем вам два микросервиса? Один достает данные другой обрабатывает?
Скорее второе. Во всех сервисах, имеющих косвенную географическо- административную привязку (например, онлайн операции привязываются к месту первичной верификации) эта привязка явно дублируется, классическая денормализация. Но дублирование исключительно мастер-слейв, не мастер-мастер. Только один микросервис имеет право вносить изменения в конкретные данные, остальные их только потребляют, или запрашивая как клиент у сервера, или подписываясь на изменения.
UFO just landed and posted this here
Merrimac
Два вопроса:
1) Почему регрессионная проверка почти всей шины — это проблема? Это ведь можно по разному организовать.
2) Имхо, и вы можете меня поправить, здесь проблема может быть не столько в факте повторного использования, сколько в неудачной композиции.
Назовите, пожалуйста, топ-3 причины, по которым вы считаете, что гибкая разработка в системе SOA/ESB невозможна.
Акцент на повторном использовании сервисов. Это правило было краеугольным камнем SOA, но в итоге оно привело к тому, что все команды (фронт, бэк и интеграция) оказались настолько плотно связаны, что любое обновление интеграции требовало регрессионной проверки практически всей шины!
Два вопроса:
1) Почему регрессионная проверка почти всей шины — это проблема? Это ведь можно по разному организовать.
2) Имхо, и вы можете меня поправить, здесь проблема может быть не столько в факте повторного использования, сколько в неудачной композиции.
Поддержка гибкой разработки. Легкое подключение новых, вертикальных команд, выход на уровень «фабрики разработки», с автоматизацией рутинных задач.
Назовите, пожалуйста, топ-3 причины, по которым вы считаете, что гибкая разработка в системе SOA/ESB невозможна.
Скажите, а чем конкретно вы решили заменить BPM в связке микросервисов?
UFO just landed and posted this here
Sign up to leave a comment.
Как и зачем переходить от сервис-ориентированной архитектуры к микросервисам