备注：本分享将介绍ServiceFabric这一由微软出品的微服务框架的基本特性、开发模型、部署模式和运维相关知识。以期让大家对ServiceFabric有个粗浅了解，即使不一定会在项目中采用，也可以给自己正在搭建的微服务平台提供一些灵感和参考。由于我最近的关注点在数据分析领域，所以对于ServiceFabric也没有在项目中实际运用，所以只能分享ServiceFabric的简单介绍，无法涉及具体的运用经验，就当作是官方文档的一个简化版本。同时本人水平有限难免有错漏，还请大家谅解。

备注：有关部署和运维的详细简介由于时间关系，以后有机会再进行分享

备注：包括AzureSQL数据库、AzureDocumentDB、Cortana、MicrosoftPowerBI、MicrosoftIntune、Azure事件中心、AzureIoT中心、SkypeforBusiness和许多核心Azure服务都构建在ServiceFabric上。支持.NET和Java的编程模型；支持任意语言的可执行应用；支持Azure部署、其他云平台部署、本地数据中心部署；SDK和本地模拟器支持Windows和Linux上的.NET和Java，MacOS可以使用Linux虚机实现开发。

备注：在分布式系统中，在群集中的节点之间进行安全通信的能力至关重要。整个分层底部是传输子系统，它在节点之间提供安全的通信。传输子系统之上即是集群管理子系统，它将不同节点聚集为一个单一实体（名为群集）以便ServiceFabric可以检测失败、执行群首选举并提供一致性路由。集群管理系统之上是可靠性子系统，它通过诸如复制、资源管理和故障转移等机制负责ServiceFabric服务的可靠性。集群管理子系统之上还有宿主和激活子系统，它管理单个节点上的应用程序的生命周期。管理子系统管理应用程序和服务的生命周期。可测试性子系统可帮助应用程序开发人员在将应用程序和服务部署到生产环境之前和之后通过模拟失败测试其服务。ServiceFabric能够通过其通信子系统来解析服务位置。向开发人员公开的应用程序编程模型则位于这些子系统以及用于启用工具的应用程序模型之上。

备注：ReliableServices是一个用于编写与ServiceFabric平台集成的服务的轻型框架，并且受益于完整的平台功能集。ReliableServices提供最小API集合，该集合允许ServiceFabric运行时管理服务的生命周期，以及允许服务与运行时进行交互。ReliableServices可以是无状态的，类似于大多数服务平台，例如Web服务器或Azure云服务中的辅助角色，这些角色中创建的每个服务实例都是平等的，并且状态保存在外部解决方案中，例如AzureDB或Azure表存储。ReliableServices也可以是有状态的，专门用于ServiceFabric，其状态使用ReliableCollections直接保存在服务中。通过复制使状态具有高可用性，以及通过分区来分布状态，所有状态由ServiceFabric自动管理。ReliableActor框架在ReliableServices的基础上构建，是根据执行组件设计模式实现虚拟执行组件模式的应用程序框架。ReliableActor框架使用称为执行组件的单线程执行的独立的计算单元和状态。ReliableActor为执行组件提供内置通信，以及提供预设的状态暂留和扩展配置。ServiceFabric可处理可执行文件的业务流程和简单的执行管理，确保其始终按照服务说明启动并运行。但是，因为来宾可执行文件不直接与ServiceFabricAPI集成，所以它们不会从平台所提供的完整功能集中获益，例如自定义健康和负载报告、服务终结点注册和有状态计算。

备注：应用程序是由执行一个或多个特定功能的成分服务组成的集合。服务执行完整且独立的功能（它们可以独立于其他服务启动和运行），并由代码、配置和数据组成。对于每个服务，代码由可执行二进制文件组成，配置由可在运行时加载的服务设置组成，数据则由可供该服务使用的任意静态数据组成。可对此层次应用程序模型中的每个组件进行独立的版本控制和升级。

备注：群集中可以有一个或多个服务类型实例处于活动状态。例如，有状态服务实例或副本通过复制位于群集中不同节点上的副本之间的状态实现高可靠性。这种复制本质上是提供冗余，使服务即使在群集中的一个节点失败时也可用。分区服务进一步跨群集中的节点划分其状态（和该状态的访问模式）。

备注：服务可以使用所需的任何协议或通信堆栈为传入请求设置终结点ServiceFabric提供一种服务发现和解析服务，称为“命名服务”。命名服务维护一个表，它将命名服务实例映射到它们所侦听的终结点地址。ServiceFabric中的所有命名服务实例都具有表示为URI的唯一名称，例如"fabric:/MyApplication/MyService"。服务的名称在服务的生存期内不会更改，只有终结点地址才能在服务移动时发生更改。这与URL保持不变但IP地址可能会更改的网站类似。

备注：有状态服务是指必须存在状态的某部分并且使该部分保持一致才能正常运行的服务。在ServiceFabric中，有状态服务无需将其状态存储在外部；ServiceFabric会为服务代码和服务状态处理这些需求（可靠性、可用性、可伸缩性和一致性）。无状态服务是指在服务内实际未维护任何状态，或者其中的状态完全可释放，无需同步、复制、保留或高可用性。不过大多数服务并不是真正的无状态。它们是将状态外部化到其他某个存储。（例如，任何依赖在备份存储或缓存中保留会话状态的Web应用程序便不是完全无状态。）ServiceFabric中常见的无状态服务使用示例是作为前端，它公开Web应用程序的面向公众的API。然后，该前端服务指示有状态服务完成用户的请求。在这种情况下，来自客户端的调用将定向到无状态服务正在侦听的某个已知端口（如80）。此无状态服务将接收调用，并判断调用是否来自可信方以及其目标服务是哪一个。然后，此无状态服务将调用转发到有状态服务的正确分区并等待响应。无状态服务收到响应后，将回复原始客户端。

备注：服务实现有状态可靠服务可以从StatefulService或StatefulServiceBase类派生。这两个基类都由ServiceFabric提供。它们可为有状态服务提供各种支持和抽象层级，以便与ServiceFabric进行交互，并作为服务加入ServiceFabric群集。这两个基类可管理服务实现的生存期和角色。如果服务实现需要在服务实现生命周期中的那些阶段执行操作或者想要创建通信侦听器对象，服务实现可能会重写任一基类的虚拟方法。有状态可靠服务使用可靠状态管理器来利用可靠集合。可靠集合是对服务高度可用的本地数据结构，即，无论是否进行服务故障转移，一律可以使用。每种类型的ReliableCollection都由可靠状态提供程序实现。可靠状态管理器可靠状态管理器是用于管理可靠状态提供程序的对象。它具有创建、删除、枚举和确保可靠状态提供程序持续保存且高度可用的功能。可靠状态提供程序实例代表持续保存且高度可用的数据结构的实例，比如字典或队列。可靠状态管理器具有一个名为IReliableStateManager的接口，该接口允许从有状态服务访问。面向可靠状态提供程序的接口通过IReliableStateManager返回。可靠状态管理器使用插件体系结构，因此可以动态地插入新的可靠集合类型。可靠状态提供程序每个可靠状态提供程序公开一个接口，由有状态服务用于与可靠状态提供程序交互。例如，IReliableDictionary用来与可靠字典交互，IReliableQueue用来与可靠队列交互。所有可靠状态提供程序均实现IReliableState接口。事务复制器事务复制器组件负责确保服务的状态（即可靠状态管理器和可靠集合内的状态）跨运行服务的所有副本保持一致。它还确保该状态持久保存在日志中。可靠状态管理器通过私有机制与事务复制器交互。日志日志组件提供一个高性能的持久性存储，该存储可针对旋转磁盘或固态磁盘的写入进行优化。日志的设计方式是使持久性存储（例如硬盘）位于运行有状态服务的节点本地。与不是位于节点本地的远程持久性存储相比，这可以降低延迟并提高吞吐量。

备注：服务实现无状态服务实现派生自StatelessService或StatelessServiceBase类。

备注：完整备份是包含重新创建副本状态所需的所有数据的备份：检查点和所有日志记录。增量备份只在自上次备份以来更改（不包括检查点），因此它们往往更快，但无法自行还原。若要还原增量备份，需要整个备份链。备份链是从完整备份开始，随后是一些连续增量备份的链。

备注：在ServiceFabric中，执行组件在ReliableActors框架（在ServiceFabricReliableServices的基础上构建而成的基于执行组件模式的应用程序框架）中实现。你编写的每个ReliableActor服务实际上都是一个已分区、有状态的ReliableService。

备注：生存期管理ServiceFabric执行组件是虚拟的，这表示其生存期不依赖于其内存中表示形式。因此，它们不需要显式创建或销毁。ReliableActors运行时会在它第一次接收到执行组件ID的请求时自动激活此执行组件。如果一段时间未使用某个执行组件，则ReliableActors运行时将回收此内存对象。它还将掌握此执行组件的存在信息，以便将来重新激活。分布和故障转移若要提供可伸缩性和可靠性，ServiceFabric在整个群集中分布执行组件，并根据需要自动将其从故障节点迁移到正常节点中。执行组件在执行组件服务的各个分区中分布，而这些分区在一个ServiceFabric群集的各个节点中分布。每个服务分区包含一组执行组件。通讯机制执行组件交互在接口中定义，该接口由实现接口的执行组件和通过相同接口获取执行组件代理的客户端共享。因为该接口用于异步调用执行组件方法，所以接口的每个方法都必须是返回任务的方法。由于方法的调用及其响应最终导致跨群集的网络请求，因此必须通过平台对这些请求的参数以及所返回的任务的结果类型进行序列化。并发处理ReliableActors运行时提供简单的基于轮次的访问模型用于访问执行组件方法。这意味着任何时候执行组件对象的代码内仅有一个活动线程。基于轮次的访问极大简化了并发系统，因为无需使用数据访问的同步机制。它还意味着系统的设计必须特别考虑每个执行组件实例的单线程访问性质。执行组件可通过注册计时器或提醒来计划自身的定期工作。执行组件事件提供了一种尽最大努力将通知从执行组件发送到客户端的方法。执行组件事件设计用于从执行组件到客户端的通信，而不应用于从执行组件到执行组件的通信。

备注：ServiceFabric默认使用进程的方式运行微服务，隔离度最低。Docker提供了高级API在Linux内核容器上创建和管理容器。WindowsServer2016提供两种不同类型的容器，它们的隔离程度有所不同。WindowsServer容器与Docker容器相似，因为它们都能提供命名空间和文件系统隔离，但与它们运行所在的主机共享内核。WindowsHyper-V容器提供更多隔离性和安全性，因为每个容器不与其他容器或主机共享操作系统内核。由于具有这么高的安全隔离性，Hyper-V容器特别适合用于对付恶意的多租户方案。

备注：默认情况下，ServiceFabric以进程形式部署和激活这些服务。进程能够以最快的速度激活、以最高的密度使用群集中的资源。ServiceFabric还可以部署容器映像中的服务。重要的是，你可以在同一应用程序中混合进程中的服务和容器中的服务。你可以根据具体的方案充分利用这些优势。IIS提升与移动：如果你有想继续使用的现有ASP.NETMVC应用，将它们放在容器中而不是迁移到ASP.NET核心。这些ASP.NETMVC应用程序都依赖Internet信息服务(IIS)。可以从预先创建的IIS映像将这些应用打包成容器映像，然后使用ServiceFabric将其部署。将容器和ServiceFabric微服务混合：可将现有容器映像用作应用程序的一部分。例如，对于应用程序的Web前端，可以使用NGINX容器；对于更密集的后端计算，可以使用在ReliableServices中构建的有状态服务。此方案的示例包括游戏应用程序。降低“干扰性邻居”服务的影响：你可以使用容器的资源调控能力来限制服务在主机上使用的资源。如果某些服务可能会消耗大量资源，因而影响其他服务的性能（例如，类似于查询的长时间运行的操作），请考虑将这些服务放入具有资源监管功能的容器中。来宾容器：与来宾可执行文件方案相同，可在容器中部署现有的应用程序。示例包括Node.js、JavaScript或任意代码（可执行文件）。容器中的无状态服务：这是一些使用ReliableServices和ReliableActors编程模型的无状态服务。目前只有Linux支持此方案。将来的版本会添加对Windows容器中无状态服务的支持。容器中的有状态服务：这是Linux上的一些使用ReliableActors编程模型的有状态服务。Linux目前不支持ReliableServices。将来的版本会添加对Windows容器中有状态服务的支持。