Перенос Java-приложений в Azure

В этой статье представлен обзор рекомендуемых стратегий переноса приложений Java в Azure.

В этом руководстве по миграции рассматриваются распространенные сценарии работы с Java в Azure, а также общие рекомендации и советы по планированию миграции. Если вы хотите обсудить конкретный сценарий миграции приложений Java с командой Microsoft Java в Azure, заполните следующую анкету, а представитель свяжется с вами.

Определение типа приложения

Прежде чем выбрать для приложения Java место назначения в облаке, необходимо указать тип этого приложения. Большинство приложений Java относятся к одному из следующих типов:

Эти типы описаны в следующих разделах.

Приложения Spring Boot (JAR)

Многие новые приложения вызываются непосредственно из командной строки. Эти приложения по-прежнему обрабатывают веб-запросы, но вместо того чтобы ожидать обработки запросов HTTP от сервера приложений, они включают связь по HTTP и все остальные зависимости непосредственно в пакет приложения. Эти приложения часто создаются с помощью таких платформ, как Spring Boot, Dropwizard, Micronaut, MicroProfile, Vert.x и т. д.

Эти приложения упаковываются в архивы с расширением .jar (JAR-файлы).

Приложения Spring, использующие модули по промежуточного слоя Spring Cloud

Стиль архитектуры микрослужб — это подход к разработке одного приложения в виде набора небольших служб. Каждая служба выполняется в собственном процессе и взаимодействует с помощью упрощенных механизмов, часто API ресурсов HTTP. Эти службы, созданные на основе бизнес-возможностей, могут независимо развертываться с помощью полностью автоматизированного механизма развертывания. Существует не менее централизованного управления этими службами, которые могут быть написаны на разных языках программирования и использовать различные технологии хранения данных. Такие службы часто создаются на таких платформах, как Spring Cloud.

Эти службы упаковываются в несколько приложений с расширением .jar (JAR-файлы).

Приложения Java EE

Приложения Java EE (также называемые приложениями J2EE или более поздними приложениями Jakarta EE) могут содержать некоторые, все или ни один из элементов веб-приложений. Эти приложения также могут содержать и использовать множество дополнительных компонентов, как определено спецификацией Jakarta EE.

Приложения Java EE могут упаковываться в архивы с расширением .ear (EAR-файлы) или .war (WAR-файлы).

Приложения Java EE должны развертываться на серверах приложений, совместимых с Java EE (например, Oracle WebLogic Server, IBM WebSphere, JBoss EAP, GlassFish, Payara и т. д.).

Приложения, в которых используются только функции, предоставляемые спецификацией Java EE (то есть приложения, независимые от сервера приложений), можно переносить с одного совместимого сервера приложений на другой. Если приложение зависит от конкретного сервера приложений, возможно, вам потребуется выбрать целевую службу Azure, в которой можно разместить этот сервер приложений.

Веб-приложения

Веб-приложения выполняются в контейнере сервлетов. Некоторые из этих приложений используют API-интерфейсы сервлета напрямую, а многие используют другие платформы, которые инкапсулируют API-интерфейсы сервлета, такие как Apache Struts, Spring MVC, JavaServer Face (JSF) и другие.

Веб-приложения упаковываются в архивы с расширением .war (WAR-файлы).

Пакетные или запланированные задания

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

Эти приложения упаковываются в архивы с расширением .jar (JAR-файлы).

Примечание.

Если для выполнения запланированных задач в приложении используется планировщик (например, Spring Batch или Quartz), настоятельно рекомендуем учитывать, что такие задачи могут запускаться вне приложения. Если приложение масштабируется до нескольких экземпляров в облаке, одно и то же задание будет выполняться несколько раз. Кроме того, если в вашем механизме планирования используется местный часовой пояс главного компьютера, вы можете столкнуться с нежелательным поведением при масштабировании приложения по регионам.

Выбор целевой службы Azure

В следующих разделах показано, какие целевые службы соответствуют требованиям вашего приложения и какие обязанности с ними связаны.

Таблица с вариантами размещения

Приведенная ниже таблица поможет вам определить потенциальные назначения для определенного типа приложений. Как видно, Служба Azure Kubernetes (AKS) и Azure Виртуальные машины поддерживают все типы приложений, но им требуется, чтобы ваша команда выполняла дополнительные обязанности, как показано в следующем разделе.

Назначение →

Тип приложения →
Приложение
Service
Java SE
Приложение
Service
Tomcat
Приложение
Service
JBoss EAP
Azure
Spring
Приложения
Приложения-контейнеры Azure AKS Виртуальная
Компьютеры
Приложения Spring Boot (JAR)
Приложения Spring Cloud
Веб-приложения
Приложения Java EE
Коммерческие серверы приложений
(например, Oracle WebLogic Server или IBM WebSphere)
Долгосрочное хранение в локальной файловой системе
Кластеризация на уровне сервера приложений
Пакетные или запланированные задания
интеграция виртуальной сети и гибридные подключения;
Доступность по регионам Azure Сведения Сведения Сведения Сведения Сведения Сведения Сведения

Таблица текущих обязанностей

С помощью следующей таблицы можно выяснить, какие обязанности будут возложены на вашу команду после миграции в зависимости от целевого расположения.

Задачи, указанные с Azure помощью Azure, полностью или в основном управляются. Ваша команда отвечает на постоянной основе за задачи, указанные в 👉. Рекомендуем внедрить надежный автоматизированный процесс для выполнения всех этих обязанностей.

Примечание.

Этот список обязанностей не является исчерпывающим.

Назначение →

Задача →
Приложение
Service
Azure
Spring
Приложения
Azure
Контейнер
Приложения
AKS Виртуальная
Компьютеры
Обновление библиотек
(включая устранение уязвимостей)
👉 👉 👉 👉 👉
Обновление сервера приложений
(включая устранение уязвимостей)
Azure Azure 👉 👉 👉
Обновление среды выполнения Java
(включая устранение уязвимостей)
Azure Azure 👉 👉 👉
Активация обновлений Kubernetes
(выполняется платформой Azure с помощью ручного триггера)
Н/П Azure Azure 👉 Н/П
Аварийное восстановление Azure Azure 👉 👉 Azure
Согласование изменений в API Kubernetes, не имеющих обратной совместимости Н/П Azure 👉 👉 Н/П
Обновление базового образа контейнера
(включая устранение уязвимостей)
Н/П Azure 👉 👉 Н/П
Обновление операционной системы
(включая устранение уязвимостей)
Azure Azure Azure Azure1 👉
Обнаружение и перезапуск экземпляров после сбоя Azure Azure Azure Azure 👉
Реализация очистки и перезапуска для обновлений Azure Azure Azure Azure 👉
Управление инфраструктурой Azure Azure 👉 👉 👉
Мониторинг и управление оповещениями 👉 👉 👉 👉

1 Некоторые обновления системы безопасности могут потребовать перезагрузки узла, которые не выполняются автоматически. Дополнительные сведения см. в разделе "Применение обновлений системы безопасности и ядра" к узлам Linux в Служба Azure Kubernetes (AKS).

Если вы развертываете контейнер сервлетов (например, Spring Boot) в составе своего приложения, вы должны рассматривать его как библиотеку и, следовательно, всегда нести за это ответственность.

Обеспечение подключений в локальной среде

Если вашему приложению требуется доступ к какой-либо из локальных служб, вам необходимо подготовить одну из служб подключения Azure. Дополнительные сведения см. в статье Выбор решения для подключения локальной сети к Azure. Кроме того, необходимо выполнить рефакторинг приложения, чтобы использовать общедоступные API-интерфейсы, предоставляемые локальными ресурсами.

Это нужно сделать до начала миграции.

Инвентаризация текущей емкости и потребления ресурсов

Документируйте оборудование текущих рабочих серверов, а также среднее и пиковое количество запросов и потребление ресурсов. Эти сведения понадобятся вам для подготовки ресурсов в целевой службе.

Руководство по миграции

С помощью следующей таблицы можно найти руководство по миграции в зависимости от типа приложения и целевой службы Azure.

Приложения Java

В строках ниже можно найти нужный тип приложения Java, а в столбцах — целевую службу Azure, в которой будет размещено ваше приложение.

Если вы хотите перенести приложение JBoss EAP в Tomcat в Службе приложений, сначала преобразуйте приложение Java EE в веб-приложения Java (сервлеты), выполняющиеся на Tomcat, а затем следуйте инструкциями из приведенных ниже руководств.

Если вы хотите перенести веб-приложение в Tomcat в Azure Spring Apps, сначала преобразуйте приложение в приложения Spring Cloud, а затем следуйте приведенным ниже инструкциям.

Назначение →

Тип приложения →
Приложение
Service
Java SE
Приложение
Service
Tomcat
Приложение
Service
JBoss EAP
Azure
Контейнер
Приложения
Azure
Spring
Приложения
AKS Виртуальная
Компьютеры
Приложения
Spring Boot (JAR)
Неприменимо Н/Д Н/Д Неприменимо Руководство Неприменимо Неприменимо
Spring Cloud
applications
Неприменимо Н/Д Н/Д Неприменимо Руководство Руководство
Планируется
Руководство
Планируется
Веб-приложения
в Tomcat
Н/П Руководство Н/П Руководство Н/П Руководство Руководство
Планируется

Приложения Java EE

В строках ниже указаны типы приложений Java EE, выполняющиеся на определенном сервере приложений. В столбцах можно найти целевую службу Azure, в которой будет размещено ваше приложение.

Назначение →

Сервер приложений →
Приложение
Service
Java SE
Приложение
Service
Tomcat
Приложение
Service
JBoss EAP
Azure
Контейнер
Приложения
Azure
Spring
Приложения
AKS Виртуальная
Компьютеры
WildFly /
JBoss AS
Неприменимо Неприменимо Руководство Неприменимо Неприменимо Руководство Руководство
Планируется
Oracle WebLogic Server Неприменимо Неприменимо Руководство Неприменимо Неприменимо Руководство Руководство
IBM WebSphere Неприменимо Неприменимо Руководство Неприменимо Неприменимо Руководство Руководство
Планируется
Red Hat JBoss EAP Неприменимо Неприменимо Руководство Неприменимо Неприменимо Руководство Руководство

См. также