Комментарии 14
Разъясните пару вопросов для тех, кто не в теме)
У микросервисной архитектуры много плюсов, а самый большой её минус — высокая сложность разработки.
А как же сеть? Ведь чем больше микросервисов, тем чаще придется ходить в сеть для общения друг с другом, а поход в сеть это медленная операция. Разве не должно быть так, что от большого количества микросервисов скорость наоборот будет падать?
Транзакционные базы, как правило, масштабируются за счёт шардирования и партиционирования.
В случае с монолитом нельзя делать шардирование БД ?
Рост сетевого трафика конечно тоже надо учитывать. Но если все хорошо спроектировано, то он не должен стать критичным: трафик между сервером приложений и сервером БД тоже идет через сеть. Ну и если все микросервисы в одном ЦОДе , то проблема скорости сети как правило не очень критична. А вот если в процессе миграции на МСА идет переход на распределенную систему, то это в большей степени проблема миграции на распределенную систему, чем на МСА. Но все конечно надо считать.
Про шардирование:
Шардировать и партиционировать БД безусловно можно и при монолите. Вопрос в том, какая задача в итоге ставиться - горизонтально масштабировать монолит все равно не получиться. Но например чуть повысить производительность за счет уменьшения размера активных таблиц можно. Но при этом делать шардирование и партиционирование механически , не задумываясь о том, как будут проходить транзакции, не будет ли возникать конкуренция за данные, не будет ли падать производительность за счет работы с разными шардами и т.д. не получиться. Все равно нужно будет в какой-то части выполнить работы по изоляции по данным модулей или сервисов , даже, если архитектура останется монолитной
В тексте приведены некорректные примеры задач, требующих перехода на микросервисы.
Всплеск продаж
Видеонаблюдение
Первый пункт никак не побеждается разбиением системы на запчасти, взаимодействующие через HTTP или даже что-то доморощенное. Всегда останется задача проверки остатков по позициям, что предполагает одну БД и одну таблицу в ней.
Второй пункт - вообще никак не связан с микросервисами, поскольку это всего лишь распараллеливание обработки на абсолютно одинаковых обработчиках.
То есть с самого начала текста ставится ложная задача - перейдём на микросервисы лишь потому, что автору кажется, что микросервисы чем-то помогут, хотя на самом деле в приведённых задачах они не помогут ничем.
>Всегда останется задача проверки остатков по позициям, что предполагает одну БД и одну таблицу в ней.
На мой взгляд, очень спорное утверждение: обработка информации об остатках совершенно не требует одной базы и одной таблицы. Необходимость централизованной обработки информации об остатках не исключает возможность применения МСА - например можно выделить микросервис "Запас", при этом шардировать таблицу с остатками например по подразделениям (местам хранения) , а то и по типам товара или товарным группам. Таким образом мы сможем масшабировать этот микросервис и разделить нагрузку между экземплярами микросервиса и соответствующими ему шардами.
Если идти дальше, то можно разделить функции чтения и записи информации об остатках : изменять остатки в OLTP , затем через ETL выкладывать срезы остатков на витрины.
Но на самом деле эффект от МСА будет уже тогда, когда мы сможем собрать все бизнес-функции по работе с товарным запасом в одном микросервисе, отделив их от других функций, связанных с продуктами : управлением ассортиментом, управлением ценами и т.д., что в ERP реализуется на связанных таблицах БД монолита
В любом случае целесообразность таких шагов определяется в конкретном проекте
>Второй пункт - вообще никак не связан с микросервисами, поскольку это всего лишь распараллеливание обработки на абсолютно одинаковых обработчиках.
Ну все таки как-то связан :) Запуск многих экземпляров обработчиков, выделенных в отдельный микросервис, управляемых общим оркестровщиком - довольно распространеное решение для паралельной обработки. Хотя согласен, что есть и другие способы ее реализации.
>То есть с самого начала текста ставится ложная задача - перейдём на микросервисы
Не ставилась такая задача. Ну и вообще тема статьи - это не микросервисы vs монолит. Выработка критериев перехода и принятие решения по миграции на МСА - это вообще прерогатива архитекторов. Аналитик работает с уже принятым решением и обеспечивает этог переход
обработка информации об остатках совершенно не требует одной базы и одной таблицы
А потом сами пишете:
шардировать таблицу с остатками например по подразделениям
То есть вы не ушли от одной БД и одной таблицы.
на самом деле эффект от МСА будет уже тогда, когда мы сможем собрать все
бизнес-функции по работе с товарным запасом в одном микросервисе,
отделив их от других функций, связанных с продуктами
Это называется "разделить по компонентам". Компонент может быть связан с другими через HTTP, и может общаться напрямую внутри приложения. Наличие компонента никак не зависит от микросервисов - и с ними и без них он будет. А вот вносимая микросервисами задержка при коммуникации будет лишь в случае принятия концепции микросервисов. Добавьте к этому сложность оркестровки зоопарка сервисов.
Я в целом не против разделения ПО на компоненты, но считаю, что такое деление должно быть обосновано, особенно, если за ним следует уменьшение эффективности за счёт появления прямых и косвенных дополнительных задач, как мы видим в случае с микросервисами.
Возможно, вам было бы проще, если бы вы не приводили примеры микросервисов. Просто принято решение - перейти. А обоснование остаётся за скобками. Это паллиатив, конечно, но так вы избежите многих споров.
То есть вы не ушли от одной БД и одной таблицы.
Физически шарды логических таблиц - это как правило разные таблицы, даже если шардирование выполняется средствами СУБД. Просто СУБД "проксирует" запросы. При этом возможен вариант шардирования "снаружи", не системными средствами. Например в том случае, если мы строим распределенную структуру и у каждого подразделения или у каждой товарной группы своя БД. В этом случае можно говорить только об одной сущности, а не об одной таблице
Возможно, вам было бы проще, если бы вы не приводили примеры микросервисов. Просто принято решение - перейти.
Без обьяснения мотивов перехода на МСА на мой взгляд нельзя сформулировать требования к потоку моделирования.
А обоснование остаётся за скобками
Именно так
Физически шарды логических таблиц - это как правило разные таблицы
Не надо ходить этой скользкой дорожкой. Вы про микросервисы или про внутреннее устройство БД? Если про первое, то БД к ним никакого отношения не имеет, вместе с её внутренностями.
Важно получить обоснование - зачем вам понадобились микросервисы. Вы пока ни одного приемлемого варианта не озвучили, только переводите стрелки на БД и прочие рассуждения.
Ну либо всё же признайте - вам сказано "внедрить", а зачем - не важно. Ну вы и внедряете. Можно даже как-то политкорректно, вроде "у нас решили перейти на микросервисы, потому что очень умные люди очень много рассказывали про важность такого перехода".
Вы про микросервисы или про внутреннее устройство БД?
Я про спорность утверждения о единственности таблицы остатков
Ну либо всё же признайте - вам сказано "внедрить", а зачем - не важно.
Признаю : были сформулированы нефункциональные требования и архитектором , как лицом, отвечающим за НФТ, были приняты соответствующие архитектурные решения, которые он согласовал с заинтересованными лицами. Ни ход выполнения проекта, ни результат его выполнения не показал, что принятые архитектурные решения были неверными.
В принципе область эффективности МСА была четко обозначена еще Фаулером, и с того времени , IMHO, по этой теме мало кто чего добавил. Во всяком случае я что-то добавить не готов
Visual Paradigm
Плюсанул за его упоминание. Почему-то мало известный продукт, при том, что "на поиграться" есть полностью бесплатная версия.
Разве схемы бизнес-процессов (БП) привязаны к реализации, будь то монолит или MSA?
В БП акторы - бизнес-сущности, описывается бизнес-логика. Иначе это уже не БП, разве не так?
Приведённые в тексте примеры меня не убедили
Все зависит от целей и задач, которые вы ставите при описании БП. Можете описать на таком уровне абстракции, что не привязаны, а можете так , что привязаны. И что за система - ее архитектура может влиять на БП, а может быть чисто технической и не влиять.
Приведенный кейс актуален для систем организационного управления , где как правило архитектура и БП взаимосвязаны
Изоляция микросервисов по данным при миграции с монолита