分布式系统平台-Azure Service Fabric

Azure Service Fabric是一个分布式系统平台，可轻松打包、部署和管理可扩展且可靠的微服务。然而，Service Fabric有很大的表面积，有很多东西需要学习。本文简要介绍了Service Fabric，并描述了核心概念、编程模型、应用程序生命周期、测试、集群和运行状况监视。

核心概念

Service Fabric术语、应用程序模型和受支持的编程模型提供了更多的概念和描述，但以下是基础知识。

设计时间：服务类型、服务包和清单、应用程序类型、应用程序包和清单

服务类型是分配给服务的代码包、数据包和配置包的名称/版本。这是在ServiceManifest.xml文件中定义的。服务类型由运行时加载的可执行代码和服务配置设置以及服务使用的静态数据组成。

其中servicesmanifest是包含服务包的静态数据类型，servicesmanifest是包含服务包的静态数据类型。例如，服务包可以引用组成数据库服务的代码、静态数据和配置包。

应用程序类型是分配给服务类型集合的名称/版本。这是在ApplicationManifest.xml文件中定义的。

应用程序包是一个磁盘目录，其中包含应用程序类型的ApplicationManifest.xml文件，该文件引用构成应用程序类型的每个服务类型的服务包。例如，电子邮件应用程序类型的应用程序包可以包含对队列服务包、前端服务包和数据库服务包的引用。

应用程序包目录中的文件将复制到Service Fabric群集的映像存储。然后，您可以从该应用程序类型创建一个命名应用程序，然后在集群中运行。创建命名应用程序后，可以从应用程序类型的服务类型之一创建命名服务。

运行时：群集和节点、命名应用程序、命名服务、分区和副本

Service Fabric群集是一组网络连接的虚拟机或物理机，在其中部署和管理微服务。集群可以扩展到数千台机器。

作为集群一部分的机器或VM称为节点。为每个节点分配一个节点名（字符串）。节点具有放置属性等特征。每台计算机或VM都有一个自动启动Windows服务FabriHost.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）中存储持久性状态。有状态服务在服务中存储状态，并使用可靠的集合或可靠的参与者编程模型来管理状态。

创建命名服务时，指定分区方案。具有大量状态的服务跨分区分割数据。每个分区负责服务的一部分完整状态，该状态分布在集群的节点上。

下图显示了应用程序与服务实例、分区和副本之间的关系。

分区、扩展和可用性

分区不是Service Fabric所独有的。一种众所周知的分区形式是数据分区或分片。具有大量状态的有状态服务跨分区分割数据。每个分区负责服务完整状态的一部分。

每个分区的副本分布在集群的节点上，这允许扩展命名服务的状态。随着数据需求的增长，分区也随之增长，服务结构跨节点重新平衡分区，以有效利用硬件资源。如果向集群中添加新节点，Service Fabric将跨增加的节点数重新平衡分区副本。总体应用程序性能提高，对内存访问的争用减少。如果集群中的节点没有得到有效利用，可以减少集群中的节点数。服务结构再次跨减少的节点数重新平衡分区副本，以更好地利用每个节点上的硬件。

在分区内，无状态命名服务具有实例，而有状态命名服务具有副本。通常，无状态命名服务只有一个分区，因为它们没有内部状态，尽管也有例外。分区实例提供了可用性。如果一个实例失败，其他实例将继续正常运行，然后服务结构将创建一个新实例。有状态命名服务在副本中维护它们的状态，每个分区都有自己的副本集。读写操作在一个副本（称为主副本）上执行。写入操作对状态的更改将复制到多个其他副本（称为活动二级副本）。如果复制副本失败，Service Fabric将从现有复制副本构建新的复制副本。

Service Fabric的无状态和有状态微服务

Service Fabric使您能够构建由微服务或容器组成的应用程序。无状态微服务（如协议网关和web代理）不会在来自服务的请求及其响应之外保持可变状态。Azure云服务工作者角色是无状态服务的一个示例。有状态的微服务（如用户帐户、数据库、设备、购物车和队列）在请求及其响应之外保持一种可变的权威状态。今天的互联网规模的应用程序由无状态和有状态的微服务组合而成。

Service Fabric的一个关键区别在于，它非常注重使用内置编程模型或容器化有状态服务构建有状态服务。应用程序场景描述了使用有状态服务的场景。

为什么有状态微服务和无状态微服务并存？两个主要原因是：

• 通过将代码和数据保持在同一台机器上，您可以构建高吞吐量、低延迟、容错在线事务处理（OLTP）服务。例如交互式店面、搜索、物联网（IoT）系统、交易系统、信用卡处理和欺诈检测系统以及个人记录管理。
• 您可以简化应用程序设计。有状态的微服务消除了对额外队列和缓存的需求，而这些队列和缓存传统上是解决纯无状态应用程序的可用性和延迟需求所必需的。有状态服务自然具有高可用性和低延迟，从而减少了整个应用程序中需要管理的移动部件的数量。

支持的编程模型

Service Fabric提供了多种编写和管理服务的方法。服务可以使用服务结构API充分利用平台的功能和应用程序框架。服务也可以是以任何语言编写并托管在服务结构集群上的任何编译的可执行程序。有关更多信息，请参阅支持的编程模型。

容器

默认情况下，Service Fabric作为流程部署和激活服务。Service Fabric还可以在容器中部署服务。重要的是，您可以在同一应用程序中混合流程中的服务和容器中的服务。Service Fabric支持在Windows Server 2016上部署Linux容器和Windows容器。您可以在容器中部署现有应用程序、无状态服务或有状态服务。

可靠的服务

Reliable Services是一个轻量级框架，用于编写与Service Fabric平台集成并受益于全套平台功能的服务。可靠的服务可以是无状态的（类似于大多数服务平台，如Azure云服务中的web服务器或工作者角色），其中状态在外部解决方案（如Azure DB或Azure表存储）中持久化。可靠的服务也可以是有状态的，其中状态使用可靠的集合直接持久化在服务本身中。状态通过复制变得高度可用，并通过分区进行分发，所有这些都由服务结构自动管理。

可靠的行动者

构建在可靠服务之上的可靠参与者框架是一个应用程序框架，它基于参与者设计模式实现虚拟参与者模式。可靠的Actor框架使用独立的计算单元和状态单元，并使用称为actors的单线程执行。可靠的参与者框架为参与者提供内置通信，并提供预设的状态持久性和扩展配置。

ASP.NET Core

Service Fabric与ASP.NET Core集成，作为构建web和API应用程序的一流编程模型。ASP.NET Core可在Service Fabric中以两种不同的方式使用：

作为来宾可执行文件托管。这主要用于在Service Fabric上运行现有ASP.NET核心应用程序，而无需更改代码。

在可靠的服务中运行。这允许更好地与服务结构运行时集成，并允许有状态的ASP.NET核心服务。

可执行Guest

Guest可执行文件是一个现有的任意可执行文件（以任何语言编写），与其他服务一起托管在服务结构集群上。Guest可执行文件不直接与服务结构API集成。但是，他们仍然受益于该平台提供的功能，例如自定义运行状况和负载报告，以及通过调用REST API实现的服务可发现性。它们还具有完整的应用程序生命周期支持。

应用程序生命周期

与其他平台一样，Service Fabric上的应用程序通常经历以下阶段：设计、开发、测试、部署、升级、维护和删除。ServiceFabric为云应用程序的整个应用程序生命周期提供一流的支持，从开发到部署、日常管理和维护，再到最终退役。服务模型允许多个不同的角色独立参与应用程序生命周期。ServiceFabric应用程序生命周期概述了API以及不同角色在ServiceFabric应用程序生命周期的各个阶段如何使用这些API。

可以使用PowerShell cmdlet、CLI命令、C#API、Java API和REST API管理整个应用程序生命周期。您还可以使用Azure pipelines或Jenkins等工具设置连续集成/连续部署管道。

测试应用程序和服务

要创建真正的云级服务，验证您的应用程序和服务是否能够承受现实世界中的故障至关重要。故障分析服务是为测试构建在Service Fabric上上的服务而设计的。使用故障分析服务，您可以诱发有意义的故障，并对应用程序运行完整的测试场景。这些故障和场景以可控、安全和一致的方式演练和验证服务在其整个生命周期中将经历的众多状态和转换。

操作针对使用单个故障进行测试的服务。服务开发人员可以将其用作编写复杂场景的构建块。模拟故障的示例包括：

• 重新启动节点以模拟机器或VM重新启动的任意数量的情况。
• 移动有状态服务的副本以模拟负载平衡、故障切换或应用程序升级。
• 在有状态服务上调用仲裁丢失，以造成写入操作无法继续的情况，因为没有足够的“备份”或“辅助”副本来接受新数据。
• 调用有状态服务上的数据丢失，以创建内存中的所有状态都被完全清除的情况。

场景是由一个或多个操作组成的复杂操作。故障分析服务提供了两个内置的完整场景：

混沌场景-模拟整个集群在较长时间内连续、交错的故障（正常和不正常）。

故障转移场景—混沌测试场景的一个版本，它针对特定的服务分区，而不影响其他服务。

Service Fabric上群集是一组网络连接的虚拟机或物理机，在其中部署和管理微服务。集群可以扩展到数千台机器。作为集群一部分的机器或VM称为集群节点。为每个节点分配一个节点名（字符串）。节点具有放置属性等特征。每台机器或VM都有一个自动启动服务FabriCost.exe，该服务在引导时开始运行，然后启动两个可执行文件：Fabric.exe和FabricGateway.exe。这两个可执行文件构成了节点。对于测试场景，您可以通过运行Fabric.exe和FabricGateway.exe的多个实例在一台计算机或VM上承载多个节点。

可以在运行Windows Server或Linux的虚拟机或物理机上创建服务结构群集。您可以在具有一组互连的Windows Server或Linux计算机的任何环境中部署和运行Service Fabric应用程序：本地、Microsoft Azure或任何云提供商。

Azure上的群集

在Azure上运行Service Fabric群集提供了与其他Azure功能和服务的集成，这使得群集的操作和管理更容易、更可靠。群集是Azure资源管理器资源，因此您可以像Azure中的任何其他资源一样对群集进行建模。资源管理器还提供了对集群作为单个单元使用的所有资源的简单管理。Azure上的群集与Azure诊断和Azure监视器日志集成。群集节点类型是虚拟机规模集，因此内置了自动缩放功能。

您可以通过Azure门户、模板或Visual Studio在Azure上创建群集。

Linux上的Service Fabric使您能够像在Windows上一样，在Linux上构建、部署和管理高可用性、高可伸缩性的应用程序。除了C#（.NETCore）之外，Linux上的Java还提供了服务结构框架（可靠的服务和可靠的参与者）。您还可以使用任何语言或框架构建来宾可执行服务。还支持编排Docker容器。Docker容器可以运行guest可执行文件或本机服务结构服务，它们使用服务结构框架。

有些功能在Windows上受支持，但在Linux上不受支持。

独立群集

Service Fabric为您提供了一个安装包，用于在本地或任何云提供商上创建独立的Service Fabric群集。独立群集使您可以自由地在任何地方托管群集。如果您的数据受到法规遵从性或管理法规的约束，或者您希望将数据保留在本地，则可以托管您自己的群集和应用程序。Service Fabric应用程序可以在多个托管环境中运行，而无需进行任何更改，因此您对构建应用程序的了解可以从一个托管环境延续到另一个托管环境。

Linux独立群集尚不受支持。

集群安全

必须对群集进行安全保护，以防止未经授权的用户连接到您的群集，尤其是在其上运行生产工作负载时。尽管可以创建不安全的群集，但如果管理端点暴露在公共internet上，这样做允许匿名用户连接到该群集。以后无法在不安全的群集上启用安全性：群集安全性在群集创建时启用。

群集安全场景包括：

• 节点间安全
• 客户端到节点安全
• 基于角色的服务结构访问控制

缩放比例

如果向集群中添加新节点，Service Fabric将跨增加的节点数重新平衡分区副本和实例。总体应用程序性能提高，对内存访问的争用减少。如果集群中的节点没有得到有效利用，可以减少集群中的节点数。Service Fabric再次跨减少的节点数重新平衡分区副本和实例，以更好地利用每个节点上的硬件。您可以手动或编程方式在Azure上扩展群集。可以手动缩放独立群集。

集群升级

定期发布新版本的Service Fabric运行时。在集群上执行运行时或结构升级，以便始终运行受支持的版本。除了结构升级之外，您还可以更新群集配置，如证书或应用程序端口。

Service Fabric群集是您拥有的资源，但部分由Microsoft管理。Microsoft负责修补基础操作系统并在群集上执行结构升级。您可以将群集设置为在Microsoft发布新版本时接收自动结构升级，或者选择所需的受支持结构版本。结构和配置升级可以通过Azure门户或资源管理器进行设置。

独立集群是您完全拥有的资源。您负责修补底层操作系统并启动结构升级。如果您的群集可以连接到https://www.microsoft.com/download，您可以将群集设置为自动下载并配置新的Service Fabric运行时包。然后，您将启动升级。如果您的群集无法访问https://www.microsoft.com/download，您可以从连接internet的计算机手动下载新的运行时包，然后启动升级。

健康监测

Service Fabric引入了一个健康模型，用于标记特定实体（如群集节点和服务副本）上不健康的群集和应用程序条件。健康模型使用健康报告器（系统组件和监视程序）。目标是简单快速地诊断和修复。服务编写者需要预先考虑健康问题以及如何设计健康报告。应报告任何可能影响健康的情况，特别是如果它有助于标记接近根源的问题。一旦服务启动并在生产中大规模运行，运行状况信息可以节省调试和调查的时间和精力。

Service Fabric报告员监控确定的感兴趣的条件。他们根据当地的观点报告这些情况。health store汇总所有报告者发送的健康数据，以确定实体是否处于全球健康状态。该模型旨在丰富、灵活且易于使用。运行状况报告的质量决定了群集运行状况视图的准确性。错误地显示不健康问题的误报可能会对升级或使用健康数据的其他服务产生负面影响。此类服务的示例包括修复服务和警报机制。因此，需要考虑提供报告，以尽可能最好的方式捕获感兴趣的条件。

可以从以下位置进行报告：

• 受监视的Service Fabric服务副本或实例。
• 作为Service Fabric服务部署的内部监视程序（例如，用于监视条件和发布报告的Service Fabric无状态服务）。监视程序可以部署在所有节点上，也可以与受监视的服务密切相关。
• 在Service Fabric节点上运行但未作为Service Fabric服务实现的内部监视程序。
• 从Service Fabric集群外部探测资源的外部监视程序（例如，监视服务，如Gomez）。

现成的Service Fabric组件报告集群中所有实体的运行状况。系统运行状况报告提供对集群和应用程序功能的可见性，并通过运行状况标记问题。对于应用程序和服务，系统运行状况报告将从Service Fabric运行时的角度验证实体是否已实现以及行为是否正确。这些报告不提供服务的业务逻辑的任何运行状况监视，也不检测已停止响应的流程。要添加特定于服务逻辑的运行状况信息，请在服务中实现自定义运行状况报告。

Service Fabric提供多种方式来查看在运行状况存储中聚合的运行状况报告：

• Service Fabric资源管理器或其他可视化工具。
• 运行状况查询（通过PowerShell、CLI、C#FabricClient API和Java FabricClient API或REST API）。
• 返回将运行状况作为属性之一的实体列表的常规查询（通过PowerShell、CLI、API或REST）。

监测和诊断

监控和诊断对于在任何环境中开发、测试和部署应用程序和服务都至关重要。当您计划并实施监控和诊断以帮助确保应用程序和服务在本地开发环境或生产环境中按预期工作时，Service Fabric解决方案最为有效。

监测和诊断的主要目标是：

• 检测和诊断硬件和基础架构问题
• 检测软件和应用程序问题，减少服务停机时间
• 了解资源消耗并帮助推动运营决策
• 优化应用程序、服务和基础架构性能
• 产生业务见解并确定需要改进的领域

监控和诊断的总体工作流程包括三个步骤：

1. 事件生成：这包括基础架构（集群）、平台和应用程序/服务级别的事件（日志、跟踪、自定义事件）

2. 事件聚合：需要收集和聚合生成的事件，然后才能显示它们

3. 分析：事件需要以某种格式可视化和可访问，以便根据需要进行分析和显示

有多种产品涵盖这三个领域，您可以自由选择不同的技术。

原文地址：https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-content-roadmap