Модульный монолит и микросервисы Раз уж затронули эту тему. Хороший модульный монолит – очень достойная архитектура. Иногда достаточно привести монолит к правильной модульной структуре, и дальше двигаться не нужно. Это рационально для многих организаций. Модульный монолит может обеспечить: ▪️Слабую связанность и независимые модули ▪️Независимые модели данных (отдельные наборы таблиц) ▪️Замену отдельных компонентов (система плагинов) Что микросервисы дают дополнительно? ▪️Независимое масштабирование В монолите при нагрузке на один компонент (например, отображение карточки товара) приходится масштабировать весь монолит, тратя ресурсы на простаивающую функциональность. Микросервисы позволяют масштабировать только нагруженный компонент. Особенно ценно при использовании облачных вычислений с оплатой по факту потребления. ▪️Независимый технологический стек Каждый микросервис может использовать наиболее подходящие технологии и инструменты для своей задачи. ▪️Независимая поставка Каждый сервис выпускается в продакшен независимо от других, без необходимости координации с другими командами. Чем микросервис принципиально отличается от хорошо спроектированного модуля в монолите? У каждого микросервиса одна цель и один источник (заказчик) изменений. В монолите обычно много целей, много стейкхолдеров, запрашивающих изменения. И однак кодовая база. Кроме того, микросервисы физически независимы в развертывании, масштабировании и могут использовать разные технологии. В монолите, при общей кодовой базе, это невозможно технически. «Распределенный монолит» Если при изменении одного сервиса приходится изменять два, три и более других сервисов и эти изменения блокируют друг друга – примерно это и есть распределенный монолит. Цель изменений одна, источник один, а логика разнесена. Это хуже, чем обычный монолит. У распределенного монолита все недостатки монолита плюс сложность распределенной системы. Я говорил про логику, но еще часто он возникает из-за зависимостей по данным, когда одна сущность используется в нескольких контекстах без изоляции. Пример Если система скоринга знает о внутреннем устройстве кредитов наличными и POS-кредитов, она не может развиваться автономно. При любом (в экстремуме) изменении в продуктах команде скоринга нужно обновлять свой код. Скоринг превращается в узкое место и постоянно занят доработкой чужих изменений. Скоринг не должен знать, что именно он скорит, у него должна быть своя модель, в которую на границе преобразуется входная информация.