共用方式為

將 Java 應用程式遷移至 Azure

  • 發行項

本文提供將 Java 應用程式遷移至 Azure 的建議策略概觀。

此移轉指引旨在涵蓋 Azure 案例上的主流 Java，並提供高階規劃建議和考慮。 如果您想要與 Azure 小組上的 Microsoft Java 討論特定的 Java 應用程式移轉案例，請填寫下列問卷，並代表會與您連絡。

Java 移轉問卷

識別應用程式類型

選取 Java 應用程式的雲端目的地之前，您必須識別其應用程式類型。 大部分的 Java 應用程式都是下列其中一種類型：

下列各節將說明這些類型。

Spring Boot / JAR 應用程式

許多較新的應用程式會直接從命令行叫用。 這些應用程式仍會處理 Web 要求，但與其依賴應用程式伺服器來提供 HTTP 要求處理，而是將 HTTP 通訊和所有其他相依性直接納入應用程式套件中。 這類應用程式經常使用 Spring Boot、Dropwizard、Micronaut、MicroProfile、Vert.x 等架構來建置。

這些應用程式會封裝成具有 .jar 擴展名 （JAR 檔案） 的封存。

使用 Spring Cloud 中間件模組的 Spring 應用程式

微服務架構樣式方法旨在開發由一組小型服務所組成的單一應用程式。 每個服務皆依照其本身的流程執行，並使用輕量型機制 (通常是 HTTP 資源 API) 進行通訊。 這些服務是以商務功能為基礎所建置，且可透過完全自動化的部署機制獨立部署。 這些服務的集中式管理最少，可能以不同的程式設計語言撰寫，並使用不同的數據儲存技術。 這類服務經常使用 Spring Cloud 等架構來建置。

這些服務會封裝成具有.jar擴展名 （JAR 檔案） 的多個應用程式。

Java EE 應用程式

Java EE 應用程式（也稱為 J2EE 應用程式，或最近，Jakarta EE 應用程式）可以包含一些、全部或沒有任何 Web 應用程式的元素。 這些應用程式也可以包含和使用 Jakarta EE 規格所定義的更多元件。

Java EE 應用程式可以封裝為擴展名 為 .ear 擴展名的封存（EAR 檔案），或封裝為擴展名 為 .war 的封存（WAR 檔案）。

Java EE 應用程式必須部署到 Java EE 相容的應用程式伺服器（例如 Oracle WebLogic Server、IBM WebSphere、JBoss EAP、GlassFish、Payara 等等）。

只依賴 Java EE 規格所提供的功能的應用程式（也就是與應用程式伺服器無關的應用程式）可以從一部相容的應用程式伺服器移轉至另一部應用程式伺服器。 如果您的應用程式相依於特定應用程式伺服器（應用程式伺服器相依），您可能需要選取可讓您裝載該應用程式伺服器的 Azure 服務目的地。

Web 應用程式

Web 應用程式會在 Servlet 容器內執行。 其中有些應用程式會直接使用 servlet API，而許多應用程式則使用封裝 servlet API 的其他架構，例如 Apache Struts、Spring MVC、JavaServer Face （JSF）和其他架構。

Web 應用程式會封裝成擴展名 為 .war 的封存（WAR 檔案）。

Batch / scheduled jobs

某些應用程式的目的是要短暫執行、執行特定工作負載，然後結束，而不是等候要求或用戶輸入。 有時候這類作業需要以一次或定期的排程間隔執行。 在內部部署中，這類作業通常會從伺服器的 crontab 叫用。

這些應用程式會封裝成具有 .jar 擴展名 （JAR 檔案） 的封存。

注意

如果您的應用程式使用排程器（例如 Spring Batch 或Tzing）來執行排程工作，強烈建議您考慮在應用程式外部執行這類工作。 如果您的應用程式調整為雲端中的多個實例，相同的作業將會多次執行。 此外，如果您的排程機制使用主機的本機時區，當您跨區域調整應用程式時，可能會遇到不想要的行為。

選取目標 Azure 服務目的地

下列各節將說明哪些服務目的地符合您的應用程式需求，以及它們所牽涉到哪些責任。

裝載選項方格

使用下列方格來識別應用程式類型的潛在目的地。 如您所見，Azure Kubernetes Service （AKS） 和 Azure 虛擬機器 支援所有應用程式類型，但需要您的小組承擔更多責任，如下一節所示。

目的地→

應用程式類型 \		 App
服務
Java SE		 App
服務
Tomcat		 App
服務
JBoss EAP		 Azure 容器應用程式 AKS 虛擬
機器
Spring Boot / JAR 應用程式 ✔ ✔ ✔ ✔
Spring Cloud 應用程式 ✔ ✔ ✔ ✔ ✔
Web 應用程式 （WAR） ✔ ✔ ✔ ✔ ✔
Java EE 應用程式 （WAR |EAR） ✔ ✔ ✔ ✔
商業應用程式伺服器
（例如 Oracle WebLogic Server 或 IBM WebSphere）		 ✔ ✔ ✔
應用程式伺服器層級叢集 ✔ ✔ ✔
Batch / scheduled jobs ✔ ✔ ✔
VNet 整合/混合式連線 ✔ ✔ ✔ ✔ ✔ ✔
Azure 區域可用性 詳細資料 詳細資料 詳細資料 詳細資料 詳細資料 詳細資料

持續的責任方格

使用下列方格瞭解移轉后，每個目的地在小組上的責任。

使用 Azure 指示的工作完全或大部分由 Azure 管理。 您的小組會持續負責使用 👉所指示的工作。 建議您實作健全且高度自動化的程式，以履行所有這類責任。

注意

這不是責任的詳盡清單。

目的地→

工作 ...		 App
服務		 Azure
容器
應用程式		 AKS 虛擬
機器
更新連結庫
（包括弱點補救）		 👉 👉 👉 👉
更新應用程式伺服器
（包括弱點補救）		 Azure 👉 👉 👉
更新 Java 執行時間
（包括弱點補救）		 Azure 👉 👉 👉
觸發 Kubernetes 更新
（由 Azure 使用手動觸發程式執行）		 N/A Azure 👉 N/A
災害復原 Azure 👉 👉 Azure
協調非回溯相容的 Kubernetes API 變更 N/A 👉 👉 N/A
更新容器基底映像
（包括弱點補救）		 N/A 👉 👉 N/A
更新作業系統
（包括弱點補救）		 Azure Azure Azure1 👉
偵測和重新啟動失敗的實例 Azure Azure Azure 👉
針對更新實作清空和輪流重新啟動 Azure Azure Azure 👉
基礎結構管理 Azure 👉 👉 👉
監視和警示管理 👉 👉 👉 👉

1 某些安全性更新可能需要節點重新啟動，但不會自動完成。 如需詳細資訊，請參閱 將安全性和核心更新套用至 Azure Kubernetes Service （AKS） 中的 Linux 節點。

如果您將 servlet 容器（例如 Spring Boot）部署為應用程式的一部分，您應該將其視為連結庫，因此一律會負責。

確保內部部署連線能力

如果您的應用程式需要存取您的任何內部部署服務，您必須佈建其中一個 Azure 連線能力服務。 如需詳細資訊，請參閱將內部部署網路連線至 Azure。 或者，您必須重構應用程式，以使用內部部署資源所顯示的公開可用 API。

開始任何移轉之前，您應該先完成這項工作。

清查目前的容量和資源使用量

記錄目前生產伺服器的硬體，加上平均和尖峰要求計數和資源使用量。 您需要此資訊，才能在服務目的地中布建資源。

移轉指引

使用下列方格依應用程式類型和目標 Azure 服務目的地尋找移轉指引。

Java 應用程式

使用下列資料列來尋找 Java 應用程式類型和資料行，以尋找將裝載應用程式的 Azure 服務目的地。

如果您想要將 JBoss EAP 應用程式移轉至 App Service 上的 Tomcat，請先將 Java EE 應用程式轉換為 Tomcat 上執行的 Java Web Apps（servlets），然後遵循下列指示。

目的地→

應用程式類型 \		 App
服務
Java SE		 App
服務
Tomcat		 App
服務
JBoss EAP		 Azure
容器
應用程式		 AKS 虛擬
機器
Spring Boot /
JAR 應用程式		 N/A N/A N/A N/A N/A N/A
Spring Cloud /
應用程式		 N/A N/A N/A N/A 指導
計劃		 指導
計劃
Web 應用程式
on Tomcat		 N/A 指導 N/A 指導 指導 指導
計劃

Java EE 應用程式

使用下列數據列來尋找在特定應用程式伺服器上執行的 Java EE 應用程式類型。 使用資料行來尋找將裝載應用程式的 Azure 服務目的地。

目的地→

應用程式伺服器 \		 App
服務
Java SE		 App
服務
Tomcat		 App
服務
JBoss EAP		 Azure
容器
應用程式		 AKS 虛擬
機器
WildFly /
JBoss AS		 N/A N/A 指導 N/A 指導 指導
計劃
Oracle WebLogic Server N/A N/A 指導 N/A 指導 指導
IBM WebSphere N/A N/A 指導 N/A 指導 指導
計劃
Red Hat JBoss EAP N/A N/A 指導 N/A 指導 指導

另請參閱