Лекция 246: Зачем нужен сервис-реестр в микросервисах

На этом этапе курса вы уже освоили основы микросервисной архитектуры, научились работать с API Gateway и интегрировать его в проекты на Spring Boot. API Gateway стал вашим другом и проводником в управление запросами между микросервисами. Вы узнали, как маршрутизировать запросы, обрабатывать их с различными фильтрами и предикатами, а также обеспечивать безопасность и балансировку нагрузки. Сегодня мы погрузимся в другой важный аспект работы микросервисов — Service Discovery. Но сначала давайте поймем, почему это вообще важно!

Представьте себе...

Итак, вы как опытный разработчик микросервисной архитектуры решаете создать приложение из множества независимых сервисов: каталог товаров, сервис авторизации, корзина покупок, сервис платежей. Всё отлично до тех пор, пока вам не нужно начать взаимодействовать с этими сервисами.

"Какой у нас будет IP-адрес для каталога товаров?" - спросят вас коллеги. "Мы же его на другом сервере разместили. А, если мы решили масштабироваться, как новых реплик добавить?" - добавят DevOps-инженеры.

И вот начинается хаос: вы вручную прописываете IP-адреса, изменяете конфигурации для каждого микросервиса, и через пару дней понимаете, что вручную управлять этим адом уже невозможно. Поздравляю, вы только что столкнулись с проблемой, которую решает сервис-реестр!

Что такое сервис-реестр?

Подходите ближе, мы разберём это детально.

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

Вот как всё это выглядит:

1. Микросервисы регистрируются в реестре. Когда новый экземпляр сервиса запускается, он сообщает реестру: "Привет, я сервис платежей, мой адрес — http://127.0.0.1:8082".
2. Запрос списка сервисов. Когда другой сервис, например "корзина покупок", хочет связаться с сервисом платежей, он спрашивает реестр: "Где мне найти сервис платежей?"
3. Обновления в реальном времени. Если сервис умирает или добавляются новые экземпляры (например, из-за увеличения нагрузки), реестр обновляет свою информацию.

Проблемы, которые решает сервис-реестр

1. Динамическое обнаружение сервисов: сервисы могут свободно перемещаться, добавляться или удаляться без необходимости обновлять маршруты вручную.
2. Масштабируемость: несколько экземпляров одного сервиса могут быть зарегистрированы, и это позволяет балансировать нагрузку между ними.
3. Упрощение конфигурации: вам не нужно задавать статические IP-адреса для каждого сервиса.

Почему использование статической конфигурации — плохая идея?

Когда вы начинаете встраивать микросервисы друг с другом, первый импульс многих разработчиков — "Давайте пропишем всё жестко в application.yml!".

Вот пример:

catalog-service:
  url: http://127.0.0.1:8081
payment-service:
  url: http://127.0.0.1:8082
auth-service:
  url: http://127.0.0.1:8083

Это работает… пока ваши микросервисы остаются статичными. Но что, если:

1. Один из сервисов переезжает на другой сервер?
2. Вы захотите добавить новые экземпляры для масштабирования?
3. Сервисы начинают масштабироваться динамически в Kubernetes?

Ручное обновление конфигураций становится невыносимым, и в результате у вас появляется больше ошибок, чем кода. Решением этой проблемы служат динамическое обнаружение сервисов и сервис-реестр, такие как Eureka, Consul или Zookeeper.

Как работает сервис-реестр?

Основные элементы:

1. Service Registry (Реестр сервисов): это центральный узел, где хранится информация обо всех зарегистрированных сервисах. Он знает, кто где находится, кто жив, а кто нет.
2. Service Provider (Поставщик услуг): каждый микросервис, предоставляющий функционал, регистрируется у реестра. Это происходит при запуске приложения.
3. Service Consumer (Потребитель услуг): любой микросервис, который хочет использовать другой сервис, делает запрос к реестру, чтобы узнать его местоположение.

Алгоритм работы:

1. Регистрация: сервис при старте отправляет информацию о себе в реестр (IP, порт, имя).
2. Heartbeat (Пульс): сервисы периодически шлют "сигналы жизни" реестру. Если пульс пропал, реестр помечает сервис как "недоступный".
3. Обнаружение: когда потребитель хочет найти другой сервис, он спрашивает реестр.
4. Балансировка нагрузки: когда несколько экземпляров одного сервиса зарегистрированы, реестр может предоставить список всех активных экземпляров для распределения нагрузки.

Пример использования реестра на базе Eureka

Eureka — это решение от Netflix для Service Discovery. Оно интегрируется с Spring Boot и является одним из самых популярных инструментов в мире микросервисов.

1. Настройка Eureka Server

Сначала создадим сервер, который будет выполнять роль нашего сервис-реестра. Добавьте зависимость в ваш pom.xml:

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
</dependency>

Далее в классе запуска добавьте аннотацию @EnableEurekaServer:

@SpringBootApplication
@EnableEurekaServer
public class EurekaServerApp {
    public static void main(String[] args) {
        SpringApplication.run(EurekaServerApp.class, args);
    }
}

И в application.yml настроим минимальную конфигурацию:

server:
  port: 8761

eureka:
  client:
    fetch-registry: false
    register-with-eureka: false

Запустите приложение. Eureka Server будет доступен по адресу http://localhost:8761.

2. Настройка сервиса-клиента

Теперь зарегистрируем микросервис в Eureka. Добавьте эту зависимость:

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>

Включите клиентскую поддержку Eureka с помощью аннотации @EnableEurekaClient:

@SpringBootApplication
@EnableEurekaClient
public class PaymentServiceApp {
    public static void main(String[] args) {
        SpringApplication.run(PaymentServiceApp.class, args);
    }
}

Добавьте настройки Eureka в application.yml:

server:
  port: 8082

spring:
  application:
    name: payment-service

eureka:
  client:
    service-url:
      defaultZone: http://localhost:8761/eureka/

После запуска микросервиса он появится на панели Eureka Server.

Альтернативы Eureka

Eureka — не единственный вариант. Вот ещё несколько популярных решений:

• Consul: мощный сервис-реестр с поддержкой распределения трафика и управления конфигурациями.
• Zookeeper: стабильный инструмент для распределённых систем, используется во многих крупных компаниях.
• Etcd: лёгкое и быстрое решение, часто используемое в Kubernetes.

Преимущества использования сервис-реестра

1. Гибкость и масштабируемость микросервисной системы.
2. Упрощённое управление конфигурациями и маршрутизацией.
3. Возможность легко добавлять новые экземпляры сервисов без изменения основной конфигурации.
4. Обеспечение отказоустойчивости системы путём автоматического исключения недоступных сервисов.

Использовать статическую конфигурацию просто, но грустно. А вот с сервис-реестрами жизнь становится весёлой, хотя бы потому, что вы перестаёте быть "системным администратором" для своих микросервисов. В следующей лекции мы узнаем, как объединить API Gateway и сервис-реестр, чтобы получить ещё больше крутых возможностей!