目录
概述
Azure Service Fabric是一款分布式系统平台，可方便用户轻松打包、部署和管理可缩放的微服务和容器。 Service Fabric还解决了开发和管理云原生应用程序面临的重大难题。 开发人员和管理人员不需解决复杂的基础结构问题，只需专注于实现苛刻的任务关键型工作负荷，即那些可缩放、可靠且易于管理的工作负荷。 Service Fabric 代表了下一代平台，用于生成和管理在容器中运行的企业级单层云规模应用程序。
Service Fabric 可以在所有环境中运行。 可以在许多环境中（例如在Azure或本地、Windows Server 或 Linux 中）创建 Service Fabric 群集；甚至可以在其他公有云上创建群集。 此外，SDK 中的开发环境与生产环境完全相同 ，都不涉及模拟器， 也就是说，在本地开发群集上运行的内容可以部署到其他环境中的群集。
通过使用Service Fabric，可以实现：
- 部署到Azure或部署到运行Windows或Linux的本地数据中心，而无需改变任何代码。 只需编写一次，即可部署到Service Fabric群集的任意位置。
- 使用Service Fabric编程模型、容器或任意代码，开发由微服务组成的可缩放应用程序。
- 开发高度可靠的无状态和有状态微服务。使用有状态微服务，简化应用程序设计。
- 使用新Reliable Actors编程模型，创建具有独立式代码和状态的云对象。
- 部署和编排容器，包括Windows容器和Linux容器。 Service Fabric是可感知数据的有状态容器Orchestrator。
- 几秒内就可以高密度部署应用程序，即每台计算机部署成百上千个应用程序或容器。
- 同时部署同一个应用程序的不同版本，且可以单独升级每个应用程序。
- 无需停机，即可管理应用程序生命周期，包括重大升级和非重大升级。
- 横向扩展或横向缩减群集中的节点数。缩放节点数的同时，应用程序也会随之自动缩放。
- 监视并诊断应用程序的运行状况，并设置策略以执行自动修复。
- 观察资源均衡器如何跨群集编排重新分发应用程序。Service Fabric可从故障中恢复，并可基于可用资源优化负载分布。
功能特性
Azure Service Fabric是一款分布式系统平台，可方便用户轻松打包、部署和管理可缩放的微服务和容器。 下面侧重介绍其微服务、群集、编程模型、应用程序生命周期、测试、监视诊断、核心概念。
使用Service Fabric，可以生成包含微服务或容器的应用程序。 无状态微服务（例如网关、Web 代理）不维护除请求及其来自服务的响应之外任何可变状态。 Azure云服务辅助角色是无状态服务的一个示例。 有状态微服务（例如，用户帐户、数据库、设备、购物车、队列）维护除请求及其响应之外的可变、授权状态。
Service Fabric群集是一组通过网络连接在一起的虚拟机或物理计算机，微服务会在其中部署和管理。 群集可以扩展到成千上万台计算机。 群集中的计算机或VM称为群集节点。 需为每个节点分配节点名称（字符串）。 节点具有各种特征，如放置属性等。 每个计算机或VM都有一个自动启动服务FabricHost.exe，此服务在引导时开始运行，并启动两个可执行文件：Fabric.exe和FabricGateway.exe， 这两个可执行文件构成了节点。 在测试方案中，可以通过运行Fabric.exe和FabricGateway.exe的多个实例，在单台计算机或VM上托管多个节点。可在运行Windows Server或Linux的虚拟机或物理计算机上创建Service Fabric群集。 可在包含一组互连Windows Server或Linux计算机（本地计算机、Microsoft Azure计算机或任何云提供商的计算机）的任何环境中部署和运行Service Fabric应用程序。
Service Fabric提供了多种方法来编写和管理服务。 服务可以使用Service Fabric API来充分利用平台的功能和应用程序框架。 服务还可以是采用任何语言编写的任意编译可执行程序，并在Service Fabric群集上托管。包含：容器、Reliable Service、Reliable Actors、ASP.NET Core等。
与其他平台一样，Service Fabric上的应用程序通常将经历以下几个阶段：设计、开发、测试、部署、升级、维护和删除。Service Fabric为云应用程序的整个应用程序生命周期提供一流的支持：从开发到部署、到日常管理和维护，再到最终解除授权。 服务模型使多个不同角色可以独立参与到应用程序生命周期中。可以使用PowerShell cmdlet、CLI 命令、C# API、Java API和REST API管理整个应用生命周期。 还可以使用Azure Pipelines或Jenkins等工具来设置持续集成/持续部署管道。
若要创建真正的大规模服务，请务必确保应用程序和服务能够经受住现实环境发生的故障。 故障分析服务是在Service Fabric基础上专为测试服务构建的。 借助故障分析服务，可以引入有意义的故障，并对应用程序运行提供完整的测试方案。 这些故障和方案将执行并验证服务在整个生命周期内要经历的大量状态和转换，所有一切都以受控、安全且一致的方式进行。
监视和诊断对任何环境中的开发、测试和部署应用程序和服务都至关重要。 监视和诊断有助于确保应用程序和服务在本地开发环境或生产环境中按预期运行，计划和实现监视和诊断时，Service Fabric解决方案效果最佳。监视和诊断的整体工作流程分为以下三个步骤：
- 事件生成：这包括基础结构（群集）级、平台级、应用程序/服务级事件（日志、跟踪、自定义事件）
- 事件聚合：需要先收集和聚合生成的事件才能显示这些事件
- 分析：需直观显示事件并能够以某种格式访问事件，以便按需进行分析和显示
设计时：服务类型、服务包、应用程序类型、应用程序包和清单
服务类型是分配给服务的代码包、数据包、配置包的名称/版本。 这是在Servicemanifest.xml文件中定义的。 服务类型由在运行时加载的可执行代码和服务配置设置以及服务使用的静态数据组成。
服务包是一个磁盘目录，其中包含服务类型的ServiceManifest.xml文件，该文件引用服务类型的代码、静态数据和配置包。
应用程序类型是分配给服务类型集合的名称/版本。 这是在Applicationmanifest.xml文件中定义的。
应用程序包是一个磁盘目录，其中包含应用程序类型的Applicationmanifest.xml文件，该文件引用构成应用程序类型的每种服务类型的服务包。 例如，电子邮件应用程序类型的应用程序包可能包含对队列服务包、前端服务包和数据库服务包的引用。
应用程序包目录中的文件将复制到Service Fabric群集的映像存储上， 然后可基于此应用程序类型，创建在群集内运行的命名应用程序。 创建命名应用程序后，可以从应用程序类型的服务类型之一创建命名服务。
运行时：群集和节点、命名的应用程序、命名的服务、分区和副本
Service Fabric群集是一组通过网络连接在一起的虚拟机或物理计算机，微服务会在其中部署和管理。 群集可以扩展到成千上万台计算机。
属于群集一部分的计算机或VM称为节点。 需为每个节点分配节点名称（字符串）。 节点具有各种特征，如放置属性等。 每个计算机或VM都有一个自动启动的Windows服务FabricHost.exe，此服务在引导时开始运行，并启动两个可执行文件：Fabric.exe和FabricGateway.exe， 这两个可执行文件构成了节点。 在开发或测试方案中，可以通过运行 Fabric.exe 和 FabricGateway.exe 的多个实例，在单台计算机或 VM 上托管多个节点。
命名应用程序是执行一个或多个特定功能的命名服务的集合。 服务执行完整且独立的功能（它们可以独立于其他服务启动和运行），并由代码、配置和数据组成。 将应用程序包复制到映像存储后，可以通过指定应用程序包的应用程序类型（使用其名称/版本）在群集内创建应用程序的实例。 将为每个应用程序类型实例分配一个如下所示的 URI 名称：fabric:/MyNamedApp。 在群集中，可以从单个应用程序类型创建多个命名应用程序。 还可以从不同的应用程序类型创建命名应用程序。 可单独管理每个命名应用程序并设置其版本。
创建命名应用程序后，可以通过指定服务类型（使用其名称/版本），在群集中创建应用程序服务类型（命名服务）之一的实例。 需为每个服务类型实例分配一个 URI 名称，该名称归并到实例的命名应用程序的 URI 之下。 例如，如果在命名应用程序“MyNamedApp”中创建命名服务“MyDatabase”，则 URI 将类似于：fabric:/MyNamedApp/MyDatabase。 在一个命名应用程序中可以创建一个或多个命名服务。 每个命名服务可以有自身的分区方案和实例/副本计数。
有两种服务类型：无状态服务和有状态服务。 无状态服务不在服务中存储状态。 无状态服务根本没有持久性存储，或者将持久性状态存储在外部存储服务中，例如，存储在 Azure 存储、Azure SQL 数据库或 Azure Cosmos DB 中。 有状态服务将状态存储在服务内，并使用 Reliable Collections 或 Reliable Actors 编程模型来管理状态。
创建命名服务时，需要指定一个分区方案。 包含大量状态的服务将跨分区拆分数据。 每个分区负责服务完整状态的一部分（分布在群集的节点上）。
下图显示应用程序和服务实例、分区与副本之间的关系。
分区、缩放和可用性：
分区并不是 Service Fabric 所独有的。 一种众所周知的分区形式是数据分区，也称为分片。 包含大量状态的有状态服务将跨分区拆分数据。 每个分区负责服务完整状态的一部分。
每个分区的副本分布在群集的节点上，以便命名服务状态进行缩放。 随着数据需求的增长，分区也会增长，Service Fabric 会在节点间重新平衡分区，以高效利用硬件资源。 如果向群集添加新节点，Service Fabric 会在新增加的节点间重新平衡分区副本。 应用程序总体性能提高，访问内存的争用减少。 如果没有高效使用群集中的节点，可以减少群集中节点的数量。 Service Fabric 会再次在减少的节点间重新平衡分区副本以更加充分使用每个节点上的硬件。
在分区中，无状态命名服务具有实例，而有状态命名服务具有副本。 通常，无状态命名服务只有一个分区，因为它们没有内部状态。 分区实例提供可用性。 如果一个实例失败，其他实例可继续正常运行，然后 Service Fabric 将创建新的实例。 有状态命名服务在副本中保持其状态，每个分区都有自己的副本集。 在一个副本上执行读取和写入操作。 因写入操作发生的状态更改将复制到其他多个副本。 如果某个副本失败，Service Fabric 将从现有副本创建新副本。
体系架构
Service Fabric是利用分层子系统而生成的。下图为Service Fabric的主要子系统架构。
在分布式系统中，群集中的节点之间进行安全通信的能力至关重要。 堆栈底部是传输子系统，它在节点之间提供安全的通信。 传输子系统之上即是联合子系统，它将不同节点聚集为一个单一实体（名为群集）以便Service Fabric可以检测失败、执行群首选举并提供一致性路由。 联合子系统之上是可靠性子系统，它通过诸如复制、资源管理和故障转移等机制负责Service Fabric服务的可靠性。 联合子系统之上还有宿主和激活子系统，它管理单个节点上的应用程序的生命周期。 管理子系统管理应用程序和服务的生命周期。 可测试性子系统可帮助应用程序开发人员在将应用程序和服务部署到生产环境之前和之后通过模拟失败测试其服务。 Service Fabric能够通过其通信子系统来解析服务位置。 向开发人员公开的应用程序编程模型则位于这些子系统以及用于启用工具的应用程序模型之上。
应用场景
Azure Service Fabric提供了一个可靠而灵活的平台，可在其中编写和运行多种类型的业务应用程序和服务。 这些应用程序和微服务可以是无状态或有状态，并且它们在虚拟机之间进行了资源平衡，以最大程度地提高效率。
Service Fabric的独特体系结构使你可以在应用程序中执行近实时数据分析、内存中计算、并行事务和事件处理。 你可以根据不断变化的资源要求轻松地放大或缩小应用程序。
Service Fabric常应用于以下场景：
- 数据收集、处理和IoT：Service Fabric处理大规模，并通过其有状态服务实现低延迟。 它可以帮助处理数百万台设备上的数据，以及设备的数据和计算的位置。
- 游戏和基于会话的交互式应用程序：如果你的应用程序需要低延迟读取和写入（例如在线游戏或即时消息），则Service Fabric很有用。Service Fabric使你能够生成这些交互式的有状态应用程序，而无需创建单独的存储或缓存。
- 数据分析和工作流处理：必须可靠地处理事件或数据流的应用程序，这些应用程序在Service Fabric中经过优化的读取和写入。Service Fabric还支持应用程序处理管道，其中的结果必须可靠，并将其传递到下一个处理阶段而不会丢失任何损失。 这些管道包括事务性和财务系统，其中的数据一致性和计算保证至关重要。
- 数据的计算：Service Fabric使你能够生成具有大量数据计算功能的有状态应用程序。Service Fabric允许在应用程序中进行归置处理（计算）和数据。
通常情况下，当应用程序需要访问数据时，与外部数据缓存或存储层关联的网络延迟会限制计算时间。 有状态Service Fabric服务可消除这种延迟，从而实现更优化的读取和写入。
- 高度可用的服务：Service Fabric通过创建多个辅助服务副本提供快速的故障转移。 节点、进程或单独的服务因硬件或其他故障而不可用时，其中一个辅助副本会提升为主副本，将对服务的损失降到最低。
- 可缩放的服务：可对单独的服务进行分区，以允许在群集范围内扩大状态。还可以动态创建和删除单个服务。 你可以从几个节点上的几个实例向外扩展到多个节点上的数千个实例，然后根据需要重新进行扩展。 您可以使用Service Fabric来生成这些服务并管理其整个生命周期。
解决方案
设计由无状态和有状态微服务组成的应用程序：
构建由微服务组成的应用程序时，通常会将无状态web应用（例如ASP.NET和node.js）组合到无状态和有状态业务中间层服务。 通过Service Fabric部署命令，所有应用和服务都部署在同一Service Fabric群集中。其中每个服务都独立于规模、可靠性和资源使用情况。 此独立性提高了开发和生命周期管理的灵活性。
以下关系图说明了设计无状态应用程序与有状态的应用程序之间的差异。
有状态微服务将简化应用程序设计，因为它们不再需要传统上用来处理纯无状态应用程序的可用性和延迟需求的附加队列和缓存。 由于有状态服务具有高可用性和低延迟性，因此在应用程序中管理的详细信息更少。
将现有应用程序迁移到Service Fabric：
Service Fabric允许你重复使用现有代码，并使用新的微服务实现现代化。 应用程序的现代化分为五个阶段，你可以在任何阶段启动和停止。 阶段为：
- 从传统单一式应用程序入手。
- 使用容器或来宾可执行文件在Service Fabric中托管现有代码。
- 添加新的微服务与现有容器化代码。
- 根据需要将单一应用程序分解成微服务。
- 转换现有的单一应用程序或生成新的领域应用程序。
通过将应用程序迁移到Service Fabric，可以有效降低成本，并实现开发和操作之间的一致性部署协定；同时，基于Service Fabric的微服务方法，可以适应不断变化的业务需求，从而使客户更好的促进业务发展和专注于业务创新。
基于数据收集、数据处理和IOT的方案：
基于Azure服务可以量身定制客户的IOT解决方案。其中Service Fabric 托管微服务应用程序，这些应用程序主要负责后端数据处理，状态管理和规则引擎等。
使用Service Fabric微服务可以使IOT架构系统独立管理每个过程；例如，它们可以独立于通知来扩展有效负载处理；他们可以在不停机的情况下更新过程的任何部分。对于服务密集型应用程序，可以降低实现高可用性所需的总体计算成本。Service Fabric通过其状态服务为应用程序提供类似于RAID功能的功能；应用程序可以非常快速地从故障节点转移到热备用副本；可以在维护期间将一组应用程序从一个节点迁移到另一个节点。
基于游戏的Service Fabric方案：
基于Azure服务可以量身定制客户的游戏解决方案。Azure Service Fabric可靠地处理游戏消息之间的传递。
基于Service Fabric可以快捷的实现游戏程序的开发、部署和上线，更好的实现版本之间的流畅切换，同时能更好的应对客户访问的峰值流量。
