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