Перевод и адаптация Java Microservices: A Practical Guide. Ссылка на первую часть гайда. Руководство по микросервисам Java. Часть 2: развертывание и тестирование - 1Любая серверная 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

  .   ____          _            __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
...
Telegram
Это оставляет открытым вопрос: каким образом файлы .properties и .jar попадут на сервер? Увы, ответов может быть много.

Как использовать инструменты сборки, SSH и Ansible для развертывания микросервисов Java

Скучный, но от этого не менее прекрасный совет о том, как развёртывать Java-микросервисы… Собственно, ровно так, как системные администраторы развёртывали любую серверную Java-программу в компаниях за последние 20 лет. Это микс:
  • вашего любимого инструмента для сборки (Maven, Gradle)
  • старого доброго SSH/SCP для копирования .jars на серверы
  • сценариев Bash для управления сценариями развертывания и серверами
  • или даже лучше: некоторых скриптов Ansible.
Разумеется, это не подойдёт новаторам, которым нужно “дышащее” облако, серверы с автоматической балансировкой нагрузки и так далее. Это самый настоящий скучный олдскул. Однако он работает!

Как использовать Docker для развертывания микросервисов Java

Давайте вернёмся к сладким мукам выбора. Пару лет назад на сцену вышел Docker, а вместе с ним — контейнеризация. Если вы никогда с ним не работали, вот краткое описание, рассчитанное на конечных пользователей и разработчиков:
  • Контейнер (упрощенный) похож на старую добрую виртуальную машину, но “полегче”. Если вам непонятно, что значит “полегче” в этом контексте, милости просим изучить вот этот ответ на Stackoverflow.
  • Контейнер гарантирует собственную переносимость. То есть он работает где угодно. Звучит знакомо, не так ли?
Руководство по микросервисам Java. Часть 2: развертывание и тестирование - 2Забавно, что с учётом переносимости и обратной совместимости 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

Python-университет
Предположим, вы решили внедрить микросервисы в продакшн. Как теперь протестировать интеграцию n-микросервисов во время разработки? Как увидеть, работает ли полный рабочий процесс, а не только отдельные его части? На практике можно применить один из трёх способов:
  1. Немного поработав (если вы используете фреймворки, такие как Spring Boot), вы можете объединить все ваши микросервисы в один класс запуска и загрузить все микросервисы с помощью одного класса Wrapper.java — в зависимости от того, достаточно ли памяти на вашем компьютере для запуска всех ваших микросервисов.
  2. Вы можете скопировать настройки Docker Swarm или Kubernetes локально.
  3. Просто больше не проводите интеграционные тесты локально. Вместо этого разверните специальную среду DEV/TEST. Это то, что на самом деле делает немало команд, поддающихся боли локальных микросервисных установок.
Кроме того, в дополнение к вашим микросервисам Java вам, вероятно, также понадобится работающий брокер сообщений (например, ActiveMQ или RabbitMQ) или, возможно, сервер электронной почты или любой другой компонент обмена сообщениями, с которым ваши микросервисы Java должны взаимодействовать друг с другом. Это приводит к значительному занижению сложности на стороне DevOps. Взгляните на Microservice Testing Libraries, они могут смягчить эту боль. В любом случае, эта сложность приводит нас к общим проблемам микросервисов, о которых мы поговорим прямо сейчас. В завершающей части мы разберем общие вопросы о микросервисах Java.