Лекція 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 і сервіс-реєстр, щоб отримати ще більше крутих можливостей!