В резюме и вакансиях Spring Cloud до сих пор встречается через раз, но состав его изменился радикально: половину задач, ради которых проект создавался, забрала платформа — Kubernetes. Разберём по задачам: что раньше решали библиотеками в приложении, что теперь решает платформа и что из Spring Cloud остаётся живым и нужным.
Откуда взялся Spring Cloud
Когда микросервисы разъезжались по виртуалкам без оркестратора, всю «сетевую обвязку» приходилось делать внутри приложений: находить друг друга (Eureka), хранить общий конфиг (Config Server), балансировать запросы (Ribbon), рвать цепочки отказов (Hystrix), маршрутизировать с края (Zuul). Spring Cloud собрал это в набор стартеров — и для своего времени это был лучший ответ.
Kubernetes решает те же задачи, но снаружи приложения: сервис не обязан знать, что его балансируют и перезапускают.
Задача за задачей
| Задача | Spring Cloud (классика) | Kubernetes |
|---|---|---|
| Найти соседний сервис | Eureka + клиент в каждом сервисе | DNS: http://orders — Service сам балансирует |
| Конфигурация | Config Server + Git-репозиторий | ConfigMap / Secret, монтируются в под |
| Балансировка | Ribbon на клиенте | Service / kube-proxy, при нужде — mesh |
| Маршрутизация с края | Zuul / Spring Cloud Gateway | Ingress / Gateway API |
| Перезапуск упавшего | — (руками) | liveness / readiness probes |
| Раскатка без простоя | — | rolling update из коробки |
Правило чтения таблицы: если задача инфраструктурная (кто где живёт, как доставить конфиг, как перезапустить) — её место на платформе. Приложение, тянущее Eureka и Config Server внутри Kubernetes, дублирует платформу и платит за это сложностью и памятью.
Что остаётся приложению
Платформа не видит смысла запросов — поэтому прикладные задачи остались библиотекам:
- Устойчивость на клиенте: circuit breaker, retry с джиттером, таймауты, bulkhead — это Resilience4j (Hystrix давно в архиве). Платформа перезапустит упавший под, но не решит за вас, ждать ли ответа платёжного шлюза 30 секунд.
- Распределённая трассировка: Micrometer Tracing (бывший Sleuth) — контекст запроса живёт в коде.
- API Gateway как приложение: Spring Cloud Gateway жив и уместен, когда на краю нужна прикладная логика — авторизация, лимиты по пользователю, агрегация ответов. Для чистой маршрутизации хватает Ingress.
- Feign / HTTP-клиенты: декларативные клиенты остаются удобством кода, discovery им больше не нужен — ходят по DNS-имени.
Отдельная ниша — service mesh (Istio, Linkerd): mTLS, канареечные раскатки, сетевые политики без изменения кода. Это следующий уровень платформенного подхода, и он ещё сильнее сужает роль библиотек.
Как выбирать
- Вы в Kubernetes (типовой случай): discovery, конфиг, балансировка, маршрутизация — у платформы. Из Spring Cloud берёте точечно: Resilience4j-интеграцию, Gateway при нужде в прикладном крае. Eureka, Config Server, Ribbon, Hystrix, Zuul — не начинать.
- Вы без оркестратора (виртуалки, свой хостинг): классический Spring Cloud всё ещё решает реальные проблемы — но честнее спросить, почему без оркестратора.
- Наследованный проект с полным стеком Netflix: работает — не трогайте ради моды; мигрируйте задачами вместе с переездом в Kubernetes.
Коротко
- Spring Cloud возник до эпохи оркестраторов и решал инфраструктурные задачи внутри приложения; Kubernetes решает их снаружи.
- Забрала платформа: discovery (DNS), конфигурацию (ConfigMap/Secret), балансировку, маршрутизацию с края, перезапуски и раскатки.
- Осталось приложению: circuit breaker и retry (Resilience4j), трассировка, Gateway с прикладной логикой, декларативные HTTP-клиенты.
- Eureka, Config Server, Ribbon, Hystrix, Zuul в новом проекте на Kubernetes — признак копирования старых рецептов.
- Service mesh двигает границу ещё дальше в сторону платформы — следите за ней, границей, а не за модой.
Что почитать дальше
- Kubernetes и graceful shutdown — как платформа управляет жизнью пода.
- Надёжность сети: таймауты и повторы — прикладная сторона, которая осталась вам.
- Монолит или микросервисы — нужен ли вообще этот разговор вашему проекту.