Посібник з мікросервісів Java. Частина 2: розгортання та тестування

Переклад та адаптація Java Microservices: A Practical Guide . Посилання на першу частину гайду . Будь-яка серверна Java-програма, а отже, і будь-який мікросервіс це просто файл з розширенням .jar або .war. Є одна чудова річ про екосистему Java, або, скоріше, про JVM: достатньо написати Java-код один раз, і його можна запускати майже на будь-якій операційній системі, якщо ви не скомпілювали свій код з новішою версією Java, ніж ваша цільова версія JVM . Це важливо розуміти, особливо коли йдеться про такі теми, як Docker, Kubernetes або (барабанний дріб!) The Cloud. Чому? Давайте розглянемо різні сценарії розгортання.

Приклад мінімалістичного розгортання мікросервісу Java

Продовжуємо приклад із банком. Отже, ми отримали файл monobank.jar (моноліт) та наш нещодавно витягнутий riskengine.jar (перший мікросервіс перевірки ризиків). Припустимо також, що обом програмам, як і будь-якому іншому застосунку у світі, потрібен файл .properties. У нашому випадку він міститиме лише URL бази даних та облікові дані. Мінімальне розгортання може складатися з двох каталогів, що виглядають приблизно так: Перший:

-r-r------ 1 ubuntu ubuntu     2476 Nov 26 09:41 application.properties
-r-x------ 1 ubuntu ubuntu 94806861 Nov 26 09:45 monobank-384.jar

ubuntu@somemachine:/var/www/www.monobank.com/java$ java -jar monobank-384.jar

  .   ____          _            __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
...

Другий:

-r-r------ 1 ubuntu ubuntu     2476 Nov 26 09:41 application.properties
-r-x------ 1 ubuntu ubuntu 94806861 Nov 26 09:45 risk-engine-1.jar

ubuntu@someothermachine:/var/www/risk.monobank.com/java$ java -jar risk-engine-1.jar

  .   ____          _            __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
...

Це залишає відкритим питання: як файли .properties і .jar потраплять на сервер? На жаль, відповідей може бути багато.

Як використовувати інструменти збирання, SSH та Ansible для розгортання мікросервісів Java

Нудна, але від цього не менш прекрасна порада про те, як розгортати Java-мікросервіси… Власне, так само, як системні адміністратори розгортали будь-яку серверну Java-програму в компаніях за останні 20 років. Це мікс:

• вашого улюбленого інструменту для збирання (Maven, Gradle)
• старого доброго SSH/SCP для копіювання .jars на сервери
• сценаріїв Bash для керування сценаріями розгортання та серверами
• або навіть краще: деякі скрипти Ansible.

Зрозуміло, це не підійде новаторам, яким потрібна "хмара, що дихає", сервери з автоматичним балансуванням навантаження і так далі. Це справжнісінький нудний олдскул. Однак він працює!

Як використовувати Docker для розгортання мікросервісів Java

Повернімося до солодких мук вибору. Кілька років тому на сцену вийшов Docker, а разом із ним — контейнеризація. Якщо ви ніколи з ним не працювали, ось короткий опис, розрахований на кінцевих користувачів та розробників:

• Контейнер (спрощений) схожий на стару добру віртуальну машину, але "легше". Якщо вам незрозуміло, що означає “легше” у цьому контексті, ласкаво просимо вивчити цю відповідь на Stackoverflow .
• Контейнер гарантує власну переносимість. Тобто він працює де завгодно. Звучить знайомо, чи не так?

Забавно, що з урахуванням переносимості та зворотної сумісності JVM ця особливість не здається такою перевагою. Ви можете просто завантажити JVM.zip на будь-якому Raspberry Pi (та хоч на мобільному телефоні), розпакувати його та запустити будь-який файл .jar. Ситуація змінюється, якщо говорити про такі мови, як PHP або Python, де несумісність версій або налаштування розгортання складніші. Або якщо ваш Java-додаток залежить від багатьох інших встановлених служб (з правильними номерами версій): наприклад, база даних Postgres, або сховище значень ключів Redis. Отже, основна перевага Docker для мікросервісів Java, а точніше для Java-додатків, полягає в наступному: можливість налаштування гомогенізованих середовищ тестування або інтеграції за допомогою таких інструментів, як Testcontainers. Складні розгортки простіше в установці. Візьміть програмне забезпечення форуму Discourse . Ви можете встановити його одним чином Docker, а той містить все, що потрібно: від програмного забезпечення Discourse, написаного на Ruby, до бази даних Postgres, до Redis і кухонної раковини. Якщо ваші файли, що розгортаються, схожі або ви хочете запустити маленьку гарну базу даних Oracle, спробуйте Docker. Отже, щоб підбити підсумок, замість простого перегляду файлу .jar, ви тепер:

• об'єднайте ваш jar-файл у образ Docker
• передайте цей образ до приватного Docker-реєстру
• витягніть та запустіть цей образ на вашій цільовій платформі
• або скопіюєте образ Docker прямо у вашу прод-систему та запустіть його.

Як використовувати Docker Swarm або Kubernetes для розгортання мікросервісів Java

Допустимо, ви вирішабо випробувати Docker. Щоразу, коли ви розгортаєте Java-мікросервіс, ви створюєте образ Docker, який поєднує ваш файл .jar. Нехай у вас є пара таких мікросервісів Java, і ви хочете розгорнути ці служби на декількох машинах (у кластері). Виникає питання: як управляти цим кластером? Запускати контейнери Docker, перевіряти працездатність, розгортати поновлення, масштабувати систему (бррр)? Дві можливі відповіді на це запитання — Docker Swarm та Kubernetes. Детальний опис обох варіантів занадто затягне це і без того довгий посібник, проте вважаємо важливим згадати, що обидва варіанти зрештою покладаються на те, що ви пишете YAML-файли (див. розповіді про відступи Yaml) для керування вашим кластером. Якщо хочете знати, які почуття це викликає на практиці, просто вбийте у пошук Twitter такий запит. Таким чином, процес розгортання для ваших мікросервісів Java тепер виглядає приблизно так:

• Налаштування та керування Docker Swarm/Kubernetes
• Усі кроки по Docker (див. вище)
• Пишіть і виконуйте YAML, поки ваші очі не заплющуть поки все не запрацює.

Як протестувати мікросервіси Java

Припустимо, ви вирішабо впровадити мікросервіси у продакшн. Як тепер протестувати інтеграцію n-мікросервісів під час розробки? Як побачити, чи працює повний робочий процес, а не лише окремі його частини? На практиці можна застосувати один із трьох способів:

1. Небагато попрацювавши (якщо ви використовуєте фреймворки, такі як Spring Boot), ви можете об'єднати всі ваші мікросервіси в один клас запуску та завантажити всі мікросервіси за допомогою одного класу Wrapper.java — залежно від того, чи достатньо пам'яті на вашому комп'ютері для запуску всіх ваших мікросервісів.
2. Ви можете скопіювати налаштування Docker Swarm або Kubernetes локально.
3. Просто більше не проводьте інтеграційні випробування локально. Натомість розгорніть спеціальне середовище DEV/TEST. Це те, що насправді робить чимало команд, що піддаються біль локальних мікросервісних установок.

Крім того, на додаток до мікросервісів Java вам, ймовірно, також знадобиться працюючий брокер повідомлень (наприклад, ActiveMQ або RabbitMQ) або, можливо, сервер електронної пошти або будь-який інший компонент обміну повідомленнями, з яким ваші мікросервіси Java повинні взаємодіяти один з одним. Це призводить до значного зниження складності на стороні DevOps. Погляньте на Microservice Testing Libraries, вони можуть пом'якшити цей біль. У будь-якому випадку, ця складність призводить до загальних проблем мікросервісів, про які ми поговоримо прямо зараз. Наприкінці ми розберемо загальні питання про мікросервіси Java .