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

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

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

Анкета по миграции Java

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

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

• Приложения Spring:
  • Приложения Spring Boot / JAR
  • Приложения Spring, использующие модули промежуточного слоя Spring Cloud
• Приложения Java EE
• Веб-приложения
• Пакетные и/или запланированные задания.

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

Приложения 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 Виртуальные машины поддерживают все типы приложений, но им требуется, чтобы ваша команда выполняла дополнительные обязанности, как показано в следующем разделе.

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

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

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

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

Примечание.

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

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

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

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

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

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

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

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

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

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

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

Приложения Java

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

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

Назначение → Тип приложения →	Приложение Сервис Java SE	Приложение Сервис Кот	Приложение Сервис JBoss EAP	Лазурный Контейнер Приложения	АКС	Виртуальный Компьютеры
Spring Boot Приложения JAR	Руководство	Н/П	Н/П	Н/П	Н/П	Н/П
Spring Cloud приложения	Н/П	Н/П	Н/П	Н/П	Руководство Планируется	Руководство Планируется
Веб-приложения в Tomcat	Н/П	Руководство	Н/П	Руководство	Руководство	Руководство Планируется

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

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

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

См. также

• Причины перехода на Java 11 и выше
• Переход с Java 8 на Java 11
• Переход с Java 7 на Java 8