Azure Service Fabric 的微服務架構

Azure API 管理

Azure 金鑰保存庫

Azure 監視器

Azure Pipelines

Azure Service Fabric

此參考架構會顯示部署至 Azure Service Fabric 的微服務架構。它會顯示基本叢集組態，可以是大部分部署的起點。

GitHub 標誌 GitHub 提供此架構的參考實作。

架構

顯示 Service Fabric 參考架構的圖表。

下載此架構的 Visio 檔案。

注意

本文著重於 Service Fabric 的 Reliable Services 程式設計模型。使用 Service Fabric 部署和管理容器已超出本文的範圍。

工作流程

此結構由下列元件組成。如需其他詞彙，請參閱 Service Fabric 術語概觀。

Service Fabric 叢集。叢集是一組網路連線的虛擬機（VM），可供您部署和管理微服務。
虛擬機擴展集。虛擬機擴展集可讓您建立和管理一組相同、負載平衡和自動調整 VM 的群組。這些計算資源也提供容錯網域和升級網域。
節點。節點是屬於 Service Fabric 叢集的 VM。
節點類型。節點類型代表部署節點集合的虛擬機擴展集。 Service Fabric 叢集至少有一個節點類型。

在具有多個節點類型的叢集中，必須將其中一個宣告為主要節點類型。叢集中的主要節點類型會執行 Service Fabric 系統服務。這些服務提供 Service Fabric 的平臺功能。主要節點類型也會做為種子節點，也就是維護基礎叢集可用性的節點。

設定其他節點類型以執行您的服務。
服務。 服務會執行獨立函式，可獨立於其他服務啟動和執行。服務的實例會部署到叢集中的節點。 Service Fabric 中有兩種服務：
- 無狀態服務。無狀態服務不會維護服務內的狀態。如果需要狀態持續性，狀態會寫入外部存放區並從外部存放區擷取，例如 Azure Cosmos DB。
- 具狀態服務。服務狀態會保留在服務本身內。大部分具狀態服務都會透過 Service Fabric 中的 Reliable Collections 來實作此作業。
Service Fabric Explorer。 Service Fabric Explorer 是一種開放原始碼工具，可用來檢查和管理 Service Fabric 叢集。
Azure Pipelines。 Azure Pipelines 是 Azure DevOps Services 的一部分，並執行自動化組建、測試和部署。您也可以使用第三方持續整合和持續傳遞（CI/CD）解決方案，例如 Jenkins。
Azure 監視器。 Azure 監視器會收集並儲存計量和記錄，包括解決方案和應用程式遙測中 Azure 服務的平臺計量。使用此數據來監視應用程式、設定警示和儀錶板，以及執行失敗的根本原因分析。 Azure 監視器會與 Service Fabric 整合，以收集控制器、節點和容器的計量，以及容器和節點記錄。
Azure Key Vault。使用金鑰保存庫來儲存微服務使用的任何應用程式秘密，例如連接字串。
Azure API 管理。在此架構中，API 管理做為 API 閘道，可接受來自用戶端的要求，並將其路由傳送至您的服務。

考量

這些考慮會實作 Azure Well-Architected Framework 的支柱，這是改善工作負載品質的一組指導原則。

設計考量

此參考架構著重於微服務架構。微服務是小型、獨立建立版本的程式代碼單位。它可透過服務探索機制進行探索，並可透過 API 與其他服務通訊。每個服務都是獨立的，而且應該實作單一商務功能。如需如何將應用程式域分解成微服務的詳細資訊，請參閱使用定義域分析來建立微服務模型。

Service Fabric 提供基礎結構，以有效率地建置、部署和升級微服務。它也提供自動調整、管理狀態、監視健康情況，以及在失敗時重新啟動服務的選項。

Service Fabric 遵循應用程式模型，其中應用程式是微服務的集合。應用程式會在應用程式指令清單檔中描述。此檔案會定義應用程式所包含的服務類型，以及獨立服務套件的指標。

應用程式套件通常也包含參數，做為服務使用之特定設定的覆寫。每個服務套件都有指令清單檔，描述執行該服務所需的實體檔案和資料夾，包括二進位檔、組態檔和唯讀數據。服務和應用程式是獨立版本設定和可升級的。

或者，應用程式指令清單可以描述建立應用程式實例時自動布建的服務。這些稱為 預設服務。在此情況下，應用程式指令清單也會說明應該如何建立這些服務。該資訊包括服務的名稱、實例計數、安全性或隔離原則，以及放置條件約束。

注意

如果您想要控制服務的存留期，請避免使用默認服務。建立應用程式時會建立預設服務，只要應用程式正在執行，就會執行它們。

如需詳細資訊，請參閱 So you want to learn about Service Fabric？。

應用程式對服務封裝模型

微服務的一個原則是，每個服務都可以獨立部署。在 Service Fabric 中，如果您將所有服務分組為單一應用程式套件，且一個服務無法升級，則會復原整個應用程式升級。該復原可防止其他服務升級。

因此，在微服務架構中，我們建議使用多個應用程式套件。將一或多個密切相關的服務類型放入單一應用程式類型。例如，如果您的小組負責一組具有下列屬性的服務，請將服務類型放在相同的應用程式類型：

它們會執行相同的持續時間，而且必須同時更新。
其生命週期相同。
它們會共享資源，例如相依性或組態。

Service Fabric 程式設計模型

當您將微服務新增至 Service Fabric 應用程式時，請決定它是否有狀態或數據需要高度可用且可靠。如果是，它可以在外部儲存數據，或數據是否包含在服務中？如果您不需要儲存資料，或想要將資料儲存在外部記憶體中，請選擇無狀態服務。如果適用下列其中一個語句，請考慮選擇具狀態服務：

您要維護狀態或資料做為服務的一部分。例如，您需要該數據位於靠近程式碼的記憶體中。
您無法容忍對外部存放區的相依性。

如果您有想要在 Service Fabric 上執行的現有程式代碼，您可以將它當作 來賓可執行檔執行：以服務身分執行的任意可執行檔。或者，您可以將可執行文件封裝在容器中，其中包含部署所需的所有相依性。

Service Fabric 會將容器和客體可執行檔模型化為無狀態服務。如需選擇模型的指引，請參閱 Service Fabric 程式設計模型概觀。

您必須負責維護客體可執行檔執行所在的環境。例如，假設來賓可執行檔需要 Python。如果可執行檔不是獨立式，您必須確定已在環境中預安裝必要的 Python 版本。 Service Fabric 不會管理環境。 Azure 提供多個機制來設定環境，包括自定義虛擬機映像和擴充功能。

若要透過反向 Proxy 存取來賓可執行檔，請確定您已將屬性新增 UriScheme 至 Endpoint 來賓可執行檔服務指令清單中的元素。

    <Endpoints>
      <Endpoint Name="MyGuestExeTypeEndpoint" Port="8090" Protocol="http" UriScheme="http" PathSuffix="api" Type="Input"/>
    </Endpoints>

如果服務有其他路由，請在值中 PathSuffix 指定路由。值不應加上前置詞或後綴，並加上斜線（/）。另一種方式是在服務名稱中新增路由。

    <Endpoints>
      <Endpoint Name="MyGuestExeTypeEndpoint" Port="8090" Protocol="http" PathSuffix="api" Type="Input"/>
    </Endpoints>

如需詳細資訊，請參閱

API 閘道

API 閘道（輸入）位於外部用戶端與微服務之間。其可作為反向 Proxy，將要求從用戶端路由傳送至微服務。它也可能執行跨領域工作，例如驗證、SSL 終止和速率限制。

我們建議在大部分情況下使用 Azure API 管理，但 Traefik 是熱門的開放原始碼替代方案。這兩種技術選項都與 Service Fabric 整合。

API 管理。公開公用IP位址，並將流量路由傳送至您的服務。它會在與 Service Fabric 叢集相同的虛擬網路中的專用子網中執行。

API 管理可以存取透過具有私人IP位址之負載平衡器公開的節點類型中的服務。此選項僅適用於 API 管理的進階和開發人員層。針對生產工作負載，請使用進階層。定價資訊會在 API 管理定價中說明。

如需詳細資訊，請參閱 Service Fabric with Azure API 管理概觀。
Traefik。支援路由、追蹤、記錄和計量等功能。 Traefik 會在 Service Fabric 叢集中以無狀態服務的形式執行。服務版本控制可透過路由支援。

如需如何為服務輸入設定 Traefik 以及作為叢集中反向 Proxy 的資訊，請參閱 Traefik 網站上的 Azure Service Fabric 提供者。如需搭配 Service Fabric 使用 Traefik 的詳細資訊，請參閱使用 Traefik 搭配 Service Fabric 的智慧型手機由部落格文章。

Traefik 與 Azure API 管理不同，沒有功能可解析要求路由傳送至其中的具狀態服務分割區（具有多個分割區）。如需詳細資訊，請參閱新增數據分割服務的比對器。

其他 API 管理選項包括 Azure 應用程式閘道和 Azure Front Door。您可以使用這些服務搭配 API 管理來執行路由、SSL 終止和防火牆等工作。

服務間通訊

若要加速服務對服務通訊，請考慮下列建議：

通訊協定。在微服務架構中，服務必須在運行時間與最低結合點彼此通訊。若要啟用語言無關的通訊，HTTP 是一個業界標準，其中包含各種不同語言可用的工具和 HTTP 伺服器。 Service Fabric 支援所有這些工具和伺服器。

針對大部分的工作負載，我們建議您使用 HTTP，而不是 Service Fabric 內建的服務遠端處理。
服務探索。若要與叢集內的其他服務通訊，客戶端服務必須解析目標服務的目前位置。在 Service Fabric 中，服務可以在節點之間移動，並導致服務端點動態變更。

若要避免連線到過時的端點，您可以使用 Service Fabric 中的命名服務來擷取更新的端點資訊。不過，Service Fabric 也提供內建的反向 Proxy 服務，以抽象化命名服務。我們建議此選項作為大部分案例的服務探索基準，因為更容易使用併產生更簡單的程序代碼。

服務間通訊的其他選項包括：

進階路由的 Traefik 。
服務預期使用 DNS 之相容性案例的 DNS 。
會快取服務端點的 ServicePartitionClient TCommunicationClient<> 類別。它可以提供更好的效能，因為呼叫會直接在服務之間進行，而不需要中繼或自定義通訊協定。

延展性

Service Fabric 支持調整這些叢集實體：

調整每個節點類型的節點數目
調整服務

本節著重於自動調整。您可以選擇在適當的情況下手動調整規模。例如，可能需要手動介入才能設定實例數目。

延展性的初始叢集設定

當您建立 Service Fabric 叢集時，請根據您的安全性和延展性需求布建節點類型。每個節點類型都會對應至虛擬機擴展集，而且可以獨立調整。

為每個具有不同延展性或資源需求的服務群組建立節點類型。首先，布建 Service Fabric 系統服務的節點類型（這會成為主要節點類型）。建立個別的節點類型，以執行您的公用或前端服務。針對後端和私人或隔離的服務，視需要建立其他節點類型。指定放置條件約束，以便服務只部署到預期的節點類型。
指定 每個節點類型的持久性層 。持久性層代表 Service Fabric 影響虛擬機擴展集中更新和維護作業的能力。針對生產工作負載，請選擇 Silver 或更高的持久性層級。如需每個層級的相關信息，請參閱叢集的持久性特性。
如果您使用銅級持久性層級，某些作業需要手動步驟。具有銅級持久性層的節點類型在相應縮小期間需要額外的步驟。如需調整作業的詳細資訊，請參閱本指南。

調整節點

Service Fabric 支援自動調整相應縮小和相應放大。您可以個別設定每個節點類型來進行自動調整。

每個節點類型最多可以有100個節點。從較小的一組節點開始，並根據負載新增更多節點。如果您在節點類型中需要超過100個節點，則必須新增更多節點類型。如需詳細資訊，請參閱 Service Fabric 叢集容量規劃考慮。虛擬機擴展集不會立即調整，因此當您設定自動調整規則時，請考慮該因素。

若要支援自動相應縮小，請將節點類型設定為具有 Silver 或 Gold 持久性層級。此設定可確保在 Service Fabric 完成重新定位服務之前，相應縮小會延遲。它也可確保虛擬機擴展集會通知 Service Fabric VM 已移除，而不只是暫時關閉。

如需有關在節點或叢集層級調整的詳細資訊，請參閱調整 Azure Service Fabric 叢集。

調整服務

無狀態和具狀態服務會套用不同的調整方法。

針對無狀態服務（自動調整）：

使用平均數據分割負載觸發程式。此觸發程式會根據調整原則中指定的負載臨界值，決定服務何時相應縮小或相應放大。您也可以設定檢查觸發程式的頻率。請參閱實例型調整的平均分割區負載觸發程式。此方法可讓您相應增加至可用的節點數目。
在服務指令清單中設定 InstanceCount 為 -1，這會指示 Service Fabric 在每個節點上執行服務的實例。此方法可讓服務隨著叢集調整而動態調整。當叢集中的節點數目變更時，Service Fabric 會自動建立和刪除要相符的服務實例。

注意

在某些情況下，您可能想要手動調整您的服務。例如，如果您有從 Azure 事件中樞讀取的服務，您可能會想要讓專用實例從每個事件中樞分割區讀取。如此一來，您可以避免並行存取分割區。

針對具狀態服務，調整是由分割區數目、每個分割區的大小，以及計算機上執行的分割區或複本數目所控制：

如果您要建立數據分割服務，請確定每個節點取得適當的複本，以平均散發工作負載，而不會造成資源爭用。如果您新增更多節點，Service Fabric 預設會將工作負載散發到新的機器上。例如，如果有 5 個節點和 10 個分割區，Service Fabric 預設會在每個節點上放置兩個主要複本。如果您相應放大節點，可以達到更高的效能，因為工作平均分散到更多資源。

如需利用此策略之案例的相關信息，請參閱在 Service Fabric 中調整。
不支援新增或移除分割區。通常用來調整的另一個選項是動態建立或刪除服務或整個應用程式實例。透過建立或移除新的具名服務，來說明該模式的範例。

如需詳細資訊，請參閱

使用計量來平衡負載

根據您設計數據分割的方式，您可能會有具有比其他複本更多的流量的節點。為了避免這種情況，請分割服務狀態，使其分散到所有分割區。使用範圍數據分割配置搭配良好的哈希演算法。請參閱開始使用數據分割。

Service Fabric 會使用計量來瞭解如何在叢集中放置及平衡服務。您可以在建立該服務時，為每個與服務相關聯的計量指定預設負載。 Service Fabric 接著會在放置服務時考慮該負載，或每當服務需要移動時（例如在升級期間），以平衡叢集中的節點。

服務最初指定的預設負載不會在服務的存留期內變更。若要擷取服務變更計量，建議您監視服務，然後動態報告負載。此方法可讓 Service Fabric 根據指定時間的報告負載來調整配置。使用 IServicePartition.ReportLoad 方法來報告自定義計量。如需詳細資訊，請參閱動態載入。

可用性

將您的服務放在主要節點類型以外的節點類型中。 Service Fabric 系統服務一律會部署到主要節點類型。如果您的服務部署至主要節點類型，它們可能會與資源競爭系統服務（並干擾）系統服務。如果節點類型預期裝載具狀態服務，請確定至少有五個節點實例，而且您選取銀級或金級持久性層。

請考慮限制服務的資源。請參閱資源治理機制。

以下是常見的考慮：

請勿混合資源控管的服務，以及未在相同節點類型上控管資源的服務。非控管的服務可能會耗用太多資源，並影響受控的服務。指定放置條件約束，以確保這些類型的服務不會在同一組節點上執行。（這是的範例大塊圖樣。）
指定要為服務實例保留的CPU核心和記憶體。如需資源治理原則的使用方式和限制的相關信息，請參閱資源治理。

若要避免單一失敗點（SPOF），請確定每個服務的目標實例或複本計數都大於一個。您可以使用作為服務實例或複本計數的最大數目等於限制服務的節點數目。

請確定每個具狀態服務至少有兩個作用中次要複本。我們建議生產工作負載使用五個複本。

如需詳細資訊，請參閱 Service Fabric 服務的可用性。

安全性

安全性可提供保證，以避免刻意攻擊和濫用您寶貴的資料和系統。如需詳細資訊，請參閱安全性要素的概觀。

以下是在 Service Fabric 上保護應用程式的一些重點。

虛擬網路

請考慮為每個虛擬機擴展集定義子網界限，以控制通訊流程。每個節點類型在 Service Fabric 叢集虛擬網路內的子網中都有自己的虛擬機擴展集。您可以將網路安全組（NSG）新增至子網，以允許或拒絕網路流量。例如，使用前端和後端節點類型，您可以將 NSG 新增至後端子網，以只接受來自前端子網的輸入流量。

當您從叢集呼叫外部 Azure 服務時，如果 Azure 服務支援，請使用虛擬網路服務端點。使用服務端點只會將服務保護至叢集的虛擬網路。

例如，如果您使用 Azure Cosmos DB 來儲存數據，請使用服務端點設定 Azure Cosmos DB 帳戶，以只允許從特定子網存取。請參閱從虛擬網路存取 Azure Cosmos DB 資源。

端點和服務間通訊

請勿建立不安全的 Service Fabric 叢集。如果叢集向公用因特網公開管理端點，匿名使用者可以連線到它。不支援將不安全的叢集用作生產工作負載。請參閱 Service Fabric 叢集安全性案例。

為了協助保護您的服務間通訊：

請考慮在您的 ASP.NET Core 或 Java Web 服務中啟用 HTTPS 端點。
建立反向 Proxy 與服務之間的安全連線。如需詳細資訊，請參閱連線到安全的服務。

如果您使用 API 閘道，您可以將驗證卸除至閘道。除非已提供額外的安全性來驗證訊息，否則請確定無法直接連線到個別服務（不含 API 閘道）。

請勿公開 Service Fabric 反向 Proxy。這樣做會導致公開 HTTP 端點的所有服務都能從叢集外部尋址。這會導致安全性弱點，並可能會不必要地在叢集外部公開其他資訊。如果您想要公開存取服務，請使用 API 閘道。本文稍後的 API 閘道一節會提及一些選項。

遠端桌面對於診斷和疑難解答很有用，但請務必關閉它。將它保持開放會造成安全性漏洞。

秘密和憑證

將秘密儲存在金鑰保存庫中，例如將資料存放區連接字串。金鑰保存庫必須與虛擬機擴展集位於相同的區域中。若要使用金鑰儲存庫：

驗證服務的金鑰保存庫存取權。

在裝載服務的虛擬機擴展集上啟用受控識別。
將您的秘密儲存在金鑰保存庫中。

以可轉譯成機碼/值組的格式新增秘密。例如，使用 CosmosDB--AuthKey。建置組態時，雙連字元（--）會轉換成冒號（:）。
在您的服務中存取這些秘密。

在appSettings.json檔案中新增金鑰保存庫 URI。在您的服務中，新增從密鑰保存庫讀取的組態提供者、建置組態，以及從建置組態存取秘密。

以下是工作流程服務以格式 CosmosDB--Database將秘密儲存在密鑰保存庫中的範例。

namespace Fabrikam.Workflow.Service
{
    public class ServiceStartup
    {
        public static void ConfigureServices(StatelessServiceContext context, IServiceCollection services)
        {
            var preConfig = new ConfigurationBuilder()
                …
                .AddJsonFile(context, "appsettings.json");

            var config = preConfig.Build();

            if (config["AzureKeyVault:KeyVaultUri"] is var keyVaultUri && !string.IsNullOrWhiteSpace(keyVaultUri))
            {
                preConfig.AddAzureKeyVault(keyVaultUri);
                config = preConfig.Build();
            }
    }
}

若要存取秘密，請在建置組態中指定秘密名稱。

       if(builtConfig["CosmosDB:Database"] is var database && !string.IsNullOrEmpty(database))
       {
            // Use the secret.
       }

請勿使用客戶端憑證來存取 Service Fabric Explorer。請改用Microsoft Entra ID。請參閱支援Microsoft Entra 驗證的 Azure 服務。

請勿將自我簽署憑證用於生產環境。

保護待用數據

如果您將數據磁碟連結至 Service Fabric 叢集的虛擬機擴展集，而您的服務會將資料儲存在這些磁碟上，您必須加密磁碟。如需詳細資訊，請參閱使用 Azure PowerShell 加密虛擬機擴展集中的 OS 和鏈接數據磁碟（預覽版）。

如需保護 Service Fabric 的詳細資訊，請參閱：

復原

若要從失敗中復原並維持正常運作的狀態，應用程式必須實作特定的復原模式。以下是一些常見的模式：

重試：若要處理您預期為暫時性的錯誤，例如暫時無法使用的資源。
斷路器：解決可能需要較長時間才能修正的錯誤。
大量分頁：隔離每個服務的資源。

此參考實作會使用開放原始碼選項 Polly 來實作所有這些模式。

監視

在探索監視選項之前，建議您先閱讀本文，以診斷 Service Fabric 的常見案例。您可以考慮在這些集合中監視資料：

應用程式計量和記錄
Service Fabric 健康情況和事件數據
基礎結構計量和記錄
相依服務的計量和記錄

以下是分析該資料的兩個主要選項：

Application Insights
Log Analytics

您可以使用 Azure 監視器來設定用於監視的儀錶板，並將警示傳送給操作員。某些第三方監視工具也與 Service Fabric 整合，例如 Dynatrace。如需詳細資訊，請參閱 Azure Service Fabric 監視合作夥伴。

應用程式計量和記錄

應用程式遙測提供數據，可協助您監視服務的健康情況，並找出問題。若要在服務中新增追蹤和事件：

如果您要使用 ASP.NET Core 開發服務，請使用 Microsoft.Extensions.Logging 。對於其他架構，請使用您選擇的記錄連結庫，例如 Serilog。
使用 SDK 中的 TelemetryClient 類別新增您自己的檢測，並在 Application Insights 中檢視數據。請參閱將自定義檢測新增至您的應用程式。
使用 EventSource 記錄 Windows 事件追蹤（ETW）事件。根據預設，此選項可在 Visual Studio Service Fabric 解決方案中使用。

Application Insights 提供許多內建遙測：要求、追蹤、事件、例外狀況、計量、相依性。如果您的服務公開 HTTP 端點，請呼叫 UseApplicationInsights Microsoft.AspNetCore.Hosting.IWebHostBuilder 的擴充方法，以啟用 Application Insights。如需檢測 Application Insights 服務的相關信息，請參閱下列文章：

若要檢視追蹤和事件記錄檔，請使用 Application Insights 作為結構化記錄的其中一個接收。呼叫 AddApplicationInsights 擴充方法，以檢測密鑰設定 Application Insights。在此範例中，檢測金鑰會儲存為金鑰保存庫中的秘密。

    .ConfigureLogging((hostingContext, logging) =>
        {
            logging.AddApplicationInsights(hostingContext.Configuration ["ApplicationInsights:InstrumentationKey"]);
        })

如果您的服務未公開 HTTP 端點，您必須撰寫將追蹤傳送至 Application Insights 的自定義延伸模組。如需範例，請參閱參考實作中的工作流程服務。

ASP.NET Core 服務會使用 ILogger 介面進行應用程式記錄。若要讓這些應用程式記錄可在 Azure 監視器中使用，請將 ILogger 事件傳送至 Application Insights。 Application Insights 可以將相互關聯屬性新增至 ILogger 事件，這對於可視化分散式追蹤很有用。

如需詳細資訊，請參閱

Service Fabric 健康情況和事件數據

Service Fabric 遙測包含 Service Fabric 叢集及其實體作業和效能的相關健康情況計量和事件：其節點、應用程式、服務、數據分割和複本。健康情況和事件資料可能來自：

EventStore。此具狀態系統服務會收集與叢集及其實體相關的事件。 Service Fabric 會使用 EventStore 來撰寫 Service Fabric 事件，以提供叢集的相關信息，以取得狀態更新、疑難解答和監視。 EventStore 也可以讓特定時間來自不同實體的事件相互關聯，以識別叢集中的問題。服務會透過 REST API 公開這些事件。

如需如何查詢 EventStore API 的詳細資訊，請參閱查詢叢集事件的 EventStore API。您可以使用適用於 Windows 的 Azure 診斷擴充功能來設定叢集，以檢視 Log Analytics 中的 EventStore 事件。
HealthStore。此具狀態服務會提供叢集目前健全狀況的快照集。它會匯總階層中實體所報告的所有健康情況數據。數據會在 Service Fabric Explorer 中可視化。 HealthStore 也會監視應用程式升級。您可以在 PowerShell、.NET 應用程式或 REST API 中使用健康情況查詢。請參閱 Service Fabric 健康情況監視簡介。
自定義健康情況報告。請考慮實作可定期報告自定義健康情況數據的內部監視程序服務，例如執行中服務的錯誤狀態。您可以在 Service Fabric Explorer 中讀取健康情況報告。

基礎結構計量和記錄

基礎結構計量可協助您瞭解叢集中的資源配置。以下是收集此資訊的主要選項：

WAD。收集 Windows 上節點層級的記錄和計量。您可以在任何對應至節點類型的虛擬機擴展集上設定 IaaSDiagnostics VM 擴充功能，以收集診斷事件，以使用 WAD。這些事件可能包括 Windows 事件記錄檔、性能計數器、ETW/指令清單系統和操作事件，以及自定義記錄。
Log Analytics 代理程式。設定 MicrosoftMonitoringAgent VM 擴充功能，將 Windows 事件記錄檔、性能計數器和自定義記錄傳送至 Log Analytics。

透過上述機制收集的計量類型有些重疊，例如性能計數器。如果有重疊，建議您使用Log Analytics代理程式。因為 Log Analytics 代理程式不會使用 Azure 記憶體，延遲很低。此外，IaaSDiagnostics 中的性能計數器無法輕易地送入 Log Analytics。

顯示 Service Fabric 中基礎結構監視的圖表。

如需使用 VM 擴充功能的詳細資訊，請參閱 Azure 虛擬機擴充功能和功能。

若要檢視數據，請將Log Analytics 設定為顯示透過WAD收集的數據。如需如何設定 Log Analytics 從記憶體帳戶讀取事件的相關信息，請參閱設定叢集的 Log Analytics。

您也可以檢視與 Service Fabric 叢集、工作負載、網路流量、擱置更新等相關的效能記錄和遙測數據。請參閱使用Log Analytics進行效能監視。

Log Analytics 中的服務對應解決方案提供叢集拓撲的相關信息（也就是在每個節點中執行的進程）。將記憶體帳戶中的數據傳送至 Application Insights。將數據放入 Application Insights 可能會有一些延遲。如果您想要即時查看數據，請考慮使用接收和通道來設定事件中樞。如需詳細資訊，請參閱使用 WAD 的事件匯總和集合。

相依服務計量

Application Insights 中的應用程式對應會使用服務之間的 HTTP 相依性呼叫，搭配已安裝的 Application Insights SDK，來提供應用程式的拓撲。
Log Analytics 中的服務對應提供輸入和輸出流量的相關信息，以及從外部服務到外部服務。服務對應與其他解決方案整合，例如更新或安全性。
自訂監看程式可以報告外部服務的錯誤狀況。例如，如果服務無法存取外部服務或數據記憶體（Azure Cosmos DB），服務可以提供錯誤健康情況報告。

分散式追蹤

在微服務架構中，數個服務通常會參與以完成工作。來自每個服務的遙測會透過分散式追蹤中的內容欄位（例如作業標識碼和要求標識元）相互關聯。

藉由在 Application Insights 中使用應用程式對應，您可以建置分散式邏輯作業的檢視，並將應用程式的整個服務圖形可視化。您也可以在 Application Insights 中使用交易診斷，將伺服器端遙測相互關聯。如需詳細資訊，請參閱整合跨元件交易診斷。

使用佇列以異步方式分派的工作也很重要。如需在佇列訊息中傳送相互關聯遙測的詳細資訊，請參閱佇列檢測。

如需詳細資訊，請參閱

警示和儀錶板

Application Insights 和 Log Analytics 支援廣泛的查詢語言（Kusto 查詢語言），可讓您擷取和分析記錄數據。使用查詢來建立數據集，並在診斷儀錶板中將其可視化。

使用 Azure 監視器警示，在特定資源中發生特定條件時通知系統管理員。例如，通知可能是電子郵件、Azure 函式或 Webhook。如需詳細資訊，請參閱 Azure 監視器中的警示。

記錄搜尋警示規則可讓您定期針對Log Analytics工作區定義及執行 Kusto 查詢。如果查詢結果符合特定條件，就會建立警示。

成本最佳化

使用 Azure 定價計算機來預估成本。 Microsoft Azure Well-Architected Framework 的成本優化要素會說明其他考慮。

以下是此架構中所使用之一些服務的一些考慮點。

Azure Service Fabric

您需支付建立 Service Fabric 叢集時所選擇的計算實例、記憶體、網路資源和 IP 位址的費用。 Service Fabric 有部署費用。

虛擬機器擴展集

在此架構中，微服務會部署到虛擬機擴展集的節點。您需支付部署為叢集和基礎結構資源的 Azure VM 費用，例如記憶體和網路功能。虛擬機擴展集本身沒有累加費用。

Azure API 管理

Azure API 管理是將要求從用戶端路由傳送至叢集中服務的閘道。

有各種定價選項。取用選項會依使用量付費，並包含閘道元件。根據您的工作負載，選擇 API 管理定價中所述的選項。

Application Insights

您可以使用 Application Insights 收集所有服務的遙測數據，並以結構化的方式檢視追蹤和事件記錄檔。 Application Insights 的定價是以內嵌的數據量和數據保留選項為基礎的隨用隨付模型。如需詳細資訊，請參閱管理 Application Insights 的使用方式和成本。

Azure 監視器

針對 Azure 監視器 Log Analytics，您需支付數據擷取和保留費用。如需詳細資訊，請參閱 Azure 監視器計量價格。

Azure Key Vault

您可以使用 Azure 金鑰保存庫，將 Application Insights 的檢測金鑰儲存為秘密。 Azure 提供兩個服務層級金鑰保存庫。如果您不需要受 HSM 保護的金鑰，請選擇標準層。如需各層功能的相關信息，請參閱金鑰保存庫定價。

Azure DevOps Services

此參考架構會使用 Azure Pipelines 進行部署。 Azure Pipelines 服務可讓 CI/CD 每月有 1,800 分鐘的免費Microsoft裝載作業，以及一個每月無限制的自我裝載作業。額外的工作有費用。如需詳細資訊，請參閱 Azure DevOps Services 定價。

如需微服務架構中的 DevOps 考慮，請參閱微服務的 CI/CD。

若要瞭解如何使用 CI/CD 將容器應用程式部署至 Service Fabric 叢集，請參閱本教學課程。

部署此案例

若要部署此架構的參考實作，請遵循 GitHub 存放庫中的步驟。

共用方式為

Azure Service Fabric 的微服務架構

架構

工作流程

考量

設計考量

應用程式對服務封裝模型

Service Fabric 程式設計模型

API 閘道

服務間通訊

延展性

延展性的初始叢集設定

調整節點

調整服務

使用計量來平衡負載

可用性

安全性

虛擬網路

端點和服務間通訊

秘密和憑證

保護待用數據

復原

監視

應用程式計量和記錄

Service Fabric 健康情況和事件數據

基礎結構計量和記錄

相依服務計量

分散式追蹤

警示和儀錶板

成本最佳化

Azure Service Fabric

虛擬機器擴展集

Azure API 管理

Application Insights

Azure 監視器

Azure Key Vault

Azure DevOps Services

部署此案例

下一步

相關資源

意見反應

其他資源