Сколько микросервисов на проекте

Что проверяют

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

Как отвечать

Назовите реальное число с контекстом: «в продукте около сорока сервисов, наша команда отвечает за пять: заказы, оплаты, уведомления». Дальше коротко об устройстве:

• границы: сервис выделяется по бизнес-области (bounded context), у каждого своя база. Одна база на несколько сервисов это уже распределённый монолит;
• синхронные вызовы: REST через RestClient, WebClient или OpenFeign, иногда gRPC;
• асинхронные: события через Kafka или RabbitMQ, чтобы сервисы не зависели от доступности друг друга;
• устойчивость: таймауты, повторы и circuit breaker на Resilience4j. Hystrix давно в режиме поддержки и в новых проектах не встречается;
• наблюдаемость: метрики через Micrometer в Prometheus и Grafana, сквозная трассировка через Micrometer Tracing и OpenTelemetry. Spring Cloud Sleuth остался в эпохе Spring Boot 2;
• развёртывание: Kubernetes, где поиск сервисов закрывают его Service и DNS, так что Eureka часто не нужна.

Хорошо, если скажете, что бы вы объединили или разделили иначе. Это показывает, что вы думали об архитектуре, а не только писали код в своём сервисе. Если на проекте монолит, так и скажите и расскажите, как он поделён на модули и что мешает или не мешает его распилить.

Где спотыкаются

Не знают число даже примерно или называют заведомо раздутое. Уточняющий вопрос про соседний сервис быстро это показывает.

Считают, что @Transactional работает поверх нескольких сервисов. Распределённая операция строится на саге или на transactional outbox, и об этом стоит сказать самим.

Путают количество с качеством. «У нас двести сервисов» без объяснения, зачем они такие мелкие, звучит как проблема, а не как достижение.