Config, Gateway, Eureka

Spring Cloud — набор инструментов поверх Spring для микросервисной архитектуры, решает проблемы, которые появляются именно когда сервисов много, а не один монолит. Три ключевых компонента:

Config Server — централизованное хранилище настроек для всех сервисов сразу, вместо того чтобы у каждого сервиса был свой application.yml, разбросанный и несогласованный:

spring:
  config:
    import: "configserver:http://config-server:8888"

Eureka — Service Discovery, “телефонная книга” сервисов. Каждый сервис при старте регистрируется в Eureka, и другие сервисы находят его по имени, а не по жёстко прописанному IP-адресу:

@EnableEurekaClient
class OrderServiceApplication { ... }

// в коде других сервисов:
restTemplate.getForObject("http://USER-SERVICE/api/users/1", User.class);
// "USER-SERVICE" — имя, Eureka сама находит реальный текущий адрес

Gateway — единая точка входа для всех запросов в систему микросервисов, маршрутизирует их к нужному сервису:

spring:
  cloud:
    gateway:
      routes:
        - id: user-service
          uri: lb://USER-SERVICE
          predicates: [Path=/api/users/**]

Копнуть глубже

Зачем Service Discovery, если можно прописать адреса вручную. В микросервисах сервисы постоянно перезапускаются, масштабируются, переезжают (особенно в Kubernetes — см. тему «Pod, Deployment») — их IP-адреса меняются динамически. Жёстко прописанные адреса быстро устаревают. Eureka решает это: сервисы регистрируются сами при старте и снимаются с регистрации при остановке, остальные всегда находят актуальный адрес.

Gateway также берёт на себя сквозную логику для всех запросов сразу — аутентификацию, ограничение частоты запросов (rate limiting), логирование — чтобы не дублировать это в каждом отдельном микросервисе.

🎤 Закрыл тему, если можешь объяснить:

• роли Config Server, Eureka и Gateway в микросервисной архитектуре;
• зачем нужен Service Discovery, а не жёстко прописанные адреса (если дошёл до 2-го слоя).