Аналитику не нужно писать микросервисы, но нужно понимать, как требования раскладываются по сервисам, где живут данные и что будет с консистентностью. Без этого контракт «на бумаге» не сработает в реальности.
Монолит и микросервисы
- Монолит: одно приложение, одна БД. Просто разрабатывать и тестировать на старте, одна транзакция на всё.
- Микросервисы: независимо разворачиваемые сервисы, каждый со своими данными и командой. Плюсы: независимые релизы и масштабирование, изоляция сбоев. Минусы: сеть, распределённые транзакции, сложная отладка, нужна зрелая эксплуатация.
- Модульный монолит: компромисс, чёткие модули внутри одного приложения.
Как резать: границы по домену
DDD (Domain-Driven Design) даёт язык:
- Ограниченный контекст (bounded context): часть домена, где термины однозначны. «Клиент» в продажах и «клиент» в доставке это разные модели.
- Единый язык (ubiquitous language): одни слова у бизнеса, аналитика и кода.
- Агрегат: группа объектов, которая меняется одной транзакцией (заказ со строками).
Хорошая граница: сервису редко нужно синхронно спрашивать другие, чтобы выполнить свою задачу. Плохая: «распределённый монолит», где любой запрос проходит цепочку из 6 сервисов.
Данные
- Database per service: у каждого сервиса своя БД, чужую напрямую читать нельзя, только через API или события.
- Нужные чужие данные держат копией, обновляемой событиями (например, сервис доставки хранит адрес из заказа).
- Отчёты по всем данным строят в хранилище (DWH), куда сервисы выгружают данные.
Консистентность
Одной транзакции на всё больше нет. Варианты:
- Сага с компенсациями.
- Eventual consistency: данные сойдутся через секунды. Аналитик фиксирует, где это допустимо (счётчик просмотров), а где нет (остаток на счёте).
- Промежуточные статусы в UI: «Платёж обрабатывается».
Типовые компоненты
- API Gateway: единая точка входа, маршрутизация, аутентификация, лимиты.
- BFF (backend for frontend): свой фасад под веб и мобильное приложение.
- Service discovery, балансировка, circuit breaker (прекращает звать упавший сервис, чтобы не копить таймауты).
- Наблюдаемость: логи, метрики, распределённая трассировка с correlation id.
Устойчивость синхронных вызовов
- Таймаут на каждый вызов.
- Повторы только для идемпотентных операций и с экспоненциальной задержкой.
- Circuit breaker и деградация: если сервис рекомендаций лёг, показываем популярное.
- Аналитик описывает поведение при отказе зависимостей: это тоже требования.
Контракты между командами
- Контракт API или события версионируется, ломающие изменения согласуются.
- Consumer-driven contracts (например, Pact): потребитель описывает ожидания, поставщик проверяет их в CI.
- Владелец каждого контракта назначен явно.
Частые ошибки
- Резать по техническим слоям («сервис БД», «сервис валидации»).
- Общая база на несколько сервисов.
- Синхронные цепочки, где падение одного сервиса кладёт всё.
- Требовать строгую консистентность там, где бизнесу хватит секунд задержки, и наоборот.
Что спросят на собесе
- Плюсы и минусы микросервисов. Когда лучше монолит?
- Как определить границы сервисов?
- Как обеспечить согласованность данных без распределённой транзакции?
- Что такое API Gateway и BFF?
- Что должен описать аналитик, если сервис зависит от трёх других?