Что хотят услышать интервьюеры:

Микросервисная архитектура — это подход, где приложение разбивается на набор небольших независимых сервисов с четкими границами ответственности. Каждый сервис можно разрабатывать, тестировать, разворачивать и масштабировать отдельно. Важно понимать не только плюсы, но и то, что вместе с гибкостью растет сложность интеграции, наблюдаемости и согласованности данных.

Определение:

Микросервисная архитектура — это стиль построения системы, в котором функциональность делится на отдельные автономные сервисы. Каждый сервис отвечает за свою бизнес-область, общается с другими через легковесные протоколы, например HTTP или сообщения очередей, и обычно имеет собственный жизненный цикл развертывания.

Ключевая идея — разделить монолит на слабо связанные компоненты, чтобы изменения в одном сервисе минимально влияли на остальные. При этом микросервисы требуют продуманной инфраструктуры: сервис-дискавери, мониторинга, централизованного логирования, обработки сбоев и версионирования контрактов.

Пример использования:

Интернет-магазин можно разделить на сервисы: каталог товаров, корзина, заказы, платежи, доставка и уведомления. Каталог можно масштабировать отдельно в период высокой нагрузки, а платежный сервис обновлять без остановки остальных частей системы.

Frontend -> API Gateway -> [Catalog Service]
                        -> [Cart Service]
                        -> [Order Service]
                        -> [Payment Service]
                        -> [Notification Service]

Пояснение кода:

Код не требуется. На практике схема работает так: пользователь открывает сайт, запрос идет через API Gateway, который маршрутизирует его в нужный сервис. Например, при оформлении заказа сервис заказов вызывает сервис платежей, а после успешной оплаты отправляет событие в сервис уведомлений. Каждый сервис имеет свою область ответственности и может быть изменен независимо, если контракт взаимодействия не нарушается.

Ключевые моменты:

Каждый сервис отвечает за одну бизнес-область, а не за технический слой.
Сервисы должны быть слабо связаны и взаимодействовать через явные контракты.
Развертывание и масштабирование происходят независимо для каждого сервиса.
Часто у каждого сервиса своя база данных или хотя бы свой способ владения данными.
Появляются дополнительные сложности: распределенные ошибки, сетевые задержки, согласованность данных, мониторинг и трассировка.
Для QA важно тестировать не только сервисы по отдельности, но и их интеграции, контракты и сценарии отказоустойчивости.

Могли бы вы объяснить принципиальные особенности и структуру микросервисной архитектуры?