應用程式部署類型
有數種方式可將 Java 應用程式部署到雲端。 此單元將探索各種選項，以讓您在下一個單元中更加了解 Azure 所提供的服務。
虛擬機器、容器或平台即服務？
主要問題是您是否想要或需要在容器內或平台即服務 (PaaS) 解決方案中的虛擬機器 (VM) 上部署您的應用程式。
透過虛擬機器，您就能身處與內部部署或傳統資料中心環境類似的世界。 Azure 為您提供一組預先設定的 VM，其執行主要的作業系統 (Windows 與 Linux)，而您必須負責設定及維護這些機器。
因為這最接近大多數企業在移至雲端之前所使用的解決方案，所以我們建議您在一開始就採用此解決方案。 他們通常會安裝自己的設定管理軟體、安裝其慣用的 Java 版本，然後以類似於過去進行的方式來執行其 Java 工作負載。
若您有經驗豐富的營運小組會進行設定及維護，而且有特定的使用案例，此 VM 解決方案就能運作良好。 例如，您可能會使用某些原生程式庫或某些專屬軟體，例如 Oracle WebLogic Server 或 IBM WebSphere Application Server。
只要使用容器，您就仍可保留 VM 的大部分控制權，且作業投入量較少。 您可以安裝自己的 Java 虛擬機器 (VM) 或某些特定軟體，而您的容器將在本機或任何雲端提供者上執行。
因為容器提供很多自由，所以會遭遇一些與 VM 相同的問題。 若您要提供自己的 JVM，則必須視需要加以更新及修補。 因此，Docker 映像需要良好的持續整合與持續傳遞 (CI/CD) 工具鏈，才能正確地維護容器。 因為 Docker 映像可在本機執行，而且比 VM 更輕量，所以也能提供絕佳的開發人員體驗。
透過平台即服務解決方案，大多數維護與作業負擔都會由雲端提供者處理。 也會提供作業系統 (OS) 更新、Java 修補檔、安全性與合規性。 因此，此選項通常更安全且成本較低。 該解決方案也隨附一些可擴縮性功能，可讓您的應用程式更適合您客戶的需求。 當流量較少時，也能實現低負載的更高效能和更低成本。
您可以透過使用 PaaS 解決方案來達成更多目標。 您可以設定自動設定、管理及載入祕密 (例如，使用 Azure Key Vault)、監視您的應用程式、啟動即時分析工作階段，以及啟用零停機部署。
部署選項
無論您使用的是 VM、容器，或是 PaaS 解決方案，通常能以兩種方式將 Java 應用程式部署到雲端：
- 原始程式碼部署：您會將原始程式碼認可到 Git 儲存機制，而雲端提供者會執行編譯、建置及封裝應用程式的程序。
- JAR、WAR 或 EAR 檔案部署: 您也可以封裝您的應用程式，通常會封裝成可執行檔 JAR (Java 封存) 檔案，但 WAR (Web 應用程式封存)、EAR (企業應用程式封存)，以及其他檔案格式也可行。 然後，雲端提供者會執行可執行檔。
這兩個部署選項是執行 Java 應用程式的傳統方式。 針對這兩個選項，組建處理序通常很類似，主要差異在於該處理序的執行位置。 透過此方法，可讓雲端提供者更輕鬆地執行組建，而雲端提供者也可以套用自己的安全性檢查與修補檔。 在本機 (或使用如 GitHub Actions 的 CI/CD 平台) 建置應用程式，您能取得更大的彈性與控制。
無伺服器函式
無伺服器函式 (或是更明確地說 Azure Functions) 是我們所見且提供非常特定功能的各種解決方案組合：無伺服器函式只能執行一段很短暫的時間。 通常，函式會由事件 (例如 HTTP 要求) 喚醒，並在數分鐘內維持在「經常性存取層」，直到回到睡眠狀態為止。
函式會與先前所述的 PaaS 解決方案共用功能。 在 Azure 中，我們的 PaaS 解決方案 (Azure App Service) 與無伺服器解決方案 (Azure Functions) 在技術上很類似，並共用一些通用的程式碼與服務。
針對部署選項，函式通常會使用 JAR 檔案。 有其他選項 (例如 Docker) 可供使用，但較不熱門，而且通常也不會執行。 這是因為基礎平台無法以與 JAR 檔案相同的方式予以最佳化。
本質上，無伺服器函式必須特別編碼。 其功能依其執行所在的雲端提供者而定，而且其短暫的生命週期會讓使用傳統解決方案 (例如快取或 HTTP 工作階段複寫) 變得複雜。
無伺服器函式可以適當地進行調整，並提供低使用量環境的最佳價格。 同時，其也可以回應需求最大的流量負載。