Монолит против микросервисов, границы сервисов, взаимодействие и цена распределённости.
Практика. Разобрать учебный монолит на модули с явными границами и описать, какой модуль и почему стоит выделить первым.
Практика. Спланировать выделение сервиса из монолита — данные, API, миграция трафика, откат.
Система из независимо развёртываемых сервисов, каждый владеет своими данными и отвечает за бизнес-возможность. Ключевое — независимость, а не размер.
Домен в центре и не зависит ни от чего внешнего. Он объявляет порты — интерфейсы на своём языке: входящие (сценарии использования) и исходящие (OrderRepository, PaymentGateway)…
Микросервисы решают организационную задачу — независимую разработку и выкатку многими командами, а не задачу производительности.
По ограниченным контекстам (bounded context) и бизнес-возможностям: типичный сценарий должен выполняться внутри одного сервиса.
Цена распределённой системы уплачена, а независимость не получена: общий релиз, общая база, синхронные цепочки, общая библиотека моделей.
В синхронной цепочке доступности перемножаются: 0,999⁵ ≈ 0,995. Простой вырастает впятеро — с ~43 минут до ~3,6 часа в месяц.
Когда микросервисы оправданы, а когда вредны; bounded context и DDD как способ резать систему; распределённый монолит и его признаки; база на сервис и организационная цена.
На живом собеседовании sotto слышит вопрос интервьюера и показывает короткий ответ и план. Оставьте контакт — пришлём доступ и промокод.
sotto