# Microsoft Azure - Azure Service Fabric 和微服務體系結構 作者?[Cesar de la Torre](https://msdn.microsoft.com/zh-cn/magazine/mt149362?author=Cesar+de+la+Torre)、[Kunal Deep Singh](https://msdn.microsoft.com/zh-cn/magazine/mt149362?author=Kunal+Deep+Singh)、[Vaclav Turecek](https://msdn.microsoft.com/zh-cn/magazine/mt149362?author=Vaclav+Turecek)?| 2015 年 12 月 微服務是目前的流行語。雖然關于此主題的演示文稿和會議演講有很多，但許多開發者仍對此感到困惑。我們經常會聽到有人提出這樣的疑問： “這不就是另一種面向服務的體系結構 (SOA) 或域驅動設計 (DDD) 方法嗎？” 當然，微服務方法中使用的許多技術都是源自開發者的 SOA 和 DDD 體驗。您可以將微服務看成是“處理得當的 SOA”，具有自治服務、界定上下文模式和事件驅動等原則和模式（均以 SOA 和 DDD 為根源）。 在本文中，我們將介紹微服務理論和實現。我們將先對微服務進行簡單介紹，然后轉向實際運用方面，介紹如何使用 Azure Service Fabric 構建和部署微服務。最后，我們將說明為什么此平臺非常適合構建微服務。 顧名思義，微服務體系結構是一種將服務器應用程序構建為一組小型服務的方法，每個服務都按自己的進程運行，并通過 HTTP 和 WebSocket 等協議相互通信。每個微服務都在特定的界定上下文（每服務）中實現特定的端到端域和業務功能，并且必須由自動機制進行自主開發和獨立部署。最后，每個服務都應該擁有自己的相關域數據模型和域邏輯，并能使用不同的數據存儲技術（SQL 和非 SQL），對每個微服務使用不同的編程語言。 微服務示例包括協議網關、用戶配置文件、購物車、庫存處理、購買子系統、付款處理以及隊列和緩存。 為什么要使用微服務？ 一言以蔽之，就是因為靈活性。從長遠來看，微服務能夠將應用程序設計為基于許多可獨立部署且能制定具體發布規劃的服務，從而可以在復雜的可高度擴展大型系統中實現極高的可維護性。 微服務的另外一大優勢是，可以獨立擴展。您可以擴展特定的微服務，而無需一次性擴展龐大的應用程序塊整體。這樣一來，可以單獨擴展需要更多處理能力或網絡帶寬以支撐需求的功能區域，而不用擴展應用程序中實際并不需要更多處理能力或網絡帶寬的其他區域。 通過構建精細的微服務應用程序，您可以持續集成和開發，并能加速在應用程序中實現新功能。通過精細分解應用程序，您還可以單獨運行和測試微服務，并能在保持微服務之間的嚴格協定的同時獨立發展微服務。只要您不破壞協定或接口，就可以在后臺更改任何微服務實現，并能添加新功能，而不破壞其他依賴微服務。 使用微服務方法，根本宗旨就是借助靈活更改和快速迭代實現高效率，因為您可以更改復雜的可擴展大型應用程序的特定一小部分（如圖 1?所示）。 ? 圖 1：微服務方法與傳統服務器應用程序方法的對比 ## 每個微服務的數據主權 這種方法遵循的一項重要規則是，每個微服務都必須擁有自己的域數據和邏輯（在自治生命周期內），且每個微服務都必須獨立部署。這實際上與完整的應用程序擁有自己的邏輯和數據別無二致。 也就是說，使用此方法，域的概念模型因子系統或微服務而異。以企業應用程序為例，其中客戶關系管理 (CRM) 應用程序、交易購買子系統和客戶支持子系統各自調用唯一客戶實體屬性和數據，并采用不同的界定上下文。 此原則與 DDD 中的原則類似，即每個界定上下文（可與子系統/服務相比的模式）必須擁有自己的域模型（數據和邏輯）。每個 DDD 界定上下文均與不同的微服務相關聯。 另一方面，許多應用程序中使用的傳統（或整體）方法是對整個應用程序及其所有內部子系統使用一個集中數據庫（通常是規范化 SQL 數據庫），如圖 2?所示。這種方法起初看來比較簡單，似乎能夠在不同的子系統中重復使用實體，從而保持所有對象的一致性。但實際上，您最終會得到為許多不同的子系統提供服務的大型表格，其中包括大多數情況下并不需要的屬性和列。這相當于在進行短途徒步旅行、一天自駕游和學習地理知識時使用同一張自然地圖。 ? 圖 2：數據主權比較： 微服務與整體 ## 微服務無狀態還是有狀態？ 如前所述，每個微服務都必須擁有自己的域模型。對于無狀態微服務，數據庫是外部的，并采用 SQL Server 等關系選項，或 MongoDB 或 Azure Document DB 等 NoSQL 選項。進一步探究發現，服務本身可以是有狀態的，也就是說數據駐留在同一微服務中。此類數據不僅可以存在于同一服務器中，還可以存在于同一微服務進程中、內存中、硬盤驅動器中，并能復制到其他節點。 無狀態是非常有效的方法，比有狀態微服務更易于實現，因為無狀態類似于傳統的已知模式。不過，無狀態微服務會導致進程和數據源之間出現延遲，同時還會在通過其他緩存和隊列提高性能時呈現更多移動對象。結果就是，您最終會得到包含許多層級的復雜體系結構。 另一方面，有狀態微服務在高級方案中脫穎而出，因為域邏輯和數據之間沒有延遲。繁重的數據處理、游戲后端、數據庫即服務和其他低延遲方案都受益于有狀態服務，因為它能啟用本地狀態以提高訪問速度。 缺點是， 有狀態服務會增加復雜性，加大了擴展難度。對于跨有狀態微服務副本的數據復制、數據分區等問題，必須實施通常在外部數據庫邊界內實現的功能。而這正是 Service Fabric 最有幫助的一個地方，即簡化有狀態微服務的開發和生命周期。 ## Azure Service Fabric 的優點 微服務方法的任何優點都伴隨著缺點。如果您親自操作，則會發現分布式計算和復雜的微服務部署很難管理。Service Fabric 提供了一種體系，方便您以卓有成效的方式創建、部署、運行和管理微服務。 什么是 Service Fabric？ 它是一種分布式系統平臺，用于構建面向云的可高度擴展且易于管理的可靠應用程序。Service Fabric 可應對開發和管理云應用程序的巨大挑戰。通過使用 Service Fabric，開發者和管理員無需解決復雜的基礎結構問題，只需專注于實現要求非常高的任務關鍵型工作負載即可，因為他們知道應用程序既可擴展，又可管理，而且還十分可靠。Service Fabric 代表 Microsoft 的下一代中間件平臺，用于構建和管理這些企業級第 1 級云擴展服務。 Service Fabric 是一種通用的部署環境；您可以部署基于任意語言（Microsoft .NET Framework、Node.js、Java 和 C++）或數據庫運行時（如 MongoDB）的所有可執行文件。 因此，請務必明確一點，Azure Service Fabric 并不局限于面向微服務的應用程序。您還可以使用它來托管和部署傳統應用程序（Web 應用或服務），并收獲許多與可擴展性、負載平衡和快速部署相關的好處。不過，Azure Service Fabric 仍是從零開始構建的全新平臺，專為超大規模和基于微服務的系統而設計（如圖 3?所示）。 ? 圖 3：Microsoft Azure Service Fabric 下面介紹了 Service Fabric 的一些優點： * 在 Azure、本地或任意云中運行。Service Fabric 的一個非常重要的特征是，您不僅可以在 Azure 上運行它，還可以在本地、您自己的裸機服務器或虛擬機 (VM) 上運行它，甚至能在其他第三方托管云中運行它。并沒有與特定的云綁定。您甚至可以在 Amazon Web Services (AWS) 中運行 Service Fabric 群集。 * 支持 Windows 或 Linux。目前（2015 年底），Service Fabric 支持 Windows，但它還將支持 Linux 和容器（Windows 圖像和 Docker 圖像）。 * 已經過全面審查。幾年來，Microsoft 一直在使用 Service Fabric 為其許多云產品提供強力支持。 Service Fabric 的產生是因為需要在 Microsoft 內構建大規模服務。使用 SQL Server 等產品并將它們構建為云中可用的服務（Azure SQL 數據庫），同時保持靈活性、可靠性、可擴展性和成本效益性，就需要能有效滿足所有這些需求的分布式技術。雖然可滿足這些復雜方案需求的核心技術已在構建，但 SQL Server 顯然不是唯一取得此類重大突破的產品。Skype for Business 等產品不得不解決類似問題，以便在成為基于微服務的應用程序的道路上取得發展。面對這些挑戰，Service Fabric 這一應用程序平臺應運而生，已廣泛用于 Microsoft 的許多大規模服務，這些服務具有不同的體系結構和大規模運行需求。InTune、DocumentDB 以及 Cortana 和 Skype for Business 的后端都是在 Service Fabric 上運行的服務。 憑借在任務關鍵型系統方面的經驗，Microsoft 設計出一種平臺，能夠自發了解可用的基礎結構資源和可擴展的應用程序的需求。它啟用了自動更新的自愈行為，這對以超大規模交付高度可用的持久性服務至關重要。Microsoft 現在將這一“久經沙場”的技術向所有人推出。 ## Azure Service Fabric 編程模型 Service Fabric 提供以下兩種簡略框架來構建服務：Reliable Services API 和 Reliable Actors API。雖然這兩種框架均在同一 Service Fabric 核心的基礎上構建而成，但在并發、分區和通信方面，它們在簡潔性和靈活性之間的取舍不同（如圖 4?所示）。了解這兩種模型的工作方式非常有用。這樣，您便能選擇更適合您的服務的框架。在許多應用程序方案中，您可以使用混合方法，并對特定微服務使用執行組件，同時對大量執行組件生成的聚合數據使用 Reliable Services。因此，可靠的服務可以在許多常見方案中安排執行組件服務。 圖 4：比較 Service Fabric 編程模型 | Reliable Actor API | Reliable Services API | |--------|--------|--------| | 您的方案涉及許多獨立的小單元/狀態對象和邏輯（具有說服力的示例包括，實際物聯網對象或游戲后端方案） | 您需要跨多個實體類型和組件維護邏輯和查詢 | | 您要處理大量單線程對象，同時仍能進行擴展并保持一致性 | 您使用可靠的集合（如 .NET 的可靠字典和隊列）來存儲和管理您的狀態/實體 | | 您想讓框架管理狀態的并發和粒度 | 您想控制狀態的粒度和并發 | | 您想讓 Service Fabric 為您管理通信實現 | 您想選定、管理和實現通信協議（Web API、WebSocket 和 Windows Communication Foundation 等） | | 您想讓 Service Fabric 管理有狀態執行組件服務的分區架構，以便對您保持透明 | 您想控制有狀態服務的分區架構 | ## 使用 Azure Service Fabric 構建無狀態微服務 Azure Service Fabric 中的微服務可以是您想在服務器中創建的幾乎所有進程，無論語言是 .NET Framework、Node.js、Java 還是 C++。目前，僅 Service Fabric API 的 .NET 和 C++ 庫可用。因此，您需要在 .NET Framework 或 C++ 中實現微服務，以便實現低級別實現。 如上文所述，無狀態微服務是指存在進程（如前端服務或業務邏輯服務），但確實沒有狀態暫留的服務，或出現的狀態在進程結束時丟失且不需要同步、復制、暫留或高可用性的服務。可能存在相關的外部狀態，但暫留在外部存儲中，如 Azure SQL 數據庫、Azure 存儲空間、Azure DocumentDB 或其他任何第三方存儲引擎（關系或 NoSQL）。因此，任何現有服務（如在云服務上運行的 ASP.NET Web API 服務、輔助角色或 Azure Web 應用）都會輕松地遷移到 Service Fabric 無狀態服務中。 若要設置開發環境，您需要使用 Service Fabric SDK 來運行不是仿真器的本地部署群集，但運行位數與 Azure 中一樣。此外，Visual Studio 2015 工具集成還可以讓開發和調試變得更加輕松。 在本地計算機中部署和調試服務前，您需要先創建節點群集。為此，您可以運行名為 DevClusterSetup.ps1 的 Windows PowerShell 腳本，如文檔頁“準備開發環境”([bit.ly/1Mfi0LB](http://bit.ly/1Mfi0LB)) 中的“安裝和啟動本地群集”部分所述。您可以參閱此頁，逐步了解整個設置流程。 無狀態服務基類?- 所有無狀態 Service Fabric 服務類都必須源自 Microsoft.ServiceFabric.Services.StatelessService 類。此類提供與 Service Fabric 群集和執行環境相關的 API 方法和上下文，并掛鉤到您服務的生命周期。 無論您的服務是有狀態還是無狀態，Reliable Services 均提供簡單的生命周期，以便您能夠快速插入代碼并開始操作。實際上，您只需實現一個或兩個方法（通常是 RunAsync 和 CreateServiceReplicaListeners）就能啟動并運行 Service Fabric 服務，我們將在深入探討通信協議時介紹這兩種方法。 請注意，圖 5?中展示了 RunAsync。在這里，您的服務可以在后臺“正常運行”。提供的取消令牌是應停止工作的信號。 圖 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 Reliable Services 中的通信協議?- Azure Service Fabric Reliable Services 提供可插入通信模型。您可以使用所選擇的傳輸協議，如帶 ASP.NET Web API 的 HTTP、WebSocket、Windows Communication Foundation 和自定義 TCP 協議等。 您可以在服務中為選定通信協議實現自己的代碼，也可以使用 Service Fabric 隨附的任意通信堆棧（如 ServiceCommunicationListener/ServiceProxy，這是 Service Fabric 中由 Reliable Services 框架提供的默認通信堆棧）。您還可以將包含其他通信堆棧的獨立 NuGet 包插入 Service Fabric 中。 在 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 應用程序的方式。首先要考慮到，您無法在 Azure Service Fabric 中使用 IIS，因為它只能使用跨群集復制的普通進程，所以您必須在代碼中自托管 HTTP 偵聽器。為了對 Web API 服務執行此操作，您有以下兩種選擇： * 使用 ASP.NET 5 Web API（代碼名稱“Project K”），在您的 Service Fabric 微服務進程中自托管 HTTP 偵聽器。 * 使用 OWIN/Katana 和 ASP.NET 4.x Web API，在您的 Service Fabric 微服務進程中自托管 HTTP 偵聽器。 在 Azure Service Fabric 之上運行 ASP.NET 5 最適合構建微服務，因為如上文所述，Service Fabric 允許您將任意數量的服務部署到每個節點/VM，同時對每個群集實現較高的微服務密度。此外，當 Service Fabric 最終在未來提供 .NET Core 5 和 CoreCLR 支持（在 ASP.NET 5 下）時，高密度功能還會變得更強。最好能實現超高密度的微服務，因為 .NET Core 5 是輕型框架，與完整的 .NET 4.x Framework 相比，它占用的內存非常少。 使用 MVC 型 Web Apps 和 Service Fabric 微服務?- ASP.NET MVC 是一種很常用的框架，用于構建傳統網站，但您無法結合使用“舊的”MVC 框架（MVC 5 或更低版本）和 Service Fabric。這是因為在 Service Fabric 中，您需要在進程中自托管 HTTP 偵聽器，并且 OWIN/Katana 不受 ASP.NET 4.x MVC 支持（僅受 ASP.NET 4.x Web API 支持）。 因此，在 Service Fabric 服務上實現 MVC 型Web 應用程序的選項如下所示： * 在 ASP.NET 5 中使用 MVC 6，在您的 Service Fabric 微服務進程中自托管 HTTP 偵聽器。它支持 MVC，因為在 ASP.NET 5 中，Web API 和 MVC 已合并，實際上兩者是具有相同控制器的同一框架（不依賴 IIS）。只要 ASP.NET 5 已發布以供生產，這就將是首選選項。 * 使用帶 OWIN/Katana 的 ASP.NET 4.x Web API 在您的 Service Fabric 微服務進程中自托管 HTTP 偵聽器，通過 Web API 控制器模擬 MVC 控制器，并使用 HTML/JavaScript 輸出，而不是常規的 Web API 內容 (JSON/XML)。[bit.ly/1UMdKIf](http://bit.ly/1UMdKIf)?上的文檔頁說明了如何實現這一技術。 ## 使用 ASP.NET 4.x Web API 和 OWIN/Katana 實現自托管 對于此方法，您以前經常使用的 Web API 應用程序并未發生改變。這與您以前可能編寫過的 Web API 應用程序并無二致，您應該能夠立即移動大部分的應用程序代碼。如果您一直在 IIS 上進行托管，則應用程序托管方式可能與您以前常用的托管方式略有差異。 服務類中的 CreateServiceReplicaListeners 方法?- 在這里，服務可以定義要使用的通信堆棧。通信堆棧（如 Web API）用于定義服務的偵聽終結點，以及這些顯示的消息如何與剩余的服務代碼進行交互。 回到上文圖 4?中提及的服務類，我現在只需添加名為 CreateServiceReplica-Listeners 的新方法，即可指定至少一個我想使用的通信堆棧。在此示例中，就是 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、WebSocket 等）。 如果您要創建 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 和微服務的端到端概述，因此我們不會進一步逐步介紹如何在 Service Fabric 微服務中實現 OWIN。GitHub 上提供了一個簡單示例 ([bit.ly/1OW5Bmj](http://bit.ly/1OW5Bmj))，可供您下載和分析， 即 Web API 和 Service Fabric 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 和網頁： 所有這些合并在一起，簡化了概念的數目。 * 全面的并行支持： ASP.NET 5 應用程序現在可以安裝在計算機上，而不會影響計算機上其他任何可能使用不同 .NET Framework 版本的應用程序。這是一項重要的 IT 管理功能。 * 跨平臺支持： ASP.NET 5 可在 Windows、Mac OS X 和 Linux 上運行，并受到這些操作系統支持。 * 云就緒： 診斷、會話狀態、緩存和配置等功能既可以在本地運行，也可以在云（如 Azure）中運行，而無需進行任何更改。 展望未來，當 Service Fabric 最終提供 .NET Core 5 和 CoreCLR 支持時，高密度功能還會變得更強。 雖然對 .NET Core 和 CoreCLR 的支持仍需通過 Service Fabric 實現，但如果此類支持上線，則受益明顯。在 .NET Core 5 之上運行 ASP.NET 5 可提供輕型 .NET Framework 和 CoreCLR 運行時，與傳統的 .NET 4.x 相比，它占用的內存非常少。這樣的組合會形成極高的微服務密度，如圖 7?中的“微服務 B”面板所示。 ? 圖 7：比較在 Service Fabric 上下文中在 CLR 與 CoreCLR 上運行 ASP.NET 5 雖然 .NET Core 5 和 CoreCLR 支持在將來才能提供，但企業現在就可以做好準備，即在 Service Fabric 的 .NET 4.x 之上開發 ASP.NET 5 服務。這樣，可以在將來更輕松地遷移到 CoreCLR。 ## 操作和部署超大規模微服務 Service Fabric 非常適合構建和運行超大規模生產微服務還有其他原因，即它提供操作和部署管理。您可以專注于微服務開發，并讓 Service Fabric 在后臺提供所有復雜的體系。 如果您希望降低基礎結構成本，那么較高的微服務密度將大有助益。Service Fabric 群集包括一個由許多 VM/服務器（以及將來的容器）組成的池，這些 VM/服務器在群集中稱為“節點”。在每個節點中，Service Fabric 自動部署多個服務，因此，您可以在整個群集中實現超高的微服務密度，具體視每個服務器/VM 的性能而定。 在 Azure Service Fabric 中，您可以在每個計算機或 VM 上運行數百個服務實例。這會大大降低您的總擁有成本 (TCO)。對于相同數量的服務，您需要的硬件變少了。因此，在比較 Azure Service Fabric 和 Azure 云服務且限制為對每個服務使用一個 VM 時，高密度就是非常重要的區分因素。如果您曾將微服務部署為 Web 角色或輔助角色，則您可能向一個微服務分配了太多的資源，導致部署和管理速度降低。例如，在圖 8?中，您可以看到示例以 Azure Web 角色或輔助角色的形式，對每個服務實例使用一個 VM（顏色表示服務類型，而每個形狀或框則表示不同的 VM 和服務實例）。如果您希望實現較高的微服務密度，那么這種方法將不起作用，除非您使用小型 VM。不過，由于存在限制，因此與 Azue Service Fabric 相比，您無法在兩個部署中實現相同的高密度級別。 ? 圖 8：服務密度比較 - Azure 云服務與 Service Fabric 相比之下，在 Service Fabric 中，您可以對每個節點部署任意數量的微服務，因此服務密度將更加高效，并且成本也會降低。您可以對每個群集部署數十個、數百個或者甚至數千個 VM/服務器，并對每個節點/VM 部署數十個或數百個微服務實例和副本。由于每個微服務只是一個進程，因此部署和擴展比對每個服務新建一個 VM 要快很多，Azure 云服務也是如此。 在 Azure 云中創建群集?- 在部署微服務之前，您需要在 Azure 或本地服務器中創建節點群集。在 Azure 云（類似于您的生產環境或過渡環境）中創建群集時，您可以直接使用 Azure 門戶或 Azure 資源管理器 (ARM)。在圖 9?中，您可以看到我們使用 Azure 門戶在 Azure 訂閱中創建的 Service Fabric 群集。從本質上看，群集創建進程是以 Azure ARM 和 Azure 資源組為基礎。在此示例中，我們創建了包含五個節點/VM 的群集，這些節點/VM 也位于 Azure 資源組中。 ? 圖 9：Azure 門戶中的 Service Fabric 群集 將應用程序/服務部署到群集?- 在啟動并運行節點/VM 的群集后，您便可以部署服務。在向生產群集部署時，您通常可以使用 Windows PowerShell 腳本將您的應用/服務部署到 Azure 中的群集；不過，對于過渡環境/測試環境，您還可以直接從 Visual Studio 部署。 在使用 Visual Studio 2015 向開發 PC 上的本地群集部署時，您通常可以右鍵單擊 Service Fabric 應用程序項目并選擇“部署”，從而直接從 IDE 進行部署。您還可以使用 Windows PowerShell 向筆記本電腦中的開發群集部署，因為在開發群集中運行的 Service Fabric 位數與在基于 Azure 云的群集中運行的 Service Fabric 位數相同。 部署的日常操作和可管理性是確保服務長期順利運行所必需的，應用程序生命周期管理功能已內置到 Service Fabric 中，將基于微服務的方法納入考慮。Service Fabric 中可用的操作和管理功能包括快速部署、在應用程序升級期間不停機、服務的運行狀況監視以及群集增加和減少。支持在升級期間不停機，因為 Service Fabric 中的升級技術提供滾動升級和自動運行狀況檢查的內置組合，用于檢測和回退升級中可破壞應用程序穩定性的更改。可通過 Windows Powershell 命令管理 Service Fabric 群集和應用程序，同時提供 CLI 和腳本的所有功能，并支持包括 Visual Studio 在內的視覺工具以提高易用性。 滾動升級分階段執行。在每個階段，升級應用于群集中的一部分節點（稱為“升級域”）。因此，在整個升級期間應用程序仍可用。您還可以使用功能強大的版本控制和并行支持，以便部署同一微服務的 v1 和 v2 版本。Service Fabric 會重定向到其中一種版本，具體視客戶端的請求而定。有關更多詳細信息，請查看?[bit.ly/1kSupz8](http://bit.ly/1kSupz8)?上的文檔。 在 PC 上的本地開發群集中調試服務時，即使服務進程在您啟動調試前已經運行，Visual Studio 也能簡化調試過程。IDE 自動附加到所有與您的項目相關的微服務進程中，以便您可以輕松入門，并在 Service Fabric 微服務代碼中使用常規斷點。只需在代碼中設置斷點，然后點擊 F5 即可。您無需了解需要將 Visual Studio 附加到什么進程。 Service Fabric 資源管理器?- Service Fabric 資源管理器（如圖 10?所示）是一種由群集提供的基于 Web 的工具，可用于直觀地顯示已部署應用程序的狀態、檢查各個節點的內容，以及執行各種管理操作。資源管理器工具由支持 Service Fabric REST API 的相同 HTTP 網關服務提供，可通過導航至 http://:19007/Explorer 獲取此工具。在使用本地群集的情況下，此 URL 為 http://localhost:19007/Explorer。  圖 10：Service Fabric 資源管理器 有關 Service Fabric 資源管理器的更多詳細信息，請閱讀文檔頁“使用 Service Fabric 資源管理器直觀顯示群集”([bit.ly/1MUNyad](http://bit.ly/1MUNyad))。 Service Fabric 平臺提供一系列功能，以便您能夠專注于應用程序開發，而不用擔心實現復雜的運行狀況和可升級系統。其中： 擴展無狀態服務?- Service Fabric 業務流程引擎可以跨更多計算機自動擴展您的 Web 應用，無論新節點何時添加到群集中。創建無狀態服務的實例時，您可以指定要創建的實例數量。Service Fabric 會相應地將此數量的實例置于群集的節點上，以確保不在任何一個節點上創建多個實例。您還可以將實例計數指定為“-1”，從而指示 Service Fabric 在每個節點上始終創建一個實例。這樣一來，無論您何時添加節點以擴展群集，都可以保證在新節點上創建無狀態服務的實例。 自動資源平衡?- Service Fabric 提供服務資源平衡（或服務業務流程）功能，用于了解群集中可利用的資源總量（類似于從 VM 進行計算）。它會根據定義的策略和約束自動移動微服務，以便最大程度地優化已創建的服務跨 VM 的分布方式（請參閱圖 11）。這側重于優化成本和性能。 ? 圖 11：顯示跨節點服務分發的群集和自動資源平衡 內置故障轉移和復制?- 任何數據中心或公有云中的計算機都容易發生計劃外硬件故障。為了防止出現這種情況，Service Fabric 提供了內置故障轉移和復制功能。也就是說，盡管出現硬件問題，服務的可用性也不會受到影響。這是可以實現的，因為 Service Fabric 能夠跨計算機和故障域運行和管理每個服務的多個實例。 位置約束?- 您可以指示群集執行下面這樣的操作：不要將前端微服務作為中間層微服務置于同一計算機/節點中，以避免在相同節點中并置某些類型的微服務。做到這一點，可以最大限度地減少已知沖突，或確保優先訪問某些微服務的資源。 請求的負載平衡?- 不要與自動資源平衡混淆，請求的負載平衡不是由 Service Fabric 處理，而是由 Azure 負載平衡器或 Service Fabric 外部的其他平臺進行處理。 運行狀況?- 您可以監視和診斷系統。還在應用程序升級期間使用，以提供安全檢查，從而在升級會破壞穩定性的情況下回退升級。有關詳細信息，請參閱文檔頁“Service Fabric 運行狀況監視簡介”([bit.ly/1jSvmHB](http://bit.ly/1jSvmHB))。 ## Azure Service Fabric 中的有狀態微服務 支持有狀態服務是 Azure Service Fabric 的一個重要組成部分，令人非常滿意。這也是相當復雜且涉及面非常廣的問題，探討有狀態服務不在本文的討論范圍內，但我們將會簡單地介紹一下什么是有狀態服務。請在今后幾期中，關注重點介紹 Service Fabric 這一領域的后續文章。 Service Fabric 中的有狀態微服務并置計算和數據，并將狀態置于微服務本身之中（位于內存中且暫留在本地磁盤上）。狀態的可靠性是通過在其他節點/VM 上進行數據本地暫留和復制而實現的。一般來說，每個數據分區都有多個與其相關聯的副本服務。每個副本都可以在不同的節點/VM 中進行部署，以在主要副本不可用時提供高可用性。這就類似于 Azure SQL 數據庫如何使用數據庫副本，因為它是基于 Azure Service Fabric。 在復雜的可擴展應用程序中，與需要使用外部緩存和隊列的傳統三層體系結構相比，有狀態服務簡化了體系結構，并減少了組件數量。使用有狀態服務，傳統外部緩存的優點現在為有狀態服務所固有。此外，不需要外部隊列，因為我們可以在 Service Fabric 微服務中實現內部隊列。 使用有狀態服務，它可以自動創建熱備份方案，以便從出現硬件故障后主要服務中斷的同一點處選取操作。服務必須擴展多次才能繼續滿足不斷擴增的用戶群的需求，同時需要向運行環境添加硬件。Service Fabric 使用分區等功能，這樣構建的服務就可以自動分布在新硬件上，而無需用戶干預。 有狀態 Azure Reliable Services 提供許多功能，包括數據分區支持、副本支持和首項選擇、副本服務命名以及服務地址發現（來自網關服務）。借助事務，它還提供狀態更改的并發和粒度管理，可以保持一致的狀態復制，并使用可靠的已分發鍵/值集合（可靠字典和可靠隊列）。值得慶幸的是，Service Fabric 為您處理這些主題中討論的復雜問題和細節，以便您可以專注于編寫應用程序。 ## Azure Service Fabric 中的 Reliable Actors 服務 Azure Service Fabric Reliable Actors 是 Service Fabric 的執行組件編程模型。它提供異步單線程的執行組件模型。執行組件表示狀態和計算單元。在某些方面，它類似于 Microsoft Research 創建的開放源代碼軟件項目“Orleans”。重要的是，Service Fabric Reliable Actors 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; ? } } ~~~ 接下來，以下代碼展示了通過代理對象使用執行組件的示例客戶端代碼： ~~~ // 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 Actors 框架負責。 您可能會有數百萬個 VehicleActor 對象跨許多不同的節點/VM 在您的群集上運行，Service Fabric 會負責相應的體系，包括作為數百萬個執行組件的分布和平衡位置的分區和副本。 Actors 客戶端 API 提供執行組件實例和執行組件客戶端之間的通信。為了與執行組件通信，客戶端會創建用于實現執行組件接口的執行組件代理對象。客戶端通過在代理對象上調用方法，與執行組件進行交互。 對于執行組件適用的方案，它極大地簡化了微服務實現，尤其是與有狀態 Reliable Services 相比時。使用有狀態 Reliable Services 時，您雖然擁有更多的控制，但需要實現許多與分區數據、分區尋址、副本等相關的體系。如果您不需要精細控制，則可以使用 Reliable Actors 避免額外工作量。 ## 總結 微服務體系結構離不開以下組成部分：分散式方法、符合標準的體系結構和設計流程、Azure Service Fabric 等新技術、團隊動力變更以便向小型開發團隊方向發展，以及對每個微服務應用的靈活原則。 * * * Cesar de la Torre?*是 Microsoft 高級項目經理，居住在美國華盛頓州雷蒙德市。他的研究興趣包括通過以下方法進行 Microsoft Azure 和 .NET 開發：微服務體系結構、域驅動的設計以及面向服務的移動應用開發。* Kunal Deep Singh?*是 Microsoft Azure Service Fabric 團隊的高級項目經理。在 Azure 推出之前，他致力于發布 Windows Phone、Silverlight 的多個版本，并且是 Xbox 主題的游戲開發者。他居住在美國華盛頓州西雅圖市。* Vaclav Turecek?*是 Microsoft 高級項目經理。他致力于與極有天賦的團隊一起工作，將 Azure Service Fabric 打造成為最強大的下一代平臺即服務。*