Service Fabric - 编程模型与服务

       在之前的例子中演示了来宾可执行文件、服务的编程模型，可以看到在 Service Fabric 编写服务时可以获取到资源、部署信息，以及能够完成健康和监控信息的汇报。除了无状态服务， Service Fabric 还着重介绍了有状态服务，服务部署后我们还可以对服务进行扩缩容以保证服务是处于最优的运行状态。

       Service Fabric 提供了多种方法来编写和管理服务。服务可以选择使用 Service Fabric API 来充分利用平台的功能和应用程序框架。服务还可以是采用任何语言编写的任意已编译可执行程序，也可以是在 Service Fabric 群集上直接托管的容器中运行的代码。之前提到的容器部署，能够支持Docker compose和windows hyper-V，以及ASP.NET core。

       Reliable Services 是一个用于编写与 Service Fabric 平台集成的服务的轻型框架，并且受益于完整的平台功能集。Reliable Services 提供最小 API 集合，该集合允许 Service Fabric 运行时管理服务的生命周期，以及允许服务与运行时进行交互。Reliable Services 可以无状态，类似于大多数服务平台，如 Web 服务器。也就是说，创建的每个服务实例都是平等的，并且状态保存在外部解决方案中，如 Azure DB 或 Azure 表存储。Reliable Services 也可以是有状态的，专门用于 Service Fabric，其状态使用 Reliable Collections 直接保存在服务中。通过复制使状态具有高可用性，以及通过分区来分布状态，所有状态由 Service Fabric 自动管理。

       Reliable Actor 框架在 Reliable Services 的基础上构建，是根据执行组件设计模式实现虚拟执行组件模式的应用程序框架。Reliable Actor 框架使用称为执行组件的单线程执行的独立的计算单元和状态。Reliable Actor 为执行组件提供内置通信，以及提供预设的状态暂留和扩展配置。

服务分区

       有两种服务类型：无状态服务和有状态服务。无状态服务可将持久状态存储在 Azure 存储、Azure SQL 数据库或 Azure Cosmos DB 等外部存储服务中。当服务根本没有永久性存储时，请使用无状态服务。有状态服务使用 Service Fabric 通过其 Reliable Collections 或 Reliable Actors 编程模型管理服务状态。

       这里可以简单的认为有状态服务是需要使用SDK中的Reliable Collections完成工作的，下图展示了服务分区：

       可以看到 Service Fabric 区分有状态和无状态的目的是服务在部署时的分区要求，也就是说将有状态的服务通过主备的方式保证其可用性的同时，提升性能，而将无状态的服务通过多实例部署的方式提升其可用性。

服务伸缩

       分区并不是 Service Fabric 所独有的。一种众所周知的分区形式是数据分区，也称为分片。包含大量状态的有状态服务将跨分区拆分数据。每个分区负责服务完整状态的一部分。每个分区的副本分布在群集的节点上，以便命名服务状态进行缩放。 随着数据需求的增长，分区也会增长，Service Fabric 会在节点间重新平衡分区&#x