sottoЗачем Spring Cloud
Когда монолит разрезан на сервисы, появляются задачи, которых раньше не было: где хранить настройки десятка сервисов, как сервису найти соседа, через какую точку внешний трафик попадает внутрь и как проследить запрос, прошедший через пять сервисов. Spring Cloud — набор библиотек, которые решают эти задачи на стороне приложения.
Важная оговорка с самого начала: в Kubernetes заметную часть этих задач уже решает платформа. Поэтому полезно знать не только, как устроен каждый компонент, но и когда он не нужен.
Config Server
Spring Cloud Config Server — отдельный сервис, который раздаёт конфигурацию всем приложениям. Источник настроек — чаще всего Git-репозиторий: файлы вида orders-service-prod.yml лежат в нём, а сервис при старте спрашивает у Config Server свою конфигурацию по имени приложения и профилю.
Что это даёт: настройки меняются без пересборки артефакта, история изменений хранится в Git, одинаковые параметры не копируются по репозиториям сервисов. Обновить настройки без перезапуска помогает @RefreshScope и событие обновления.
Чего Config Server не решает — хранения секретов. Пароли и ключи в Git-репозитории остаются уязвимыми даже в закрытом репозитории. Для них используют Vault, облачный KMS или секреты Kubernetes. В Kubernetes обычную конфигурацию часто отдают через ConfigMap, и отдельный Config Server тогда не нужен.
Service discovery
Сервисы в облаке постоянно перезапускаются и меняют адреса, поэтому вызывать соседа по жёстко прописанному host:port нельзя. Service discovery позволяет обращаться по логическому имени: сервис при старте регистрируется в реестре, а клиент спрашивает у реестра живые экземпляры и выбирает один из них (балансировка на стороне клиента).
Классический реестр в Spring Cloud — Eureka из стека Netflix. В Kubernetes ту же роль выполняют объект Service и встроенный DNS: имя orders-service и так разрешается в живые поды. Поэтому в Kubernetes Eureka обычно избыточна.
API Gateway
Gateway — единая точка входа для внешнего трафика. Spring Cloud Gateway принимает запрос и по правилам маршрутизации передаёт его нужному сервису. На шлюзе удобно делать то, что одинаково для всех сервисов: завершение TLS, проверку токена, ограничение частоты запросов, добавление correlation id, постепенное переключение трафика на новую версию.
Главное правило: на шлюзе не должно быть бизнес-логики. Если в него начинают переносить правила предметной области, он превращается во второй монолит, который нужно выкатывать вместе со всеми сервисами.
spring:
cloud:
gateway:
routes:
- id: orders
uri: lb://orders-service # lb — балансировка через discovery
predicates:
- Path=/orders/**Распределённая трассировка
Трассировка связывает один пользовательский запрос в цепочке сервисов: каждый сервис получает trace id из заголовка, создаёт свой span и передаёт контекст дальше. В системе вроде Zipkin или Jaeger видно, сколько времени запрос провёл в каждом сервисе и где возникла ошибка.
В Spring Boot 3 трассировку строят на Micrometer Tracing с мостом в OpenTelemetry. Spring Cloud Sleuth, о котором пишут старые материалы, больше не развивается — для Boot 3 он не подходит.
Как отвечать на собеседовании
Разберите компоненты по задачам, а не по названиям: Config Server — централизованная конфигурация (но секреты — в Vault или KMS), discovery — поиск по логическому имени, Gateway — единая точка входа без бизнес-логики, трассировка — путь запроса через сервисы на Micrometer Tracing и OpenTelemetry.
Сильный акцент — граница с платформой. В Kubernetes discovery даёт Service и DNS, конфигурацию — ConfigMap, а часть функций шлюза и трассировки может взять на себя service mesh вроде Istio. Выбирать компоненты стоит по тому, чего не хватает в инфраструктуре, а не подключать весь Spring Cloud по привычке.