Масштабирование микросервисов Java EE в OpenShift

В первых двух частях этой небольшой серии мы создали крошечный сервис JAX-RS с WildFly Swarm и упаковали его в образ Docker . Вы узнали, как развернуть этот пример в OpenShift, и теперь пришло время немного его увеличить.

Почему масштабирование важно

Одним из ключевых аспектов архитектур на основе микросервисов является разложение на высокопроизводительные отдельные сервисы, которые масштабируются по требованию и технически просты. Приложения в настоящее время создаются для масштабирования, а инфраструктура прозрачно помогает там, где это необходимо. В то время как разработчики Java EE в прошлом делали это с помощью стандартного горизонтального масштабирования, размещая больше физических блоков рядом друг с другом или ограничивая вертикальное масштабирование, увеличивая количество экземпляров на одном хосте. Микросервисы допускают разные подходы к масштабированию. Гораздо более полное определение различных вариантов масштабирования можно найти в книге «Искусство масштабируемости» . Я собираюсь покопаться в разных подходах в будущих постах. Чтобы сделать процесс масштабирования немного проще, мы собираемся масштабировать наше крошечное приложение по вертикали, раскрутив для этого больше модулей.

Что такое стручок

Модуль (например, модуль «кит» или «горох») — это объект Kubernetes, который соответствует совместной группе приложений, работающих с общим контекстом. В терминах конструкций Docker модуль состоит из объединенной группы контейнеров Docker с общими томами. В мире до контейнера они выполнялись бы на одном физическом или виртуальном хосте. Итак, вот что мы хотим масштабировать в этом примере. Стручок, который уже запущен.

Что мы сделали до сих пор?

Когда вы впервые развернули пример JAX-RS, OpenShift создал кучу ресурсов. А именно:

• Imagestream : Поток изображения похож на хранилище изображений Docker в том, что он содержит одно или несколько изображений Docker, идентифицированных тегами. OpenShift хранит полные метаданные о каждом изображении (например, команда, точка входа, переменные среды и т. Д.). Изображения в OpenShift неизменны. Компоненты OpenShift, такие как сборки и развертывания, могут наблюдать за потоком изображений и получать уведомления при добавлении новых образов, реагируя, например, на сборку или развертывание.
• Сервис : сервис Kubernetes служит внутренним балансировщиком нагрузки. Он идентифицирует набор реплицированных модулей для прокси-соединений, которые он получает к ним.
• DeploymentConfig : Опираясь на контроллеры репликации, OpenShift добавляет расширенную поддержку жизненного цикла разработки и развертывания программного обеспечения с концепцией развертываний. Развертывания OpenShift также предоставляют возможность перехода от существующего развертывания образа к новому, а также определяют перехватчики, которые должны выполняться до или после создания контроллера репликации.

Таким образом, служба передает наш запрос модулям, а конфигурация развертывания создается поверх контроллера репликации Kubernetes, который контролирует количество модулей. Мы приближаемся!

Масштабируйте Мой Микросервис сейчас, пожалуйста!

Таким образом, на секунду дольше: в то время как сервисы обеспечивают маршрутизацию и балансировку нагрузки для модулей, которые могут мигать как во время, так и вне их существования, ReplicationControllers (RC) используются для указания и применения количества модулей (реплик), которые должны существовать. Можно предположить, что RC живут на том же уровне, что и Сервисы, но они предоставляют различные функциональные возможности по сравнению с модулями. RC — это объект Kubernetes. OpenShift предоставляет объект-оболочку поверх RC, называемый конфигурацией развертывания (DC). Контроллеры домена не только включают RC, но и позволяют вам определять, как происходят переходы между изображениями, а также ловушки после развертывания и другие действия по развертыванию.

Мы наконец-то знаем, где искать. Давайте покажем, как выглядит DeploymentConfig, который мы создали, когда запустили наш образ Swarm-sample.

Несмотря на то, что RC контролируют масштабирование модулей, они заключены в более высокую конструкцию DeploymentConfig, которая также определяет, когда, где и как будут развернуты эти модули / модули. Мы все еще можем видеть основной RC: (примечание: вывод усечен)

И теперь нам нужно знать, работает ли любое масштабирование, которое мы собираемся сделать. Я нажал небольшой сценарий скручивания , который выводит результат из конечной точки JAX-RS и спит в течение 2 секунд, прежде чем он снова запрашивает вывод. Запустите его и просмотрите результат, возвращающий одну и ту же переменную среды hostname, пока не выполните следующую команду:

Теперь все меняется, и через некоторое время вы видите три разных имени хоста. Это может занять некоторое время (в зависимости от вашей машины и от того, насколько быстро OpenShift может раскрутить новые модули). Вы также можете увидеть изменения в консоли администратора, где теперь отображаются три модуля.

Мы можем вернуть поведение, установив счетчик реплик обратно в 1.

Это было просто. И не совсем считается лучшей практикой. Поскольку все модули имеют одинаковый контекст, они никогда не должны запускаться на одной физической машине. Вместо этого было бы лучше запустить полный микросервис (внешний интерфейс, серверную часть, базу данных) на трех модулях в пределах одного RC. Но это тема для новых постов в блогах. Теперь вы узнали, как масштабировать модули в OpenShift, и мы можем продолжать развивать наше примерное приложение и делать больше примеров масштабирования позже.