2015 年 12 月

第 30 卷，第 13 期

本文章是由機器翻譯。

Microsoft Azure - Azure Service Fabric 和微服務架構

由 Cesar de la Torre, Kunal 深層 深層 | 2015 年 12 月

微服務目前是熱 buzzword。雖然有許多簡報和會議有關主題的討論，許多開發人員仍然混淆。常見的問題，我們聽說: 「 不是這只是另一個服務導向架構 (SOA) 或網域導向設計 (DDD) 的方法嗎? 」

當然，在微服務方法所使用的技術有許多衍生自 SOA 和 DDD 中的開發人員的體驗。您可以想像微服務 」 權限，完成 SOA 」 原則和模式，如同自發服務，已繫結內容模式與和事件導向全都在 SOA 和 DDD 根源。

在本文中我們解決微服務理論上和實作。我們將開始微服務，簡短的簡介，請移到實際的側邊和如何建置和部署微服務與 Azure 服務網狀架構。最後，我們會示範建立微服務時這個平台為何理想。

正如其名，微服務架構是伺服器應用程式建置為一組小型的服務，每個服務在自己的處理序中執行，並透過通訊協定，例如 HTTP 和 Websocket 來與彼此通訊的方法。每個微服務實作特定的端對端的網域和商務功能，某些已繫結的內容中每個服務，和必須獨立開發和部署獨立的自動化機制。最後，每個服務應擁有其相關的網域資料模型和網域邏輯，可以採用不同的資料儲存技術 (SQL、 No SQL) 與不同的程式設計語言，每個微服務。

微服務的範例包括通訊協定閘道、 使用者設定檔、 購物車、 清查處理、 訂單子系統、 付款處理程序，與佇列和快取。

為什麼微服務嗎? 在 word 中的靈活度。長期來看，透過微服務啟用優異的可維護性龐大、 複雜且具有高擴充性系統中設計許多可獨立部署的服務，以更細微的發行計劃為基礎的應用程式。

另一個好處，微服務可以向外延展獨立。您不需要大型整合型的應用程式區塊，您必須向外延展一次，您可以改為向外延展特定微服務。這樣一來，只是需要更多處理能力或網路頻寬來支援指定的功能區域可以縮放，而不是調整應用程式其實也不需要它的其他區域。

架構更細緻的微服務應用程式啟用連續整合和持續開發作法，並加速新函式傳遞至應用程式。精細分解的應用程式也可讓您執行及測試微服務隔離，並維持它們之間的嚴格合約獨立發展微服務。只要您在不中斷的合約或介面，您可以變更實際上任何微服務實作，以及加入新的功能，而不會中斷其他依存於此的微服務。

做為 圖 1 微服務的方法關鍵在於效率敏捷式軟體開發的變更以及快速反覆項目，您就可以變更特定的小部分的大，因為顯示複雜且可擴充的應用程式。

圖 1 微服務方式相較於傳統的伺服器應用程式方法

每個微服務的資料主權

重要的規則，在這種方法是每個微服務必須擁有網域資料和邏輯下自發的生命週期，每個微服務的獨立部署。這是完整的應用程式擁有其邏輯和資料的方式從實在沒什麼兩樣。

這種方式表示網域的概念模型將不同子系統或微服務。請考慮企業應用程式，其中客戶關係管理 (CRM) 應用程式，交易式購買子系統和客戶支援子系統上唯一的客戶實體的屬性和資料的每個呼叫，而採用不同的已繫結內容。

此原則的類似 DDD 其中每個已繫結的內容，這是相當於子系統/服務模式，必須擁有其網域模型 (資料和邏輯)。每個 DDD 已繫結內容會與不同的微服務相互關聯。

相反地，許多應用程式中使用的傳統 (或整合型) 方法是將單一且集中式資料庫 (通常是標準化 SQL 資料庫) 的整個應用程式和其所有內部子系統中, 所示 圖 2。此方法看起來更簡單一開始，並看起來以便重複使用的項目: 一致的不同子系統中的實體。但事實是您得到巨大的資料表提供許多不同子系統，在大部分情況下，包含屬性和資料行只是不必要的。就像嘗試使用相同的實體對應登山簡短的軌跡，採取全天汽車路線和學習地理位置。

圖 2 資料主權比較: 微服務與整合

無狀態或可設定狀態微服務嗎?

如先前所述，每個微服務必須擁有其網域模型。在無狀態微服務，資料庫將會是外部，採用關聯式的選項，例如 SQL Server 或 NoSQL 選項，例如 MongoDB 或 Azure Document DB。繼續進行，服務本身可以可設定狀態，這表示資料位於相同的微服務。這項資料可以存在於不只是位於相同的伺服器，但在相同的微服務處理程序，在記憶體和硬碟機上保存和複寫到其他節點。

無狀態是完全有效的方法，可設定狀態的微服務，因為它比容易實作類似於傳統和已知的模式。但無狀態微服務會造成處理程序和資料來源，同時也呈現更移動項目時改善效能，透過額外的快取和佇列之間的延遲。結果: 您可以得到複雜的架構包含太多的階層。

可設定狀態的微服務，相反地，excel 在進階案例中，因為沒有網域邏輯和資料之間的延遲。大量的資料處理回遊戲結束，即服務、 資料庫和其他低延遲案例都受益於啟用更快地存取本機狀態中的可設定狀態服務。

缺點: 具狀態服務會在以便向外延展複雜的程度。通常會在外部資料庫界限內實作的功能必須處理一些像是資料複寫，跨無狀態微服務複本，資料分割，依此類推。但這是精確的 Service Fabric 可以幫助大部分的區域，透過簡化的開發和可設定狀態微服務的生命週期。

Azure Service Fabric 的優點

隨附的微服務方法的所有健全度都附有一項缺點。分散式部署可能難以管理，如果您在執行自己的運算和複雜微服務。Service Fabric 會提供建立、 部署、 執行和成效與效率的方式來管理微服務所需的配管。

Service Fabric 是什麼? 它屬於分散式的系統平台用來建置 hyper-v 可擴充、 可靠且可輕鬆管理的雲端應用程式。Service Fabric 可解決開發和管理雲端應用程式的重大挑戰。藉由使用 Service Fabric，開發人員和管理員可以避免解決複雜的基礎結構問題和焦點改為實作關鍵任務、 嚴苛了解它們的可擴充、 可靠且易管理的工作負載。Service Fabric 代表 Microsoft 的新一代的中介軟體平台來建置及管理這些企業級的 tier-1 雲端規模服務。

Service Fabric 是通用的部署環境。您就可以將任何可執行檔 (Microsoft.NET Framework、 Node.js、 Java、 c + +) 的任何語言為基礎的部署，或甚至資料庫 MongoDB 之類的執行階段。

因此，務必釐清 Azure Service Fabric 不限於微服務導向的應用程式。您也可以使用裝載和部署傳統的應用程式 (Web 應用程式或服務) 和可得到許多好處，相關的延展性、 負載平衡和快速部署。但是 Azure Service Fabric 中所示，最多，特別是針對超大規模一和微服務為基礎的系統，從頭建置新的平台 圖 3。

圖 3 的 Microsoft Azure 服務網狀架構

某些服務網狀架構的優點如下:

• Azure、 內部部署上或任何定域機組中執行。您可以在 Azure 中，但也在內部，裸機伺服器或虛擬機器 (Vm) 上執行它，而即使在其他協力廠商裝載定域機組非常重要的特性，Service fabric。沒有任何鎖定在特定雲端。您甚至可以執行 Service Fabric 叢集 Amazon Web Services (AWS)。
• 支援 Windows 或 Linux。目前 (晚期 2015) Service Fabric 支援的 Windows，但它也支援 Linux 和容器 (Windows 映像和 Docker 映像)。
• 完整驗證。Service Fabric 用於幾年來 microsoft 電源許多定域機組的產品。

Service Fabric 誕生超出建置 Microsoft 內部的大規模服務的需求。取得 SQL Server 等產品，而敏捷、 可靠、 可擴充且符合成本效益要求無法有效地符合這些需求的所有分散式的技術作為定域機組 (Azure SQL Database) 中可用的服務建置它們。雖然建置核心技術，來解決這些複雜的情況時，變得很明顯的 SQL Server 不只讓這類閏年的產品。產品，例如商務用 Skype 必須解決類似問題變得微服務架構的應用程式的路徑。Service Fabric 是發展出這些挑戰，並已用於許多大規模服務在 Microsoft 的各種架構和需求來執行大規模的應用程式平台。InTune、 DocumentDB 和 Cortana 和所有的商務用 Skype 的後端會在 Service Fabric 執行的服務。

體驗支援關鍵任務系統已啟用 Microsoft 設計的平台，在本質上了解可用的基礎結構資源和可擴充的應用程式的需求。它可讓自動更新，自我修復所不可或缺超大規模提供高度可用且持久的服務行為。Microsoft 現在發佈這戰場強化項技術的每個人。

Azure 服務網狀架構的程式設計模型

Service Fabric 提供兩個高階架構來建置服務: 可靠服務 Api 和可靠動作項目 Api。雖然兩者都建置於相同的 Service Fabric 核心，但會進行之間的簡易性和彈性並行處理、 資料分割以及通訊方面，不同的權衡中所示 圖 4。您最好了解這兩種模型的運作方式，以便您可以選擇較適合您的服務架構。在許多應用程式案例中，您可以擁有混合式方法，並使用動作項目微服務與採用可靠的服務，來彙總資料產生特定的動作項目數目。因此，可靠的服務無法協調動作項目服務中許多常見案例。

圖 4 比較服務網狀架構的程式設計模型

建置使用 Azure Service Fabric 無狀態微服務

在 Azure Service Fabric 微服務可以是您想要建立時，無論是.NET Framework、 Node.js、 Java 或 c + + 的伺服器中幾乎任何程序。目前僅提供 Service Fabric API 的.NET 和 c + + 程式庫。因此，您需要的低階實作 c + + 或.NET Framework 中實作微服務。

如前所述，無狀態微服務是其中一個位置沒有處理序 (例如前端服務或商務邏輯的服務)，但實際上沒有任何狀態保存在服務中，或結束處理程序，並不需要同步處理、 複寫、 持續性或高可用性時，會遺失已存在的狀態。它可能會有相關的外部狀態，但保存在外部儲存體，例如 Azure SQL Database、 Azure 儲存體、 Azure DocumentDB 或任何其他協力廠商儲存引擎 (關聯式或 NoSQL)。因此，任何現有的服務，例如雲端服務、 背景工作角色或 Azure Web 應用程式上執行的 ASP.NET Web API 服務會輕易地移轉至 Service Fabric 無狀態服務。

若要設定開發環境，您需要有可讓您執行的本機開發叢集不是模擬器，但執行相同的位元，如同 Azure Service Fabric SDK。此外，工具整合的 Visual Studio 2015 可讓開發和偵錯更加容易。

之前部署和偵錯在本機電腦的服務，您必須建立叢集的節點。這麼做，執行 Windows PowerShell 指令碼呼叫 DevClusterSetup.ps1，文件頁面，「 準備開發環境的安全 」 的 「 安裝和啟動本機叢集 」 一節中所述位於 bit.ly/1Mfi0LB。您可以參考此頁面，完成安裝程序的逐步解說。

無狀態服務基底類別 發生 Service Fabric 無狀態服務的任何類別必須衍生自 Microsoft.ServiceFabric.Services.StatelessService 類別。這個類別提供 API 方法與內容相關的 Service Fabric 叢集和執行環境，並將連結服務的生命週期。

無論您的服務是可設定狀態或無狀態，可靠的服務會提供簡單的生命週期，可讓您快速插入您的程式碼，並開始使用。沒有其實只是一個或兩個方法，您需要實作，以取得 Service Fabric 服務啟動並執行 — 通常 RunAsync 和 CreateServiceReplicaListeners，我們會說明當向下鑽研的通訊協定。

請注意 RunAsync 中所示 圖 5。這是您的服務可以在 「 工作 」 在背景中。提供的取消語彙基元是針對該工作何時應該停止的訊號。

圖 5 中 Azure Service Fabric 無狀態服務的基礎結構

using Microsoft.ServiceFabric.Services;
namespace MyApp.MyStatelessService
{ 
  public class MyStatelessService : StatelessService
  {
    //... Service implementation
    protected override async Task RunAsync(CancellationToken cancellationToken)
    {   
      int iterations = 0;
      while (!cancellationToken.IsCancellationRequested)
      {
        ServiceEventSource.Current.ServiceMessage(this, "Working-{0}",
          iterations++);
        // Place to write your own background logic.
        // Example: Logic doing any polling task.
        // Logic here would be similar to what you usually implement in
        // Azure Worker Roles, Azure WebJobs or a traditional Windows Service.
         await Task.Delay(TimeSpan.FromSeconds(1), cancellationToken);
      }
      } 
    }
}

Azure Service Fabric 可靠服務中的通訊協定 Azure Service Fabric 可靠的服務提供可外掛式通訊模型。您可以使用您選擇的傳輸，例如 HTTP 與 ASP.NET Web API、 WebSockets、 Windows Communication Foundation、 自訂 TCP 通訊協定，依此類推。

您可以為您所選擇的通訊協定實作自己的程式碼，在您的服務或提供服務的網狀架構，例如 servicecommunicationlistener 進行通訊/ServiceProxy，也就是在 Service Fabric 可靠的服務架構所提供的預設通訊堆疊的任何通訊堆疊。也會與其他通訊堆疊，您可以插入服務網狀架構的個別 NuGet 封裝。

Service Fabric 微服務中使用 ASP.NET Web API 之前有提到，Service Fabric 可讓您決定您的服務進行通訊，但在.NET Framework 中建立 HTTP 服務最常見的方法之一是使用 ASP.NET Web API。

在 Service Fabric web API 是相同的 ASP.NET Web API 您熟知而且喜愛。使用控制器、 HttpRoutes，您可以建置 REST 服務的相同方式使用 MapHttpRoute 或屬性，您想要對應到 Http 路由的方法。當使用 Service Fabric 的差異在於裝載 Web API 應用程式的方式。第一次列入考量是，您無法使用 IIS 在 Azure Service Fabric 中，因為它使用起來複寫叢集中，所以您不必自我裝載 HTTP 接聽程式，在程式碼中的處理程序。若要執行的 Web API 服務，您有兩個選擇:

• 自我裝載 HTTP 接聽程式，Service Fabric 微服務處理序中的使用 ASP.NET 5 Web API (代碼名稱"專案 K")。
• 自我裝載 HTTP 接聽程式，Service Fabric 微服務處理序中的使用 OWIN/Katana 和 ASP.NET 4.x Web API。

執行 Azure Service Fabric 上的 ASP.NET 5 是最適合用來建置微服務，因為如先前所述，Service Fabric 可讓您將任何數目的服務部署至每個節點/VM，讓每個叢集的高微服務密度。此外，該高密度會更好時，Service Fabric 會接著傳遞.NET 核心 5 和 CoreCLR 支援未來 (下方 ASP.NET 5)。它將是 「 最適合的選擇 」 來達成超級高密度的微服務，因為.NET 核心 5 淺非常小的記憶體使用量，相較於完整.NET framework 4.x 架構。

使用 「 MVC 型別 」 Web 應用程式和服務網狀架構微服務 ASP.NET MVC 是一種非常受歡迎的架構為傳統的網站，但您不能使用 Service Fabric 中的 「 舊 」 MVC framework (MVC 5 或更舊版本)。這是因為，您需要在 Service Fabric 自我裝載 HTTP 接聽程式，在您的程序和 OWIN/Katana 不支援在 ASP.NET 4.x MVC (它 ASP.NET 4.x Web API 中只支援)。 因此，您必須在 Service Fabric 服務實作的 「 MVC 型別 」 Web 應用程式的選項如下所示:

• 使用 MVC 6 ASP.NET 5 中，以自我裝載 HTTP 接聽程式，Service Fabric 微服務處理序中。因為 ASP.NET 5 中 Web API 和 MVC 會合併，而且事實上 iis 沒有相依的同一個控制站相同的架構，它支援 MVC。ASP.NET 5 是發行製造會較適合的選擇。
• 使用 ASP.NET 4.x Web API 與 OWIN/Katana 自我裝載 HTTP 接聽程式，Service Fabric 微服務處理序中的，並模擬 MVC 控制站與 Web API 控制器，並使用 HTML/JavaScript 輸出而不是一般 Web API 內容 (JSON/XML)。在 [文件] 頁面上 bit.ly/1UMdKIf 示範如何實作這項技術。

實作自我裝載 ASP.NET 4.x Web API 與 OWIN/Katana

Web API 應用程式您經常使用這種方式，不會變更。它是與您在過去，撰寫的 Web API 應用程式和您應該只在移動大部分的應用程式程式碼。裝載應用程式可能與您要用來裝載在 IIS 上如果稍有不同。

CreateServiceReplicaListeners 方法在服務類別 這是服務定義了通訊堆疊它想来使用。通訊堆疊，例如 Web API，也會定義服務的接聽端點如何與服務程式碼的其餘部分互動會顯示這些訊息。

回到 service 類別之前有提到在 圖 4, ，我現在只需要加入新的方法呼叫 CreateServiceReplicaListeners，指定至少一個我想要使用的通訊堆疊。在此情況下，它是 Web API 所使用之 OwinCommunicationListener 所顯示的 圖 6。

圖 6 將 CreateServiceReplicaListeners 方法加入至無狀態服務類別

using Microsoft.ServiceFabric.Services;
namespace MyApp.MyStatelessService
{ 
  public class MyStatelessService : StatelessService
  {
    //... Service implementation.
    protected override async Task RunAsync(CancellationToken cancellationToken)
    {            
      // Place to write your own background logic here.
      // ...         
    }
    protected override IEnumerable<ServiceReplicaListener>
      CreateServiceReplicaListeners()
      {
        return new List<ServiceReplicaListener>()
        {
          new ServiceReplicaListener(parameters =>
            new OwinCommunicationListener(
            "api", new Startup()))
        };
      } 
    }
}

請務必反白顯示，您可以有多個通訊接聽程式加入至您的服務。

OwinCommunicationListener 類別是您想重複使用您的微服務的未定案程式碼。類似的方式，您可以插入其他通訊協定 (例如 WCF、 WebSockets 等) 中。

如果您正在建立 Web API 微服務，您仍然必須控制站沒有不同，您可能會用於實作 Web API 服務，如下列程式碼時的一般程式碼:

// Typical Web API Service class implementation
public class CustomerController : ApiController
{ 
  //// Example - GET /customers/MSFT
  [HttpGet]
  [Route("customers/{customerKey}", Name = "GetCustomer")]
  public async Task<IHttpActionResult> GetCustomer(string customerKey)
  {
    // ... Stateless method implementation.       
  }
}

由於本文是 Azure Service Fabric 和微服務的端對端概觀，我們將不會進行進一步實作 OWIN 到您的 Service Fabric 微服務的步驟。上有可用的簡單範例，您可以下載並分析 GitHub (bit.ly/1OW5Bmj): Web API 和服務網狀架構 HelloWorld 範例 (ASP.NET 4.x)。

實作自我裝載 ASP.NET 5 Web api

執行 Azure Service Fabric 上的 ASP.NET 5 是最適合用來建置微服務，因為 Service Fabric 可讓您將任何數目的服務部署至每個節點/VM，可以針對每個叢集的高微服務密度。ASP.NET 5 也提供令人興奮的功能，如下所示:

• 彈性的裝載: 您現在可以裝載在 IIS 上或您自己的處理序 ASP.NET 5 應用程式。在自己的程序中裝載的是，Azure Service Fabric 中的基礎。
• Web API、 MVC 和 Web 網頁: 這些是所有合併在一起，以簡化概念的數目。
• 完整的並存支援: ASP.NET 5 應用程式現在可以安裝在電腦上而不會影響其他任何應用程式可能使用不同的.NET Framework 版本的電腦上。這是 IT 管理龐大的功能。
• 跨平台支援: ASP.NET 5 執行，而且會在 Windows、 Mac OS X 及 Linux 上支援。
• 定域機組已備妥: 診斷、 工作階段狀態、 快取及組態等功能專為搭配本機和雲端中 (例如 Azure) 有任何變更。

展望未來，高密度功能會更好時，Service Fabric 會接著傳遞.NET 核心 5 和 CoreCLR 支援。

.NET Core 和 CoreCLR 仍在進行中的支援服務網狀架構，同時支援線上時的優點是清除。執行 ASP.NET 5.NET 核心 5 之上提供輕量級.NET framework 和 CoreCLR 執行階段非常小的記憶體使用量，相較於傳統的.NET 4.x。"微服務 B"] 面板中所示組合可讓擁有驚人的微服務密度 圖 7。

圖 7 比較在 CLR 與 ASP.NET 5 執行。服務網狀架構內容中的 CoreCLR

雖然.NET 核心 5 和 CoreCLR 支援未來的選項，企業可以準備它立即開發 ASP.NET 5 服務，在.NET 4.x 服務網狀架構上的。如此一來會輕鬆地將移轉至 CoreCLR 未來。

操作和部署超大規模微服務

作業和部署管理 Service Fabric 所提供其他的原因很它適合用來建置和執行在實際執行超大規模微服務。您可以專注於微服務開發，並讓 Service Fabric 提供深入剖析複雜的配管。

微服務的密度是一項優勢，如果您想要降低基礎結構成本。Service Fabric 叢集所組成的許多 Vm/伺服器 (而且在未來的容器) 稱為叢集中的節點集區。每個節點中 Service Fabric 會自動部署數個服務，因此您可以根據每個伺服器/VM 的電源營造超級高密度微服務的跨叢集。

Azure Service Fabric 中您可以在每個電腦或 VM 上執行數百個服務執行個體。提供反而會節省的總成本的擁有權 (TCO)。針對相同數量的服務，您將需要較少的硬體。比較 Azure 服務網狀架構使用 Azure 雲端服務，您要限制為每個服務的一個 VM 時，因此，較高的密度是大的不同點。如果您為 Web 角色或背景工作角色部署微服務您可能有太多的資源指派給單一的微服務，產生速度變慢時部署和管理。例如，在 圖 8 您可以看到每個服務的 Azure Web 角色或背景工作角色執行個體的一個 VM (色彩表示每個圖形中的服務類型或方塊表示不同的 VM 和服務執行個體)。如果您想要有較高的密度的微服務，除非您使用小型 Vm，這種方法不會幫助。不過，有所限制，而您將無法達到相同的層級較高的密度，相較於 Azure Service Fabric 其中一個部署中。

圖 8 服務密度比較 — 與 Azure 雲端服務。服務網狀架構

相較之下，在 Service Fabric 中，您可以部署任意數目的每個節點的微服務，讓服務的密度是更有效率且符合成本會降低。您可以有數十、 數百或甚至數千個 Vm/伺服器，每個叢集，數十或數百個微服務執行個體和每個 VM 節點/複本。另外，由於每個微服務是只是一個程序，部署和調整是很多較快，建立新的 VM，每個服務，做為 Azure 雲端服務的情況。

Azure 的雲端中建立叢集 之前部署微服務，您必須在 Azure 或內部部署伺服器中建立叢集的節點。在 Azure 雲端中建立叢集時 (例如您的生產或預備環境)，您可以直接從 Azure 入口網站或使用 Azure 資源管理員 (ARM) 工作。在 圖 9, ，您會看到我們使用 Azure 入口網站建立我們的 Azure 訂用帳戶中的 Service Fabric 叢集。實際上，叢集建立程序根據 Azure ARM 和 Azure 資源群組。在此情況下，我們會建立叢集的五個節點/Vm 也會在 Azure 資源群組內。

圖 9 Service Fabric 叢集在 Azure 入口網站

部署應用程式/服務叢集 節點/Vm 的叢集啟動並執行之後，您可以部署服務。部署至實際執行叢集時您通常使用 Windows PowerShell 指令碼來將您的應用程式/服務部署至在 Azure 中，叢集雖然預備/測試環境中您也可以部署直接從 Visual Studio。

當部署至您在開發使用 Visual Studio 2015 的 PC 上的本機叢集，您會通常部署直接從 IDE Service Fabric 應用程式專案上按一下滑鼠右鍵，然後選取部署。您也可以使用 Windows PowerShell 至開發叢集部署在您的膝上型電腦，因為在與 Azure 雲端叢集中的開發叢集中執行相同的 Service Fabric 位元。

日常作業及管理性的部署，才能維持長時間執行]，在順利執行的服務和應用程式生命週期管理功能已建置 Service Fabric 牢記在心的微服務架構方法。作業和管理 Service Fabric 提供的功能包含快速部署、 零停機時間的應用程式升級、 健全狀況監視的服務，和叢集向上延展和向下調整。零停機時間升級，可能會因為 Service Fabric 在升級的技術提供內建的輪流升級和自動健康情況檢查偵測並回復所做的變更中升級它們穩定應用程式組合。可以透過 Windows Powershell 命令，提供所有功能的 CLI 和指令碼，同時也支援視覺化工具，包括 Visual Studio，以方便使用 Service Fabric 叢集和應用程式的管理。

輪流升級階段中執行。在每個階段中，升級會套用到叢集中，稱為升級網域中的節點的子集。如此一來，應用程式仍然可在整個升級。您也可以有強式版本控制和並存的支援，您可以部署 v1 和 v2 版本相同的微服務和服務網狀架構會重新導向至一個或另一個，根據用戶端的要求。請檢查文件，網址 bit.ly/1kSupz8 如需詳細資訊。

當偵錯您的電腦中本機開發叢集內的服務，Visual Studio 方便即使服務的處理序已經在執行之前啟動的偵錯。IDE 自動附加至所有微服務處理程序與您的專案，以便輕鬆地開始使用和您的 Service Fabric 微服務程式碼中使用一般的中斷點。只要在您的程式碼中設定中斷點，然後按 f5 鍵。您不需要了解什麼處理您需要將連接 Visual Studio。

Service Fabric 總管 所述的 Service Fabric 總管 圖 10, 、 是 Web 型工具，若要以視覺化方式檢視已部署的應用程式的狀態，請檢查個別節點的內容叢集所提供，並執行各種系統管理動作。總管工具被由支援服務網狀架構 REST Api，您可以瀏覽至 http://<your-cluster-endpoint>:19007/Explorer 的相同 HTTP 閘道服務。如果本機叢集，此 URL 會是 http://localhost:19007/總管。

圖 10 Service Fabric 總管

如需 Service Fabric 總管的詳細資訊，請讀取文件頁面，「 視覺化您叢集使用 Service Fabric 總管 」 (bit.ly/1MUNyad)。

Service Fabric 平台可讓各種功能，可讓您專注於應用程式開發，而非實作複雜的健全狀況和升級的系統。這些技術包括：

向外延展無狀態服務 Service Fabric 的協調流程引擎可以自動調整您的 Web 應用程式分散到多個電腦每當新的節點加入至叢集。在建立無狀態服務的執行個體時，您可以指定您想要建立的執行個體數目。Service Fabric 會將該執行個體數目叢集中的節點上，並確保不會在任何一個節點上建立多個執行個體。您也可以指示 Service Fabric，一定要建立執行個體的每個節點指定"-1"的執行個體計數。這可確保每當您將向外擴充您的叢集節點時，您無狀態服務的執行個體要建立的新節點上。

自動資源平衡 Service Fabric 會提供服務資源平衡 」 (或服務的協調流程)，了解總計的可用資源 (例如在 vm 運算) 叢集中。它會自動移微服務，根據定義的原則和條件約束，以最佳最佳化跨 Vm 放置建立的服務的方式 (請參閱 圖 11)。這會著重於最佳化成本和效能。

圖 11 叢集會顯示於節點以及自動資源平衡的服務發佈

內建的容錯移轉和複寫中任何資料中心或公用雲端機器都有可能因未規劃的硬體失敗。為了防範這類案例 Service Fabric 提供內建的容錯移轉和複寫，這表示，雖然硬體問題的服務可用性不受影響。這可能是因為 Service Fabric 可以執行並管理多個執行個體，每個服務的電腦和故障網域。

放置條件約束 您可以指示叢集，或執行類似在相同機器/節點做為中介層微服務放入前端的微服務作業並避免將放在相同節點的微服務的特定類型。做法是已知的衝突降到最低，或確保特定微服務優先的存取權的資源。

負載平衡的要求 為無法與自動資源平衡混淆，負載平衡要求不會處理由 Service Fabric 但而是由 Azure 負載平衡器或其他外部服務網狀架構的平台。

健全狀況 可讓您監視和診斷您的系統。在應用程式升級期間也用來提供安全性檢查，因此如果升級具有 destabilizing 效果，就可以復原升級。如需詳細資訊，請參閱文件頁面，「 引進到服務網狀架構健全狀況監視 」 (bit.ly/1jSvmHB)。

在 Azure Service Fabric 無狀態微服務

可設定狀態服務的支援是令人興奮且重要的 Azure Service Fabric 元件。它也是複雜且廣泛夠探索可設定狀態的服務超出本文的範圍，但我們將簡短說明其為何。尋找後續的文章著重於 Service Fabric 的這個區域，在未來的問題。

在 Service Fabric 可設定狀態微服務 collocates 計算和與狀態的資料放在微服務本身 (記憶體中和在本機磁碟上保存)。可靠性的狀態是透過本機的持續性和資料複寫到其他節點/Vm 來達成。基本上，每個資料分割有多個複本服務與其相關聯。每個複本可以部署在不同節點/的 VM 以提供高可用性的主要複本都應。這是 Azure SQL 資料庫與資料庫複本的運作方式類似，因為它根據 Azure 服務網狀架構。

在複雜且可擴充的應用程式，可設定狀態的服務簡化架構，並減少相較於傳統三層式的架構必須使用外部快取和佇列的元件數目。使用可設定狀態的服務時，傳統的外部快取的優點是現在內建函式可設定狀態服務中。此外，我們可以實作 Service Fabric 微服務內的內部佇列，因此並不需要外部的佇列。

使用可設定狀態的服務時，它會自動建立作業中從相同主要離開硬體失敗後可以挑選的熱備份次要資料庫。多次服務具有可繼續滿足不斷增加的使用者基礎，需要新增至執行環境的硬體需求的小數位數。Service Fabric 會使用功能，例如資料分割，讓服務可以建置它們自動分散到新硬體不需要使用者介入的方式。

可設定狀態的 Azure 可靠的服務提供功能，包括資料分割支援、 複本支援和領導者 (英文)、 服務命名的複本，以及從閘道服務的服務位址探索的主機。它也提供管理並行存取和使用交易，能夠維持一致的狀態複寫，以及使用可靠的狀態變更的資料粒度分散式 (可靠的字典和可靠的佇列) 的索引鍵/值集合。好消息是，Service Fabric 會處理的複雜性和這些主題的詳細資料，因此您可以專注於撰寫應用程式。

在 Azure Service Fabric 可靠動作項目服務

Azure Service Fabric Reliable Actor 是 Service Fabric 動作項目程式設計模型。它提供非同步、 單一執行緒動作項目模型。動作項目代表狀態和計算的單位。在某些方面是類似的開放原始碼軟體專案 「 奧良"Microsoft Research 所建立。重要的一點是，Service Fabric 可靠動作項目 API 為基礎的 Service Fabric 所提供的基礎結構。

實作物聯網 (IoT) 裝置的動作項目執行個體是使用動作項目服務使用情況的例子。C# 類別的形式的車輛動作項目類型會封裝 IoT 車輛網域邏輯加上其即時的狀態，例如 GPS 座標與其他資料。接著，我們可能會有數百萬個動作項目物件，或該執行個體所述的類別，分散到叢集中許多節點。

當然，不限於即時 IoT 物件的動作項目，無法用於任何主題，但 「 即時 IoT 物件 」 是一個很棒的指導案例。

動作項目分散於叢集以達到高延展性和可用性，並會被視為記憶體中每個叢集 VM 中的物件。他們也會保存在本機磁碟上，透過叢集複寫。

動作項目是封裝狀態和行為隔離的單一執行緒的物件。每個動作項目是動作項目類型，類似如下所示的.NET 程式碼的執行個體:

// Actor definition (State+Behaviour) to run in the back end.
// Object instances of this Actor class will be running transparently
// in the service back end.
public class VehicleActor : Actor<Vehicle>, IVehicleActor
{
  public void UpdateGpsPosition(GpsCoordinates coord)
  { 
    // Update coordinates and trigger any data processing
    // through the State property on the base class Actor<TState>.
    this.State.Position= coord;
  }
}

接下來，下列程式碼顯示範例用戶端程式碼將透過 proxy 物件的動作項目:

// Client .NET code
ActorId actorId = ActorId.NewId();
string applicationName = "fabric:/IoTVehiclesActorApp";
IVehicleActor vehicleActorProxy =
  ActorProxy.Create<IVehicleActor>(actorId, applicationName);
vehicleActorProxy.UpdateGpsPosition(new GpsCoordinates(40.748440, -73.984559));

所有通訊基礎結構都一切都是實際上由 Service Fabric Reliable Actor 架構。

您可能會有數百萬個 VehicleActor 跨許多不同節點/Vm，在叢集上執行的物件和服務網狀架構就會負責需要的配管，包括資料分割和複本，您將數百萬個動作項目，其中分散且平均。

動作項目用戶端 API 提供動作項目執行個體與動作項目用戶端之間的通訊。與動作項目通訊，用戶端會建立實作動作項目介面的動作項目 proxy 物件。用戶端互動的 proxy 物件上叫用方法的動作項目。

動作項目適用於什麼情況的案例，其中大幅簡化了微服務實作，尤其是相較於可設定狀態可靠服務您有更多控制，但需要實作許多相關的資料分割的細節，資料分割定址、 複本和類似。如果您不需要細微控制，您可以使用可靠動作項目避免額外的工作。

總結

微服務架構需要非集中式的方法、 專業的架構和設計程序、 Azure Service Fabric 中，等新技術和小組動態小型開發團隊和 Agile 依據微服務套用的原則變更的認可。

Cesar de la Torre是 microsoft 的資深專案經理，並且住在美國華盛頓州 Redmond他的興趣包括 Microsoft Azure 和.NET 開發方法，例如微服務架構和網域導向設計，以及呈現服務的行動應用程式開發。

Kunal 深層 Singh是 Microsoft Azure Service Fabric 小組的資深專案經理。在 Azure 之前，他曾在多個版本的 Windows Phone、 Silverlight 和 Xbox 標題的遊戲開發人員。他居住在美國華盛頓州西雅圖

Vaclav Turecek是 microsoft 的資深專案經理。他負責靈魂傑出的一群人進行 Azure Service Fabric 的最佳的下一代平台即服務。

感謝下列 Microsoft 技術專家共同撰寫和檢閱這份文件: 作者: Mark Fussell
作者: Mark Fussell 是熱衷於建置雲端規模應用程式，需要花費多年 microsoft 建立其他的伺服器端技術範圍從資料存取和通訊的產品。他是興奮地看到，Microsoft 已 Service Fabric 提供給每個人的微服務方式使用建置應用程式。