共用方式為

為微服務選擇 Azure 計算選項

  • 發行項

計算一詞是指您的應用程式所執行的計算資源的託管模式。 本文提供規範性指引，可協助您選擇微服務的計算平臺。 您的微服務計算平臺選擇可能會取決於更細微的需求。

針對微服務架構，下列方法很受歡迎：

  • 在專用計算平臺上部署微服務，通常是使用微服務協調器。
  • 在無伺服器平臺上部署微服務。

雖然這些選項並非唯一的選項，但它們都是建置微服務的已證實方法。 應用程式可能包含這兩種方法。

顯示 Azure 中微服務計算選項的圖表。

下載此架構的 Visio 檔案。

使用無伺服器平臺

您可以使用無伺服器平臺在 Azure Container Apps 或 Azure Functions 上部署微服務。 Container Apps 和 Functions 都提供無伺服器計算選項，可根據要求數量計費，而不是計算耗用量。 這兩個平臺也可讓您選擇在專用容量上裝載工作負載。

部署程式代碼型微服務

如果您想要將微服務部署為程序代碼，而不是將其容器化，您可能想要使用 Azure Functions。 如需詳細資訊，請參閱 Functions 所支援的程式設計和腳本語言清單。 對於以其他語言開發的微服務，您可能會想要在 Functions 中實作自定義處理程式，或考慮將應用程式容器化。

使用 GPU 模型

例如，如果您的微服務需要 GPU 容量來執行機器學習工作，請考慮為您的平台選擇 Container Apps 或 Azure Kubernetes Service （AKS）。 AKS 可以使用 Azure 中的任何 GPU 模型，而 Container Apps 提供一部分 GPU 模型可供選擇。

使用服務協調器

協調器會處理與部署和管理一組服務相關的工作。 這些工作包括將服務放在節點上、監視服務的健康情況、重新啟動狀況不良的服務、跨服務實例的網路流量負載平衡、服務探索、調整服務的實例數目，以及套用組態更新。 熱門協調器包括 Kubernetes、Azure Service Fabric、DC/OS 和 Docker Swarm。

在 Azure 平臺上，請考慮下列選項：

  • Azure Kubernetes Service (AKS) 是受控 Kubernetes 服務。 AKS 會布建 Kubernetes 並公開 Kubernetes API 端點、裝載和管理 Kubernetes 控制平面，以及執行自動化升級、自動化修補、自動調整和其他管理工作。 AKS 可讓您直接存取 Kubernetes API。

  • Container Apps 是建置在 Kubernetes 上的受控服務，可抽象化容器協調流程和其他管理工作的複雜性。 Container Apps 可簡化在無伺服器環境中容器化應用程式和微服務的部署和管理，同時提供 Kubernetes 的功能。 容器應用程式適用於不需要直接存取 Kubernetes API 的案例。

  • Service Fabric 是用於封裝、部署和管理微服務的分散式系統平臺。 您可以將微服務部署至 Service Fabric 作為容器、二進位可執行檔或 Reliable Services。 藉由使用 Reliable Services 程式設計模型，服務可以直接使用 Service Fabric 程式設計 API 來查詢系統、報告健康情況、接收有關設定和程式代碼變更的通知，以及探索其他服務。

  • 使用 Azure Red Hat OpenShift 部署完全受控的 OpenShift 叢集。 Azure Red Hat OpenShift 可擴充 Kubernetes。 Azure Red Hat OpenShift 是由 Red Hat 和 Microsoft 共同設計、運作和支援。

  • Docker Enterprise Edition 等其他選項可以在 Azure 上的雲端運算環境中執行。 您可以在 Azure Marketplace 上找到部署範本。

使用 Kubernetes API

當您選擇計算選項時，存取 Kubernetes API 通常是決定因素。 AKS 提供 Kubernetes API 的直接存取權，但 Container Apps 則不會。 Container Apps 會隱藏 Kubernetes 的複雜性，並簡化容器部署體驗。 如果您設計微服務部署以直接與 Kubernetes API 互動，AKS 可能是正確的選擇。

其他決策因素

可能還有其他因素會影響您的微服務計算平臺選取專案。 這些因素包括服務網格選項、平臺延展性和您可能在組織內使用的技能集。

考量

這些考量能實作 Azure Well-Architected Framework 的支柱，其為一組指導原則，可以用來改善工作負載的品質。 如需更多資訊，請參閱 Microsoft Azure 結構完善的架構。

可靠性

可靠性可確保您的應用程式符合您對客戶的承諾。 如需詳細資訊，請參閱可靠性的設計檢閱檢查清單。

可靠性的主要要素之一是復原能力。 復原的目標是在發生失敗之後，將工作負載傳回完整運作的狀態。

如果您選擇 Azure Functions 作為微服務運算平臺，請考慮在區域備援設定中部署 Functions Premium 方案或 Azure App 服務 方案。 如需詳細資訊，請參閱 Functions 中的可靠性。

如果您選擇 AKS 作為微服務運算平臺，您可以藉由部署 使用可用性區域的 AKS 叢集、使用 Azure Kubernetes 叢集的標準層或進階層 ，以及增加最少的 Pod 和節點數目，來增強微服務可靠性。 如需詳細資訊，請參閱 AKS 的部署和叢集可靠性最佳做法。

如果您選擇 [容器應用程式] 作為微服務運算平臺，您可以使用可用性區域來增強可靠性。 如需詳細資訊，請參閱 容器應用程式中的可靠性。

安全性

安全性可提供保證，以避免刻意攻擊和濫用您寶貴的資料和系統。 如需詳細資訊，請參閱安全性的設計檢閱檢查清單。

如果您選擇 Azure Functions 作為部署微服務的計算平臺， 則保護 Azure Functions 的原則也適用於微服務。

如果您選擇 AKS 作為部署微服務的計算平臺， AKS 安全性基準架構 會提供保護計算平臺的指引。 如需 AKS 上微服務安全性的最佳做法，請參閱 進階 AKS 微服務架構。

如果您選擇容器應用程式作為部署微服務的計算平臺，請參閱 容器應用程式 的安全性基準以取得安全性最佳做法。

成本最佳化

成本最佳化是關於考慮如何減少不必要的費用，並提升營運效率。 如需詳細資訊，請參閱成本最佳化的設計檢閱檢查清單。

當您使用協調器時，您需要為叢集中執行的虛擬機付費。 當您使用無伺服器應用程式時，您只需支付您取用的實際計算資源費用。 在這兩種情況下，您需要考慮任何額外服務的成本，例如記憶體、資料庫和傳訊服務。

Azure Functions、Container Apps 和 AKS 提供自動調整選項。 Container Apps 和 Functions 提供無伺服器平臺，其成本是以耗用量為基礎，而且可以是零。 AKS 僅提供專用的計算選項。

如果您選擇 AKS 作為部署微服務的計算平臺，您必須瞭解成本優化最佳做法。 如需詳細資訊，請參閱 將 Azure Kubernetes Service 中的成本優化。

如果您選擇容器應用程式作為微服務計算平臺，您必須瞭解各種計費模型，並根據工作負載需求決定微服務的部署模型。 如需詳細資訊，請參閱 容器應用程式中的計費。

如果您選擇 Azure Functions 作為微服務計算平臺，您必須瞭解各種計費模型，並根據工作負載需求決定 Functions 方案。 如需詳細資訊，請參閱 估計耗用量型成本和 Azure Functions 方案詳細數據。

卓越營運

卓越營運涵蓋部署應用程式並使其持續在生產環境中執行的作業流程。 如需詳細資訊，請參閱卓越營運的設計檢閱檢查清單。

您可以使用 Terraform、Bicep 和其他腳本語言，以自動化方式部署本文描述的所有微服務計算選項。 您可以使用 Application Insights、 Azure 監視器和其他監視解決方案來監視這些計算平臺和微服務。

當您選擇協調器方法與無伺服器方法時，請考慮下列因素：

  • 彈性和控制： 協調器可讓您控制設定和管理服務和叢集。 取捨比較複雜。 使用無伺服器架構時，您會放棄某種程度的控制，因為這些詳細數據會抽象化。

  • 可移植性： 本文中列出的所有協調器，包括 Kubernetes、DC/OS、Docker Swarm 和 Service Fabric，都可以在內部部署或多個公用雲端中執行。

  • 應用程式整合： 建置使用無伺服器架構的複雜應用程式可能會很困難，因為您需要協調、部署和管理許多小型獨立函式。 Azure 中的其中一個選項是使用 Azure Logic Apps 來協調一組 Azure 函式。 如需此方法的範例，請參閱 建立與LogicApps整合的函式。

後續步驟

Azure 上的微服務