Почему Spring Boot лучше подходит для микросервисной архитектуры
Что проверяют
Назовёте ли вы конкретные вещи, которые нужны сервису в контейнере, или выдадите список маркетинговых достоинств. Хороший ответ содержит оговорку: «лучше» здесь не абсолютное, и кандидат, который знает минусы и альтернативы, выглядит сильнее.
Как отвечать
Перечисляйте через потребность микросервиса:
- встроенный сервер и исполняемый jar: сервис поднимается одной командой, внешний контейнер сервлетов не нужен, образ собирается тривиально;
- стартеры и автоконфигурация: типовая обвязка не переписывается в каждом из двух десятков сервисов;
- конфигурация снаружи: профили, переменные окружения и файлы свойств ложатся на подход двенадцати факторов и на секреты оркестратора;
- Actuator: готовые эндпоинты состояния под пробы живости и готовности, метрики через Micrometer, трассировка;
- тестирование: срезы контекста и связка с Testcontainers дают честные интеграционные тесты одного сервиса.
Обязательно разделите Boot и Cloud: обнаружение сервисов, конфигурационный сервер, шлюз и предохранитель это Spring Cloud, а не сам Boot.
Оговорка про минусы: JVM заметно ест память и стартует небыстро, поэтому для очень мелких функций и бессерверных сценариев берут Quarkus или Micronaut с конфигурацией на этапе компиляции либо собирают нативный образ через GraalVM.
Где спотыкаются
Пересказывают буклет: удобно, гибко, масштабируемо. Интервьюер ждёт привязки к эксплуатации, то есть пробы, метрики, корректное завершение по сигналу, конфигурация из окружения.
Второе: говорят, что Spring Boot делает архитектуру микросервисной. Фреймворк упаковывает один сервис, а согласованность данных, отказы сети и границы контекстов он не решает. Монолит на Spring Boot это нормальный и частый выбор.
Третье: не могут назвать ни одного недостатка. Ответ без минусов читается как заученный, и следующий вопрос обычно про время старта и потребление памяти.