Всі труднощі та уроки, через які я пройшов, щоб налаштувати хмарну архітектуру на основі мікросервісів — включаючи шлюзи, сервери відкриття та самі мікросервіси.
Ця стаття досліджує еволюцію від Netflix Eureka до HashiCorp Consul для відкриття сервісів, з впровадженням Spring Cloud Gateway та Kong для керування API. Ми розглянемо деталі реалізації та переваги кожного підходу.
Еволюція відкриття сервісів
Початковий підхід: Netflix Eureka
Eureka реалізує архітектуру клієнт-сервер для відкриття сервісів:
Налаштування сервера Eureka з мікросервісами
- Сервер: Центральний реєстр, що підтримує з'єднання сервісів
- Клієнти: Мікросервіси, які реєструють себе на сервері
- Реалізація: Сервіси спілкуються через імена сервісів, а не жорстко прописані URL
- Балансування навантаження: Ribbon забезпечує балансування навантаження на стороні клієнта з використанням алгоритму round-robin
Масштабовані екземпляри мікросервісів — балансування навантаження через ribbon.
Запити чергуються між екземплярами 9091 та 9092.
Сучасний підхід: HashiCorp Consul
Consul має кілька переваг порівняно з Eureka:
- Уникає необхідності в окремому обслуговуванні серверів
- Автоматична реєстрація/дереєстрація сервісів
- Вбудоване перевірка здоров'я
- Інтерфейс DNS
Реалізація Consul
- Встановлення: (Binary — я використовую ubuntu)
wget -O - https://apt.releases.hashicorp.com/gpg | sudo gpg --dearmor -o /usr/share/keyrings/hashicorp-archive-keyring.gpg
echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] https://apt.releases.hashicorp.com $(lsb_release -cs) main" |
sudo tee /etc/apt/sources.list.d/hashicorp.list
sudo apt update && sudo apt install consul
2.
Конфігурація
-
Залежність, додавання клієнта consul-discovery у pom.xml,
-
Додавання @EnableDiscoveryClient до програми Spring Boot,
# Конфігурація Spring Cloud Consul pom.xml
spring.cloud.consul.host=127.0.0.1
spring.cloud.consul.port=8500
spring.cloud.consul.discovery.service-name=shopping-service
Усі (або всі) мікросервіси повинні бути зареєстровані в Consul — через властивості або файл yml.
— — — — — — Сервіс — 1 — — — — — —
spring.application.name=shopping-service
server.port=9090
# Конфігурація Spring Cloud Consul
spring.cloud.consul.host=127.0.0.1
spring.cloud.consul.port=8500
spring.cloud.consul.discovery.service-name=shopping-service
і аналогічно для сервісу 2.
spring.application.name=payment-service
server.port=9100
# Конфігурація Spring Cloud Consul
spring.cloud.consul.host=127.0.0.1
spring.cloud.consul.port=8500
spring.cloud.consul.discovery.service-name=payment-service
spring.cloud.consul.discovery.enabled=true
spring.cloud.consul.discovery.register=true
spring.cloud.consul.discovery.healthCheckPath=/actuator/health
Тепер, для того, щоб клієнт дізнався про всі сервіси та їхні порти, це важко, коли у нас є кілька сервісів, тому й приходить API шлюз, де ми можемо мати центральну точку доступу до них…
Реалізація API шлюзу
Тепер, щоб керувати мікросервісами, ми можемо запитувати шлюз, який, у свою чергу, буде взаємодіяти з мікросервісами і повертати результат для нас.
Spring Cloud Gateway
Конфігурація:
spring.cloud.consul.host=127.0.0.1
spring.cloud.consul.port=8500
spring.cloud.consul.discovery.service-name=shopping-service
spring.application.name=gateway
server.port=8095
spring.cloud.consul.host=127.0.0.1
spring.cloud.consul.port=8500
spring.cloud.gateway.discovery.locater.enabled=true
spring.cloud.gateway.discovery.locater.lower-case-service-id:true
І нарешті, шлюзу необхідно мати одну важливу інформацію!
spring:
cloud:
gateway:
routes:
- id: payment-service
uri: http://localhost:9100 # Припускаючи, що ваш платіжний сервіс працює на порту 8081
predicates:
- Path=/pay/** # Усі запити, що починаються з /pay, будуть перенаправлені на платіжний сервіс
- id: shopping-service
uri: http://localhost:9090 # Припускаючи, що ваш торговий сервіс працює на порту 8082
predicates:
- Path=/shop/** # Усі запити, що починаються з /shop, будуть перенаправлені на торговий сервіс
Який шлях має обробляти хто!
Комунікація сервісів
так, зроблено..
Продовження буде з..
Інтеграція з Kong Gateway
Kong надає мовно-нейтральну альтернативу для Spring Cloud Gateway та Zuul:
- Побудовано на NGINX
- Ефективне балансування навантаження
- Інтеграція з відкриттям сервісів
- Висока продуктивність і масштабованість
Огляд архітектури
Два мікросервіси взаємодіють через інфраструктуру:
Сервіси відкриваються через Consul (8500) і доступні через Kong gateway, що дозволяє:
- Динамічне відкриття сервісів
- Балансування навантаження
- Централізоване маршрутизування
- Покращений моніторинг
Висновок
Ця архітектура поєднує переваги відкриття сервісів через Consul з можливостями API шлюзу Kong, створюючи надійну та масштабовану інфраструктуру мікросервісів. Реалізація поєднує простоту з потужними можливостями, роблячи її придатною як для розробки, так і для виробничих середовищ.
Перекладено з: Starting with Spring Cloud