Какой принцип рекомендуется соблюдать при проектировании границ микросервисов и зависимостей между ними
Что проверяют
Понимаете ли вы, что граница сервиса проводится по бизнес-смыслу, а не по таблицам и не по техническим слоям. Главный принцип, который ждут услышать: высокая связность внутри сервиса и слабая зацепленность между сервисами. Следом просят нарезать на сервисы конкретный домен, например интернет-магазин, и объяснить, как они обмениваются данными.
Как отвечать
Опорные идеи:
- ограниченный контекст (bounded context) из DDD: сервис совпадает с областью, внутри которой термины однозначны. «Товар» в каталоге и «товар» на складе это разные модели с разными атрибутами, и это нормально;
- бизнес-возможность, а не сущность: сервис «оформление заказа» лучше, чем CRUD-сервис над таблицей заказов, к которому ходят все;
- своя база у каждого сервиса: остальные получают данные только через API или события. Общая база превращает систему в распределённый монолит;
- зависимости в одну сторону и без циклов: если А вызывает Б, а Б вызывает А, границу провели неверно;
- короткие синхронные цепочки: в цепочке из пяти вызовов доступность перемножается, и отказ любого звена роняет весь сценарий. Где немедленный ответ не нужен, используют события через брокер;
- владение командой: по закону Конвея сервис удобно отдавать одной команде целиком.
Как аналитик вы выходите на границы через моделирование: event storming, выделение агрегатов и событий, карта контекстов с типами связей между ними. Хорошая проверка: большинство изменений требований затрагивает один сервис, а не три сразу. Если бизнес-операция всё же проходит через несколько сервисов, описывают сагу с компенсирующими действиями вместо распределённой транзакции.
Где спотыкаются
Нарезают сервисы по сущностям. Получается десяток CRUD-сервисов, и любая фича требует согласованных изменений в половине из них.
Верят, что асинхронность сама делает сервисы независимыми. Она убирает зависимость по времени, но если сервис разбирает внутреннюю структуру чужого события, связь по контракту остаётся.
Дробят слишком мелко, до наносервисов. Сетевые вызовы, мониторинг и согласованность данных обходятся дороже выгоды от разделения, поэтому часто разумнее начать с модульного монолита.