Інструменти Spring Cloud: знайомимось із Gateway, Config Server, Config Bus та Spring Data Flow

Дмитро Чоломбитько, Full Stack Developer в NIX

Продовжую знайомити вас з інструментами Spring Cloud. Сьогодні зупинимось детальніше на конкретних практичних речах.

Spring Cloud Gateway

Якщо ви працювали у хмарі, то напевно стикалися з такою проблемою…

Буває складно забезпечити доступ до особливих API всередині хмарної інфраструктури або поєднати різні розподілені API в одну спільну. Наприклад, вам потрібно зібрати воєдино API до внутрішніх ресурсів та API до систем інших провайдерів. З цим допоможе Spring Cloud Gateway.

Можливості Spring Cloud Gateway не обмежуються цією функціональністю. Також він може менеджерити безпеку. Це відбувається за рахунок єдиного способу авторизації для всіх API. Адже доступ здійснюватиметься лише через цей шлюз. Також цей інструмент дозволяє збирати метрики та моніторити систему.

У Spring Cloud Gateway можна гнучко налаштувати роутинг до кожного API. Це робиться за допомогою шляхів, параметрів, навіть за вмістом request body або за зразком хедерів. Пропоную поглянути, як це працює. Для прикладу працюватимемо у зв'язці з проєктом Circuit Breaker.

Це реалізація однойменного патерна програмування. Його суть полягає у простій обробці помилок та управлінні стабільністю застосунку та інфраструктури загалом. Фактично це перемикач. При появі проблеми він перенаправляє нас на інший ендпойнт або мок, які можуть підтримати систему в робочому стані, поки сервіс, що впав, не відновиться. Можливо, не варто покладатися лише на таке рішення. Але для критичних точок, які важко контролювати, це часто єдиний можливий вихід.

Існує чотири реалізації Circuit Breaker:

Роботу Circuit Breaker у зв'язці зі Spring Cloud Gateway я розберу ще на одному прикладі зі стандартним проєктом.

У ньому є залежність від Spring Cloud Gateway.

Все це працює на WebFlux. А ще тут використовується Resilence4J. Саме на нього зараз рекомендується переходити при використанні Circuit Breaker.

Також зверну увагу на React-версію (через WebFlux) та актуатор за стандартом. А ось проперті тут порожні. У Spring Cloud Gateway можна задавати конфігурацію двома способами: через проперті та через Java. Я покажу другий спосіб.

Та для початку поясню суть цього прикладу. Припустимо, ми маємо дві API у вигляді простих мікросервісів. Вони повертають деякі дані з бази, і треба зв'язати їх у єдину API. Одна з них надсилає випадкове жіноче або чоловіче прізвище.

Друга API видає випадкове ім'я, також чоловіче чи жіноче.

У Gateway є три класи. Перший — стандартний main.

Підписуйтеся на наші соцмережі

Другий — це конфігурація роутингу. В нашому випадку вона виглядає завеликою, але для демонстрації можливостей шлюзу підійде й таке виконання.

На перший погляд, тут дуже багато фільтрів. Усе здається незрозумілим. Але насправді все достатньо просто. Коли треба позначити зв'язування з віддаленою API, насамперед слід вказати шлях, яким працюватиме Gateway.

Якщо Gateway запущений на порті 8080, це буде localhost8080/name/male. Далі переходимо до реального шляху для віддаленої API, яку ми фактично проксуємо. Це потрібно вказати через uri.

Якби у нас не було гарного фільтра, система просто підставила би name/male на адресу після localhost8080, після адреси name-мікросервісу.

Для прикладу я свідомо ускладнив ситуацію. Припустимо, API не збігаються повністю. Тому потрібно зробити ремапінг. Можна переписати шляхи або додати фільтр, щоб підключити Circuit Breaker. Через це rewritepath приймає регулярне вираження, яке дозволяє витягувати параметри зі шляху в Gateway. Для цього треба написати, що є name, а потім забрати все, що йде після наступного слешу, і перенести на новий шлях. Таким чином можна переробити шлях під використання в цільовій API.

Переходимо до Circuit Breaker. Нижче зображена реалізація обробника помилок, який перемикатиме нас при отриманні запитів 404, 500 або 504. За потреби можете вказати будь-які інші коди.

Також треба вказати, куди все це пересилатиметься. Для цього я використовую мок усередині Gateway — це fallback endpoint.

З появою помилки у відправленні випадкового чоловічого імені повертатиметься лише одне ім'я — я задав «Артур». Щойно мікросервіс відновиться, все працюватиме, як слід.

Після запуску у браузері можна оцінити результати роботи системи.

Аналогічно працюють і жіночі імена. Все це підтверджує коректне налаштування Spring Cloud Gateway та мікросервісів на портах 8090 та 8091.

Але припустимо, щось зламалося, скажімо, на отриманні імені. Для симуляції розкоментуємо цю помилку і перебілдимо мікросервіс.

Реакція перемикача передбачувана: при зверненні до браузера ми бачимо лише ім'я Артур, скільки б разів не оновлювали сторінку.

Далі виправляємо помилку та дивимося, що змінилося. Мікросервіси не пов'язані з Gateway безпосередньо, тут не використовується Discovery Server. Весь зв'язок побудований на тому, що система періодично стукається до мікросервісу і в разі виявлення помилки повертається на fallback endpoint. Після виправлення багу і відновлення роботи сервісу ми знову бачимо в браузері випадкові імена. Все працює, як і має бути.

Звісно, регулярне звернення до ендпойнту не є гарною практикою. У реальному проєкті все можна налаштувати коректніше. Наприклад, під конкретний застосунок задати тайм-аут, потрібну кількість спроб для обробника помилок тощо.

Spring Cloud Config Server

Це веб-застосунок для управління конфігураційними файлами. Особливо корисним Config Server буде за наявності автоскейлінгу, який створює інстанси та їх конфігурації без участі розробника.

Можна прокидати в хмарі конфігурації через проперті в консольних командах, але, на мій погляд, це сумнівна практика. Набагато краще використовувати готові, стандартизовані рішення. Це дозволить зберігати конфігурації в одному місці та спростить контроль доступу та версіонування. Саме таким рішенням є Spring Cloud Config Server. Як він працює?

Уявімо програму, яка хоче запуститися. Її створює, наприклад, якийсь executor, і застосунку потрібно отримати актуальну конфігурацію. Для цього йому достатньо відправити своє ім'я та потрібний список профілів на спеціальний ендпойнт у Config Server. Від нас не потрібні мануальні дії. Все просто, стабільно, безпечно.

Spring Cloud Config Server може використовувати для зберігання та вилучення проперті декілька рішень. Найчастіше це Git. Також це можуть бути версіоновані або звичайні файлові системи, бази даних, Redis, сховище Amazon S3, CredHub (якщо ви користуєтесь CloudFoundry) та ін.

Config Server передбачає шифрування для проперті, які не можна зберігати у відкритому доступі. Для цього потрібно викликати спеціальний ендпойнт у Config Server. Потім свій ключ із префіском «{cipher}» помістити у репозиторій замість проперті і зберігати це все у такому вигляді. Коли застосунок вимагатиме проперті, Config Server за допомогою ключа розшифрує все і передасть застосунку.

Існує й альтернатива від іншого вендора — Vault від HashiCorp. Це не Spring-застосунок, а сховище ентерпрайз-рівня для зберігання ключів. Його особливість — оптимізація під зашифроване розміщення ключів, як у базі даних.

Spring Cloud Config Bus

Цей інструмент дозволяє автоматично оновлювати проперті на сервісах при настанні будь-якої події. Це здійснюється за допомогою підключення Message Broker. Припустимо, ми зробили commit у Git-репозиторій, до якого підключено спеціальний WebHook. Він слухає зміни в Git і сам викликає спеціальний ендпойнт у Config Server. Потім у Message Broker з'являється повідомлення, яке слухають мікросервіси. Його поява і викликає оновлення конфігурацій. Виходить досить зручна система.

Spring Cloud для хмарних платформ

У Spring Cloud є модулі для всіх основних хмар: від AWS та Azure до GCP і навіть Alibaba. Останній активно розвивається в Китаї. Також існує модуль для Docker із Kubernetes. Кожен надає різні можливості, про які можна багато писати. Тож у межах цієї статті я наведу лише ключові функції по кожній платформі.

AWS:

Azure:

Google Cloud Platform:

Alibaba:

Kubernetes:

Spring Data Flow

Це інтегрована платформа для обробки даних. За допомогою Data Flow можна на UI налаштувати спосіб перетворення даних, що надходить від запиту HTTP. Також платформа дозволяє зберегти дані та пізніше автоматично створювати під них мікросервіси. Все відбуватиметься без вашого безпосереднього втручання. Потрібно лише змапити все, щоб платформа розуміла, що саме піднімати. Якщо немає даних — немає й сервісів. Та тільки-но дані з'явилися, то відразу через Kubernetes підіймаються кілька сервісів.

Цікаво? Усі розглянуті у статті приклади ви можете знайти на моєму репозиторії на GitHub.