Поделиться через


Перенос 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 AKS Виртуальная
Компьютеры
Приложения Spring Boot (JAR)
Приложения Spring Cloud
Веб-приложения (WAR)
Приложения Java EE (WAR | EAR)
Коммерческие серверы приложений
(например, Oracle WebLogic Server или IBM WebSphere)
Кластеризация на уровне сервера приложений
Пакетные или запланированные задания
интеграция виртуальной сети и гибридные подключения;
Доступность по регионам Azure Сведения Сведения Сведения Сведения Сведения Сведения

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

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

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

Примечание.

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

Назначение →

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

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

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

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

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

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

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

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

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

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

Приложения Java

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

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

Назначение →

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

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

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

Назначение →

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

См. также