# 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 中提及的服务类，我现在只需添加名为 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、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 打造成为最强大的下一代平台即服务。*
- 介绍
- Visual Studio - 用于 Web 开发的新式工具： Grunt 和 Gulp
- 新员工 - 放长钱钓大鱼
- Microsoft Azure - Azure Service Fabric 和微服务体系结构
- 数据点 - Aurelia 与 DocumentDB 结合： 结合之旅（第 2 部分）
- 游戏开发 - Babylon.js： 构建 Web 基本游戏
- 测试运行 - 面向 .NET 开发者的 Spark 简介
- Xamarin - 使用 Xamarin.Forms 构建跨平台用户体验
- 孜孜不倦的程序员 - 如何成为 MEAN： 快速输入
- Microsoft Azure - Azure、Web API 和 Redis 如何有助于加快数据交付
- 必备 .NET - 设计 C# 7
- 新式应用 - 需要了解的 Windows 10 应用开发概念
- 别让我打开话匣子 - 重构高等教育
- 编者注 - 再见 Kenny