Azure Service Fabric - 微服务方法

引言

在我上一篇关于微服务方法的文章中，我们讨论了这种方法与早期应用程序开发风格——单体应用程序——有何不同。在此基础上，我强调了将应用程序的每个组件分解成更小的独立模块，并将它们视为独立的服務。

现在，我想介绍微软对这种方法的贡献。

Azure Service Fabric

您是否曾经访问过 Microsoft Azure 门户？在那里，我们有各种资源和管理服务，如 Azure API Management。当我还不清楚微服务是什么时，阅读了许多文章后，找到了一句话，一个恰当的句子，为我理清了思路。这句话是：

"将 Azure 门户上的所有服务视为独立模块。"

猜猜怎么着，这在很大程度上是正确的。Microsoft Azure 门户建立在 Service Fabric 平台之上。在 2016 年 3 月，他们向所有人开放了这个平台。目前，这个 Service Fabric 仍处于预览状态。

如果按照微软的方法来说，它表示：

"Service Fabric 使您能够构建和管理可扩展、可靠的微服务应用程序，这些应用程序可以非常高密度地运行在共享的机器池上，即集群。它提供了一个复杂的运行时来构建分布式、可扩展、无状态和有状态的微服务。它还提供了全面的应用程序管理功能，用于预配、部署、监控、升级/修补和删除已部署的应用程序。"

在以下网址：https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-overview

什么是 Service Fabric？

Azure Service Fabric 是一个分布式系统平台，可以轻松地打包、部署和管理可扩展、可靠的微服务。Service Fabric 还解决了开发和管理云应用程序中的重大挑战。开发人员和管理员可以避免复杂的底层设施问题，专注于实现可扩展、可靠且可管理的任务关键型、要求苛刻的工作负载。Service Fabric 代表了下一代中间件平台，用于构建和管理这些企业级、一级、云规模的应用程序。

Service Fabric 的一些核心关键词

集群 (Cluster)：一组通过网络连接的虚拟机或物理机，您的微服务将被部署和管理到其中。集群可以扩展到数千台机器。

您可以创建一个本地集群，然后将其部署到 Azure。

以上是不同的节点，默认情况下，任何集群都有 5 个节点，我们可以随时扩展。

节点 (Node)：集群的一部分机器或虚拟机称为节点。每个节点都被分配一个节点名称（一个字符串）。节点具有放置属性等特征。每台机器或虚拟机都有一个自动启动的 Windows 服务，名为 FabricHost.exe，该服务在启动时运行，然后启动两个可执行文件：Fabric.exe 和 FabricGateway.exe。这两个可执行文件构成了节点。对于测试场景，您可以通过运行多个 Fabric.exe 和 FabricGateway.exe 实例来在单台机器或虚拟机上托管多个节点。

应用程序类型 (Application Type)：分配给一组服务类型的名称/版本。在 ApplicationManifest.xml 文件中定义，嵌入在应用程序包目录中，然后该文件被复制到 Service Fabric 集群的映像存储中。然后，您可以从集群中的此应用程序类型创建命名应用程序。

应用程序包 (Application Package)：一个磁盘目录，包含应用程序类型的 ApplicationManifest.xml 文件。它引用构成应用程序类型的每个服务包的服务包。应用程序包目录中的文件将被复制到 Service Fabric 集群的映像存储中。例如，电子邮件应用程序类型的应用程序包可以包含对队列服务包、前端服务包和数据库服务包的引用。

命名应用程序 (Named Application)：在将应用程序包复制到映像存储后，您通过指定应用程序包的应用程序类型（使用其名称/版本）在集群中创建该应用程序的一个实例。每个应用程序类型实例都会被分配一个 URI 名称，格式如下：“fabric:/MyNamedApp”。在集群中，您可以从单个应用程序类型创建多个命名应用程序。您也可以从不同的应用程序类型创建命名应用程序。每个命名应用程序都独立管理和版本控制。

服务类型 (Service Type)：分配给服务的代码包、数据包和配置包的名称/版本。在 ServiceManifest.xml 文件中定义，嵌入在服务包目录中，然后该服务包目录被应用程序包的 ApplicationManifest.xml 文件引用。在集群中，创建命名应用程序后，您可以从该应用程序类型的某个服务类型创建命名服务。服务类型的 ServiceManifest.xml 文件描述了该服务。

服务包 (Service Package)：一个磁盘目录，包含服务类型的 ServiceManifest.xml 文件。该文件引用了服务类型的代码、静态数据和配置包。服务包目录中的文件被应用程序类型的 ApplicationManifest.xml 文件引用。例如，一个服务包可以引用构成数据库服务的代码、静态数据和配置包。

命名服务 (Named Service)：在创建命名应用程序后，您可以指定服务类型（使用其名称/版本）来创建其服务类型在集群中的一个实例。每个服务类型实例都会被分配一个命名 URI，该 URI 作用域在其命名应用程序的 URI 之下。例如，如果您在“MyNamedApp”命名应用程序中创建了一个“MyDatabase”命名服务，其 URI 看起来像：“fabric:/MyNamedApp/MyDatabase”。在一个命名应用程序中，您可以创建多个命名服务。每个命名服务都可以拥有自己的分区方案和实例/副本计数。

代码包 (Code Package)：一个磁盘目录，包含服务类型的可执行文件（通常是 EXE/DLL 文件）。代码包目录中的文件被服务类型的 ServiceManifest.xml 文件引用。当创建命名服务时，代码包会被复制到将运行命名服务的一个或多个节点上。然后代码开始运行。代码包可执行文件有两种类型：

• 访客可执行文件 (Guest executables)：作为原始文件在宿主操作系统（Windows 或 Linux）上运行的可执行文件。也就是说，这些可执行文件不链接或引用任何 Service Fabric 运行时文件，因此不使用任何 Service Fabric 编程模型。这些可执行文件无法使用某些 Service Fabric 功能，例如用于终结点发现的命名服务。访客可执行文件无法报告特定于每个服务实例的负载指标。
• 服务宿主可执行文件 (Service Host Executables)：通过链接到 Service Fabric 运行时文件来使用 Service Fabric 编程模型的可执行文件，从而启用 Service Fabric 功能。例如，命名服务实例可以将终结点注册到 Service Fabric 的命名服务，还可以报告负载指标。

数据包 (Data Package)：一个磁盘目录，包含服务类型的静态、只读数据文件（通常是照片、声音和视频文件）。数据包目录中的文件被服务类型的 ServiceManifest.xml 文件引用。当创建命名服务时，数据包会被复制到将运行命名服务的一个或多个节点上。代码开始运行，现在可以访问数据文件。

配置文件包 (Configuration Package)：一个磁盘目录，包含服务类型的静态、只读配置文件（通常是文本文件）。配置文件包目录中的文件被服务类型的 ServiceManifest.xml 文件引用。当创建命名服务时，配置文件包会被复制到将运行命名服务的一个或多个节点上。然后代码开始运行，现在可以访问配置文件。

容器 (Containers)：默认情况下，Service Fabric 将服务部署和激活为进程。Service Fabric 也可以在容器映像中部署服务。容器是一种虚拟化技术，可以从应用程序中虚拟化底层操作系统。应用程序及其运行时、依赖项和系统库在一个容器中运行，并对容器自己的操作系统构造的隔离视图具有完全的私有访问权限。Service Fabric 支持 Linux 上的 Docker 容器和 Windows Server 容器。有关更多信息，请阅读Service Fabric 和容器。

分区方案 (Partition Scheme)：在创建命名服务时，您需要指定一个分区方案。拥有大量状态的服务会将数据分散到各个分区，从而分散到集群的节点上。这使得您的命名服务状态可以扩展。在一个分区内，无状态命名服务有实例，而有状态命名服务有副本。通常，无状态命名服务只有一个分区，因为它们没有内部状态。分区实例提供了可用性；如果一个实例失败，其他实例将继续正常运行，然后 Service Fabric 将创建一个新实例。有状态命名服务在其副本内维护其状态，每个分区都有自己的副本集，所有状态都保持同步。如果副本失败，Service Fabric 将从现有副本构建一个新的副本。

 

关注点

如果您根据上图来看，它描绘了一个正常的待解决问题，即我们需要高效地处理多个请求。简单的解决方案是在两者之间应用一个或多个负载均衡器。

但有了 Service Fabric，这项工作就简单多了，集群中有多个节点，每个节点有多个分区，我们可以将任何（需求量大的）应用程序扩展到节点上，如果这还不够，我们可以在另一个节点上运行该应用程序的同一实例，它将处理请求。

总之，如果一个节点正忙于处理请求，那么另一个节点会很乐意提供帮助。

Service Fabric 用于微服务

Azure Service Fabric 源于微软从交付典型的单体式盒装产品转向交付服务的转变。构建和运营大型服务（如 Azure SQL Database 和 Azure Cosmos DB）的经验塑造了 Service Fabric。随着越来越多的服务采用它，该平台也随之发展。重要的是，Service Fabric 不仅要在 Azure 中运行，还要在独立的 Windows Server 部署中运行。

Service Fabric 的目标是解决构建和运行服务的难题，并高效利用基础设施资源，以便团队能够使用微服务方法来解决业务问题。

Service Fabric 提供了两个主要方面来帮助您构建使用微服务方法的应用程序：

• 一个平台，提供系统服务来部署、升级、检测和重新启动失败的服务、发现服务位置、管理状态和监控运行状况。这些系统服务实际上实现了之前描述的许多微服务的特性。
• 编程 API 或框架，帮助您构建微服务应用程序：可靠的 Actor 和可靠的服务。当然，您可以选择任何代码来构建您的微服务。但这些 API 使这项工作更加直接，并且它们与平台进行了更深层次的集成。这样，例如，您可以获得运行状况和诊断信息，或者您可以利用内置的高可用性。

Service Fabric 对您如何构建服务是无关紧要的，您可以使用任何技术。然而，它提供了内置的编程 API，使构建微服务更加容易。

 

趣味事实：如果您听说过游戏 Age of Ascent，它建立在 Service Fabric 平台之上，充分利用了微服务的概念，有趣的是，它在 1 秒内处理数百万条消息交换，一天处理数万亿条消息。

赞美 Service Fabric！！

以下是微软关于 Service Fabric 和微服务的网址：

https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-overview-microservices

历史

基础版本 - 2017 年 5 月 19 日