Перенос Java-приложений в Azure
В этой статье представлен обзор рекомендуемых стратегий переноса приложений Java в Azure.
В этом руководстве по миграции рассматриваются распространенные сценарии работы с Java в Azure, а также общие рекомендации и советы по планированию миграции. Если вы хотите обсудить конкретный сценарий миграции приложений Java с командой Microsoft Java в Azure, заполните следующую анкету, а представитель свяжется с вами.
Определение типа приложения
Прежде чем выбрать для приложения Java место назначения в облаке, необходимо указать тип этого приложения. Большинство приложений Java относятся к одному из следующих типов:
- Приложения Spring:
- Приложения 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 Виртуальные машины поддерживают все типы приложений, но им требуется, чтобы ваша команда выполняла дополнительные обязанности, как показано в следующем разделе.
Назначение → Тип приложения → |
Приложение 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 | Сведения | Сведения | Сведения | Сведения | Сведения | Сведения |
Таблица текущих обязанностей
С помощью следующей таблицы можно выяснить, какие обязанности будут возложены на вашу команду после миграции в зависимости от целевого расположения.
Задачи, указанные с Azure помощью Azure, полностью или в основном управляются. Ваша команда отвечает на постоянной основе за задачи, указанные в 👉. Рекомендуем внедрить надежный автоматизированный процесс для выполнения всех этих обязанностей.
Примечание.
Этот список обязанностей не является исчерпывающим.
Назначение → Задача → |
Приложение Service |
Azure Контейнер Приложения |
AKS | Виртуальная Компьютеры |
---|---|---|---|---|
Обновление библиотек (включая устранение уязвимостей) |
👉 | 👉 | 👉 | 👉 |
Обновление сервера приложений (включая устранение уязвимостей) |
Azure | 👉 | 👉 | 👉 |
Обновление среды выполнения Java (включая устранение уязвимостей) |
Azure | 👉 | 👉 | 👉 |
Активация обновлений Kubernetes (выполняется платформой Azure с помощью ручного триггера) |
Н/П | Azure | 👉 | Н/П |
Аварийное восстановление | Azure | 👉 | 👉 | Azure |
Согласование изменений в API Kubernetes, не имеющих обратной совместимости | Н/П | 👉 | 👉 | Н/П |
Обновление базового образа контейнера (включая устранение уязвимостей) |
Н/П | 👉 | 👉 | Н/П |
Обновление операционной системы (включая устранение уязвимостей) |
Azure | Azure | Azure1 | 👉 |
Обнаружение и перезапуск экземпляров после сбоя | 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, а затем следуйте инструкциями из приведенных ниже руководств.
Назначение → Тип приложения → |
Приложение Service Java SE |
Приложение Service Tomcat |
Приложение Service JBoss EAP |
Azure Контейнер Приложения |
AKS | Виртуальная Компьютеры |
---|---|---|---|---|---|---|
Приложения Spring Boot (JAR) |
Н/П | Н/П | Н/П | Н/П | Н/П | Н/П |
Spring Cloud applications |
Н/П | Н/П | Н/П | Н/П | Руководство Планируется |
Руководство Планируется |
Веб-приложения в Tomcat |
Н/П | Руководство | Н/П | Руководство | Руководство | Руководство Планируется |
В строках ниже указаны типы приложений 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 | Н/П | Н/П | Руководство | Н/П | Руководство | Руководство |