Как стать автором
Обновить

Изоляция микросервисов по данным при миграции с монолита

Время на прочтение15 мин
Количество просмотров4.4K
Всего голосов 5: ↑4 и ↓1+3
Комментарии14

Комментарии 14

Разъясните пару вопросов для тех, кто не в теме)

У микросервисной архитектуры много плюсов, а самый большой её минус — высокая сложность разработки.

А как же сеть? Ведь чем больше микросервисов, тем чаще придется ходить в сеть для общения друг с другом, а поход в сеть это медленная операция. Разве не должно быть так, что от большого количества микросервисов скорость наоборот будет падать?

Транзакционные базы, как правило, масштабируются за счёт шардирования и партиционирования.

В случае с монолитом нельзя делать шардирование БД ?

Рост сетевого трафика конечно тоже надо учитывать. Но если все хорошо спроектировано, то он не должен стать критичным: трафик между сервером приложений и сервером БД тоже идет через сеть. Ну и если все микросервисы в одном ЦОДе , то проблема скорости сети как правило не очень критична. А вот если в процессе миграции на МСА идет переход на распределенную систему, то это в большей степени проблема миграции на распределенную систему, чем на МСА. Но все конечно надо считать.

Про шардирование:
Шардировать и партиционировать БД безусловно можно и при монолите. Вопрос в том, какая задача в итоге ставиться - горизонтально масштабировать монолит все равно не получиться. Но например чуть повысить производительность за счет уменьшения размера активных таблиц можно. Но при этом делать шардирование и партиционирование механически , не задумываясь о том, как будут проходить транзакции, не будет ли возникать конкуренция за данные, не будет ли падать производительность за счет работы с разными шардами и т.д. не получиться. Все равно нужно будет в какой-то части выполнить работы по изоляции по данным модулей или сервисов , даже, если архитектура останется монолитной

В тексте приведены некорректные примеры задач, требующих перехода на микросервисы.

  1. Всплеск продаж

  2. Видеонаблюдение

Первый пункт никак не побеждается разбиением системы на запчасти, взаимодействующие через HTTP или даже что-то доморощенное. Всегда останется задача проверки остатков по позициям, что предполагает одну БД и одну таблицу в ней.

Второй пункт - вообще никак не связан с микросервисами, поскольку это всего лишь распараллеливание обработки на абсолютно одинаковых обработчиках.

То есть с самого начала текста ставится ложная задача - перейдём на микросервисы лишь потому, что автору кажется, что микросервисы чем-то помогут, хотя на самом деле в приведённых задачах они не помогут ничем.

>Всегда останется задача проверки остатков по позициям, что предполагает одну БД и одну таблицу в ней.

На мой взгляд, очень спорное утверждение: обработка информации об остатках совершенно не требует одной базы и одной таблицы. Необходимость централизованной обработки информации об остатках не исключает возможность применения МСА - например можно выделить микросервис "Запас", при этом шардировать таблицу с остатками например по подразделениям (местам хранения) , а то и по типам товара или товарным группам. Таким образом мы сможем масшабировать этот микросервис и разделить нагрузку между экземплярами микросервиса и соответствующими ему шардами.

Если идти дальше, то можно разделить функции чтения и записи информации об остатках : изменять остатки в OLTP , затем через ETL выкладывать срезы остатков на витрины.

Но на самом деле эффект от МСА будет уже тогда, когда мы сможем собрать все бизнес-функции по работе с товарным запасом в одном микросервисе, отделив их от других функций, связанных с продуктами : управлением ассортиментом, управлением ценами и т.д., что в ERP реализуется на связанных таблицах БД монолита

В любом случае целесообразность таких шагов определяется в конкретном проекте

>Второй пункт - вообще никак не связан с микросервисами, поскольку это всего лишь распараллеливание обработки на абсолютно одинаковых обработчиках.

Ну все таки как-то связан :) Запуск многих экземпляров обработчиков, выделенных в отдельный микросервис, управляемых общим оркестровщиком - довольно распространеное решение для паралельной обработки. Хотя согласен, что есть и другие способы ее реализации.

>То есть с самого начала текста ставится ложная задача - перейдём на микросервисы

Не ставилась такая задача. Ну и вообще тема статьи - это не микросервисы vs монолит. Выработка критериев перехода и принятие решения по миграции на МСА - это вообще прерогатива архитекторов. Аналитик работает с уже принятым решением и обеспечивает этог переход

обработка информации об остатках совершенно не требует одной базы и одной таблицы

А потом сами пишете:

шардировать таблицу с остатками например по подразделениям

То есть вы не ушли от одной БД и одной таблицы.

на самом деле эффект от МСА будет уже тогда, когда мы сможем собрать все
бизнес-функции по работе с товарным запасом в одном микросервисе,
отделив их от других функций, связанных с продуктами

Это называется "разделить по компонентам". Компонент может быть связан с другими через HTTP, и может общаться напрямую внутри приложения. Наличие компонента никак не зависит от микросервисов - и с ними и без них он будет. А вот вносимая микросервисами задержка при коммуникации будет лишь в случае принятия концепции микросервисов. Добавьте к этому сложность оркестровки зоопарка сервисов.

Я в целом не против разделения ПО на компоненты, но считаю, что такое деление должно быть обосновано, особенно, если за ним следует уменьшение эффективности за счёт появления прямых и косвенных дополнительных задач, как мы видим в случае с микросервисами.

Возможно, вам было бы проще, если бы вы не приводили примеры микросервисов. Просто принято решение - перейти. А обоснование остаётся за скобками. Это паллиатив, конечно, но так вы избежите многих споров.

То есть вы не ушли от одной БД и одной таблицы.

Физически шарды логических таблиц - это как правило разные таблицы, даже если шардирование выполняется средствами СУБД. Просто СУБД "проксирует" запросы. При этом возможен вариант шардирования "снаружи", не системными средствами. Например в том случае, если мы строим распределенную структуру и у каждого подразделения или у каждой товарной группы своя БД. В этом случае можно говорить только об одной сущности, а не об одной таблице

Возможно, вам было бы проще, если бы вы не приводили примеры микросервисов. Просто принято решение - перейти.

Без обьяснения мотивов перехода на МСА на мой взгляд нельзя сформулировать требования к потоку моделирования.

А обоснование остаётся за скобками

Именно так

Физически шарды логических таблиц - это как правило разные таблицы

Не надо ходить этой скользкой дорожкой. Вы про микросервисы или про внутреннее устройство БД? Если про первое, то БД к ним никакого отношения не имеет, вместе с её внутренностями.

Важно получить обоснование - зачем вам понадобились микросервисы. Вы пока ни одного приемлемого варианта не озвучили, только переводите стрелки на БД и прочие рассуждения.

Ну либо всё же признайте - вам сказано "внедрить", а зачем - не важно. Ну вы и внедряете. Можно даже как-то политкорректно, вроде "у нас решили перейти на микросервисы, потому что очень умные люди очень много рассказывали про важность такого перехода".

Вы про микросервисы или про внутреннее устройство БД?

Я про спорность утверждения о единственности таблицы остатков

Ну либо всё же признайте - вам сказано "внедрить", а зачем - не важно.

Признаю : были сформулированы нефункциональные требования и архитектором , как лицом, отвечающим за НФТ, были приняты соответствующие архитектурные решения, которые он согласовал с заинтересованными лицами. Ни ход выполнения проекта, ни результат его выполнения не показал, что принятые архитектурные решения были неверными.

В принципе область эффективности МСА была четко обозначена еще Фаулером, и с того времени , IMHO, по этой теме мало кто чего добавил. Во всяком случае я что-то добавить не готов

Спасибо за признание. Не буду больше приставать :)

Согласен. Сейчас еще его плюсом явлется то, что его разработчик базируется в Гонконге. Но на момент этого проекта это было еще неактуально :)

Разве схемы бизнес-процессов (БП) привязаны к реализации, будь то монолит или MSA?
В БП акторы - бизнес-сущности, описывается бизнес-логика. Иначе это уже не БП, разве не так?
Приведённые в тексте примеры меня не убедили

Все зависит от целей и задач, которые вы ставите при описании БП. Можете описать на таком уровне абстракции, что не привязаны, а можете так , что привязаны. И что за система - ее архитектура может влиять на БП, а может быть чисто технической и не влиять.
Приведенный кейс актуален для систем организационного управления , где как правило архитектура и БП взаимосвязаны

Зарегистрируйтесь на Хабре, чтобы оставить комментарий