共用方式為

選擇微服務的 Azure 計算選項

  • 發行項

計算一詞是指應用程式執行之計算資源的裝載模型。 針對微服務架構，兩種方法特別受歡迎：

  • 服務協調器，管理在專用節點上執行的服務（VM）。
  • 使用函式即服務 （FaaS） 的無伺服器架構。

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

服務協調器

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

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

  • Azure Kubernetes Service (AKS) 是受控 Kubernetes 服務。 AKS 會布建 Kubernetes 並公開 Kubernetes API 端點，但裝載和管理 Kubernetes 控制平面、執行自動化升級、自動化修補、自動調整和其他管理工作。 您可以將 AKS 視為「Kubernetes API 即服務」。

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

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

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

容器

有時候人們會談論容器和微服務，就像是一樣。 雖然這不是真的，但您不需要容器來建置微服務，但容器確實有一些與微服務特別相關的優點，例如：

  • 可移植性。 容器映像是獨立套件，不需要安裝連結庫或其他相依性即可執行。 這可讓部署變得容易。 容器可以快速啟動和停止，因此您可以啟動新的實例來處理更多負載，或從節點失敗中復原。

  • 密度。 相較於執行虛擬機，容器是輕量型的，因為它們會共用OS資源。 這可讓您將多個容器封裝到單一節點上，這在應用程式包含許多小型服務時特別有用。

  • 資源隔離。 您可以限制容器可用的記憶體和CPU數量，這有助於確保失控進程不會耗盡主機資源。 如需詳細資訊， 請參閱 Bulkhead 模式 。

無伺服器 （函式即服務）

使用無伺服器架構時，您不會管理 VM 或虛擬網路基礎結構。 相反地，您會部署程式代碼，而裝載服務會處理將該程式代碼放入 VM 並加以執行。 這種方法傾向於使用事件型觸發程式協調的小型細微函式。 例如，放置於佇列中的訊息可能會觸發從佇列讀取並處理訊息的函式。

Azure Functions 是無伺服器計算服務，可支援各種函式觸發程式，包括 HTTP 要求、服務匯流排 佇列和事件中樞事件。 如需完整清單，請參閱 Azure Functions 觸發程式和系結概念。 另請考慮 Azure 事件方格，這是 Azure 中的受控事件路由服務。

Orchestrator 或無伺服器？

以下是在協調器方法與無伺服器方法之間進行選擇時需要考慮的一些因素。

管理性 無伺服器應用程式很容易管理，因為平臺會為您管理所有計算資源。 雖然協調器會抽象化管理及設定叢集的某些層面，但它不會完全隱藏基礎 VM。 使用協調器時，您必須考慮負載平衡、CPU 和記憶體使用量和網路等問題。

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

可移植性。 這裡所列的所有協調器（Kubernetes、DC/OS、Docker Swarm 和 Service Fabric）都可以在內部部署或多個公用雲端中執行。

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

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

延展性。 Azure Functions 會根據傳入事件的數目自動調整以符合需求。 透過協調器，您可以藉由增加叢集中執行的服務實例數目來相應放大。 您也可以將其他 VM 新增至叢集來調整規模。

我們的參考實作主要使用 Kubernetes，但我們確實針對一項服務使用 Azure Functions，也就是傳遞歷程記錄服務。 Azure Functions 非常適合此特定服務，因為它是事件驅動工作負載。 藉由使用事件中樞觸發程式叫用函式，服務需要最少的程式代碼量。 此外，傳遞歷程記錄服務不是主要工作流程的一部分，因此在 Kubernetes 叢集外部執行，不會影響使用者起始作業的端對端延遲。

下一步

服務間通訊