Как работает микросервисная архитектура
Что проверяют
Понимаете ли вы, за что платите при переходе на микросервисы, а не только список выгод из статьи. Дальше слушают, как вы проводите границы сервисов и что делаете с данными, транзакциями и отказами.
Как отвечать
Определение. Приложение собрано из небольших сервисов, каждый отвечает за свою бизнес-возможность, разворачивается и масштабируется независимо, общается с остальными по сети через явный контракт.
Ключевой критерий не размер, а независимость деплоя. Если для выката фичи нужно синхронно выкатить три сервиса, это распределённый монолит: сложность сетевая уже оплачена, а выгоды нет.
Границы. Режут по бизнес-возможностям (bounded context из DDD): каталог, заказы, платежи, уведомления. Резать по техническим слоям («сервис базы», «сервис API») бессмысленно, любая фича всё равно затронет все.
Данные. У каждого сервиса своя база, чужие таблицы читать нельзя. Общая база убивает независимость деплоя: изменение схемы ломает соседей, и вы возвращаетесь к монолиту с сетевыми вызовами внутри.
Взаимодействие:
- Синхронное: HTTP/REST или gRPC. Просто, но задержки и отказы складываются вдоль цепочки вызовов.
- Асинхронное: события через брокер (Kafka, RabbitMQ). Развязывает сервисы по времени и доступности, но приносит итоговую согласованность и порядок доставки как отдельную задачу.
Транзакции. Распределённой транзакции в привычном виде нет. Используют saga с компенсирующими действиями (отменить бронь, вернуть деньги) и transactional outbox, чтобы запись в свою базу и публикация события не разъехались при сбое.
Устойчивость не появляется сама. Нужны таймауты на каждый вызов, ретраи с экспоненциальной задержкой и джиттером, circuit breaker, идемпотентные обработчики (повторная доставка события не должна списать деньги дважды) и осмысленная деградация вместо каскадного отказа.
Эксплуатация. Централизованные логи, метрики по каждому сервису, распределённая трассировка со сквозным trace id. Без этого отладка «где потерялся заказ» превращается в чтение десяти разных логов.
Цена. Сетевые задержки, версионирование контрактов, интеграционное тестирование, N пайплайнов и N дежурств. Небольшой команде обычно выгоднее модульный монолит с чёткими внутренними границами, из которого сервисы выносят по мере роста нагрузки и числа команд.
Где спотыкаются
Пересказывают плюсы и утверждают, что «падение одного сервиса не влияет на приложение». Без таймаутов, ретраев и запасного поведения один медленный сервис кладёт всю синхронную цепочку, и это ровно то, что интервьюер хочет услышать про отказоустойчивость.