Service Fabric 术语概述

Service Fabric 是分布式系统平台,可借助它轻松打包、部署和管理可缩放且可靠的微服务。 本文详细介绍 Service Fabric 所使用的术语,帮助了解文档中使用的术语。

基础结构概念

群集:一组通过网络连接在一起的虚拟机或物理计算机,会在其中部署和管理微服务。 群集可以扩展到成千上万台计算机。

节点:属于群集一部分的计算机或 VM 称为节点。 需为每个节点分配节点名称(字符串)。 节点具有各种特征,如放置属性。 每个计算机或 VM 都有一个自动启动 Windows 服务 FabricHost.exe,此服务在引导时开始运行,并启动两个可执行文件:Fabric.exeFabricGateway.exe。 这两个可执行文件构成了节点。 在测试方案中,可以通过运行 Fabric.exeFabricGateway.exe 的多个实例,在单台计算机或 VM 上托管多个节点。

应用程序和服务概念

Service Fabric 网格应用程序:Service Fabric 网格应用程序是由资源模型(YAML 和 JSON 资源文件)描述的,并且可以部署到运行 Service Fabric 的任何环境。

Service Fabric 本机应用程序:Service Fabric 本机应用程序是由本机应用程序模型(基于 XML 的应用程序和服务清单)描述的。 Service Fabric 本机应用程序无法在 Service Fabric 网格中运行。

Service Fabric 网格应用程序概念

应用程序:应用程序是网格应用程序的部署、版本控制和生存期的单位。 每个应用程序实例的生命周期可以单独管理。 应用程序包括一个或多个服务代码包和设置。 应用程序是使用 Azure 资源模型 (RM) 架构定义的。 服务在 RM 模板中描述为应用程序资源的属性。 应用程序使用的网络和卷由应用程序引用。 创建应用程序时,将使用 Service Fabric 资源模型对应用程序、服务、网络和卷进行建模。

服务:应用程序中的服务表示一项微服务,并执行完整而独立的功能。 每项服务由一个或多个代码包组成,这些代码包描述运行与代码包关联的容器映像所需的所有内容。 可以纵向扩展和收缩应用程序中的服务数。

网络:网络资源为应用程序创建专用网络,并且独立于可以引用它的应用程序或服务。 来自不同应用程序的多个服务可以是同一网络的一部分。 网络是由应用程序引用的可部署资源。

代码包:代码包描述运行与代码包关联的容器映像所需的所有内容:

  • 容器名称、版本和注册表
  • 每个容器所需的 CPU 和内存资源
  • 网络终结点
  • 要在引用单独卷资的源容器中装载的卷。

定义为应用程序资源一部分的所有代码包作为一个组一起进行部署和激活。

:卷是装载在可用于保留状态的容器实例内的目录。 Azure 文件卷驱动程序将 Azure 文件共享装载到容器中,并通过支持文件存储的任何 API 提供可靠的数据存储。 卷是由应用程序引用的可部署资源。

Service Fabric 本机应用程序概念

应用程序:应用程序是由执行一个或多个特定功能的成分服务组成的集合。 每个应用程序实例的生命周期可以单独管理。

服务:服务执行完整且独立的功能,可以独立于其他服务启动和运行。 服务由代码、配置和数据组成。 对于每个服务,代码由可执行二进制文件组成,配置由可在运行时加载的服务设置组成,数据则由可供该服务使用的任意静态数据组成。

应用程序类型:分配给服务类型集合的名称/版本。 在 ApplicationManifest.xml 文件中定义并嵌入到应用程序包目录。 然后将目录复制到 Service Fabric 群集的映像存储。 然后,可以基于此应用程序类型,在群集内创建命名的应用程序。

有关详细信息,请阅读应用程序模型一文。

应用程序包:一个磁盘目录,其中包含应用程序类型的 ApplicationManifest.xml 文件。 引用构成应用程序类型的每个服务类型的服务包。 应用程序包目录中的文件会复制到 Service Fabric 群集的映像存储中。 例如,电子邮件应用程序类型的应用程序包可能包含对队列服务包、前端服务包和数据库服务包的引用。

命名应用程序:将应用程序包复制到映像存储后,在群集中创建应用程序实例。 当你指定应用程序包的应用程序类型时,通过使用其名称或版本来创建一个实例。 将为每个应用程序类型实例分配一个类似如下的统一资源标识符 (URI) 名称:"fabric:/MyNamedApp"。 在群集中,可以从单个应用程序类型创建多个命名应用程序。 也可以从不同的应用程序类型创建命名应用程序。 可单独管理每个命名应用程序并设置其版本。

服务类型:分配给服务的代码包、数据包、配置包的名称/版本。 服务类型在 ServiceManifest.xml 文件中定义,并嵌入到服务包目录中。 然后,服务包目录由应用程序包的 ApplicationManifest.xml 文件引用。 在群集中创建命名应用程序后,可以从应用程序类型的服务类型之一创建命名服务。 服务类型的 ServiceManifest.xml 文件描述该服务。

有关详细信息,请阅读应用程序模型一文。

有两种类型的服务:

  • 无状态:服务的持久状态存储在 Azure 存储、Azure SQL 数据库、Azure Cosmos DB 等外部存储服务中时,请使用无状态服务。 当服务没有永久性存储时,请使用无状态服务。 以计算器服务为例,首先要将值传递给该服务,然后服务使用这些值执行计算并返回结果。
  • 有状态:如果要让 Service Fabric 通过其 Reliable Collections 或 Reliable Actors 编程模型管理服务状态,请使用有状态服务。 创建命名服务时,请指定要将状态分布于其中的分区数量,以实现伸缩性。 此外,指定跨节点复制状态的次数,以实现可靠性。 每个命名服务都有一个主要副本和多个次要副本。 在写入主要副本时修改命名服务的状态。 然后,Service Fabric 会将此状态复制到所有次要副本以使状态保持同步。当主要副本失败时,Service Fabric 会自动检测到此状态,并将现有的次要副本升级为主要副本。 然后,Service Fabric 会创建新的次要副本。

副本或实例是指已部署或运行中的服务的代码(和有状态服务的状态)。 请参阅副本和实例

重新配置是指服务副本集中任何更改的过程。 请参阅重新配置

服务包:一个磁盘目录,其中包含服务类型的 ServiceManifest.xml 文件。 此文件引用服务类型的代码、静态数据和配置包。 应用程序类型的 ApplicationManifest.xml 文件引用服务包目录中的文件。 例如,服务包可能引用构成数据库服务的代码、静态数据和配置包。

命名服务:创建命名应用程序后,可以在群集中创建它的其中一个服务类型的实例。 通过使用其名称/版本指定服务类型。 需为每个服务类型实例分配一个 URI 名称,该名称归并到实例的命名应用程序的 URI 之下。 例如,如果在命名应用程序“MyNamedApp”中创建命名服务“MyDatabase”,则 URI 类似于:"fabric:/MyNamedApp/MyDatabase"。 在一个命名应用程序中可以创建多个命名服务。 每个命名服务可以有自身的分区方案和实例或副本计数。

代码包:一个磁盘目录,其中包含服务类型的可执行文件,通常是 EXE/DLL 文件。 服务类型的 ServiceManifest.xml 文件引用代码包目录中的文件。 创建命名服务后,会将代码包复制到选定来运行命名服务的一个或多个节点。 然后代码将开始运行。 有两种类型的代码包可执行文件:

  • 来宾可执行文件:在主机操作系统(Windows 或 Linux)上按原样运行的可执行文件。 这些可执行文件不会链接到或引用任何 Service Fabric 运行时文件,因此不会使用任何 Service Fabric 编程模型。 这些可执行文件不能使用某些 Service Fabric 功能,例如终结点发现的命名服务。 来宾可执行文件无法报告特定于每个服务实例的负载指标。
  • 服务主机可执行文件:通过链接到 Service Fabric 运行时文件、启用 Service Fabric 功能来使用 Service Fabric 编程模型的可执行文件。 例如,命名服务实例可在 Service Fabric 命名服务中注册终结点,还可以报告负载指标。

数据包:一个磁盘目录,其中包含服务类型的静态只读数据文件,通常是照片、音频和视频文件。 服务类型的 ServiceManifest.xml 文件引用数据包目录中的文件。 创建命名服务后,会将数据包复制到选定来运行命名服务的一个或多个节点。 代码开始运行,现在即可访问数据文件。

配置包:一个磁盘目录,其中包含服务类型的静态只读配置文件,通常是文本文件。 服务类型的 ServiceManifest.xml 文件引用配置包目录中的文件。 创建命名服务后,会将配置包中的文件复制到选定运行命名服务的一个或多个节点。 然后,代码开始运行,现在即可访问配置文件。

容器:默认情况下,Service Fabric 以进程形式部署和激活服务。 Service Fabric 还可在容器映像中部署服务。 容器是在应用程序中将基础操作系统虚拟化的一种虚拟化技术。 应用程序及其运行时、依赖项和系统库在一个容器内运行。 容器对自己的操作系统构造隔离视图具有全部专有访问权限。 Service Fabric 支持 Linux 和 Windows Server 容器上的 Docker 容器。 有关详细信息,请参阅 Service Fabric 和容器

分区方案:创建命名服务时,需要指定一个分区方案。 包含大量状态的服务跨分区拆分数据,将状态分散在群集的节点上。 通过在分区之间拆分数据,可以扩展命名服务的状态。 在分区中,无状态命名服务具有实例,而有状态命名服务具有副本。 通常,无状态命名服务只有一个分区,因为它们没有内部状态。 分区实例提供可用性。 如果一个实例失败,其他实例可继续正常运行,然后 Service Fabric 将创建新的实例。 有状态命名服务在副本中保持其状态,每个分区都有自身的副本集,以便状态保持同步。如果某个副本失败,Service Fabric 将从现有副本创建新副本。

有关详细信息,请阅读 Service Fabric Reliable Services 分区一文。

系统服务

系统在每个群集中创建了一些系统服务,用于提供 Service Fabric 的平台功能。

命名服务:每个 Service Fabric 群集均有一个命名服务,该服务将服务名称解析到群集中的某个位置。 使用类似于管理群集的 Internet 域名系统 (DNS) 的方式管理服务名称和属性。 客户端可以使用命名服务安全地与群集中的任何节点进行通信,以解析服务名称及其位置。 应用程序在群集内移动。 例如,原因可以是故障、资源平衡或重设群集大小。 可开发解析当前网络位置的服务和客户端。 客户端会获得实际计算机 IP 地址及其当前运行位置所在的端口。

有关使用搭配命名服务运行的客户端与服务通信 API 的详细信息,请阅读与服务通信

映像存储服务:每个 Service Fabric 群集都有一个映像存储服务,其中保存已部署且版本化的应用程序包。 将应用程序包复制到映像存储,并注册该应用程序包内包含的应用程序类型。 预配应用程序类型后,根据它创建命名应用程序。 在删除某个应用程序类型的所有命名应用程序之后,可以从映像存储服务中注销该应用程序类型。

有关映像存储服务的详细信息,请参阅了解 ImageStoreConnectionString 设置

有关将应用程序部署到映像存储服务的详细信息,请阅读部署应用程序一文。

故障转移管理器服务:每个 Service Fabric 群集都具有一个故障转移管理器服务,负责执行以下操作:

  • 执行与服务的高可用性和一致性相关的功能。
  • 协调应用程序和群集升级。
  • 与其他系统组件交互。

修复管理器服务:这是一项可选的系统服务,可在集群上实现自动、透明、安全的修复操作。 修复管理器可用于:

部署和应用程序模型

若要部署服务,需要描述服务的运行方式。 Service Fabric 支持 3 种不同的部署模型:

资源模型(预览版)

Service Fabric 资源是可以单独部署到 Service Fabric 的任何内容,包括应用程序、服务、网络和卷。 资源是使用 JSON 文件定义的,该文件可以部署到群集终结点。 对于 Service Fabric 网格,将使用 Azure 资源模型架构。 还可以使用 YAML 文件架构更轻松地创作定义文件。 可将资源部署到 Service Fabric 运行的任何位置。 资源模型是用来描述 Service Fabric 应用程序的最简单方法。 其主要重点在于容器化服务的简单部署和管理。

本机模块

本机应用程序模型为应用程序提供对 Service Fabric 的完整低级别访问权限。 应用程序和服务被定义为 XML 清单文件中的已注册类型。

本机模型支持 Reliable Services 框架和 Reliable Actors 框架,该框架提供对 C# 和 Java 中 Service Fabric 运行时 API 和群集管理 API 的访问权限。 本机模型还支持任意容器和可执行文件。 Service Fabric 网格环境中不支持本机模型。

Reliable Services:用于构建无状态和有状态服务的 API。 有状态服务将其状态存储在 Reliable Collections(例如字典或队列)中。 也可插入各种通信堆栈,如 Web API 和 Windows Communication Foundation (WCF)。

Reliable Actors:用于通过虚拟执行组件编程模型构建无状态和有状态对象的 API。 如果有大量的独立计算或状态单位,此模型可能十分有用。 此模型使用基于轮次的线程模型,因此最好避免使用向外调用其他执行组件或服务的代码,原因是只有在单个执行组件的所有出站请求都已完成后,该执行组件才能处理其他传入请求。

还可以在 Service Fabric 上运行现有应用程序:

容器:Service Fabric 支持在 Linux 上部署 Docker 容器,在 Windows Server 2016 上部署 Windows Server 容器,同时支持 Hyper-V 隔离模式。 在 Service Fabric 应用程序模型中,容器表示放置多个服务副本的应用程序主机。 Service Fabric 可运行任何容器,该方案类似于来宾可执行的方案,可在容器内打包现有应用程序。 此外,也可在容器内运行 Service Fabric 服务

来宾可执行文件:可在 Azure Service Fabric 中运行任何类型的代码(如 Node.js、Java 或 C++)作为服务。 Service Fabric 将这些类型的服务称为来宾可执行文件,视其为无状态服务。 在 Service Fabric 群集中运行来宾可执行文件的优点包括高可用性、运行状况监视、应用程序生命周期管理、高密度和可发现性。

有关详细信息,请阅读为服务选择编程模型一文。

Docker Compose

Docker Compose 是 Docker 项目的一部分。 Service Fabric 对使用 Docker Compose 模型部署应用程序提供了有限支持。

环境

Service Fabric 是一种开放源平台技术,多种不同的服务和产品都以它为基础。 Azure 提供了以下选项:

  • Azure Service Fabric 网格:一种完全托管服务,用于在 Azure 中运行 Service Fabric 应用程序。
  • Azure Service Fabric:Azure 托管的 Service Fabric 群集服务/产品。 它提供 Service Fabric 和 Azure 基础结构之间的集成,以及 Service Fabric 群集的升级和配置管理。
  • Service Fabric 独立:一组安装和配置工具,可在任何位置部署 Service Fabric 群集(在本地或任何云提供程序)。 不由 Azure 管理。
  • Service Fabric 开发群集:在 Windows、Linux 或 Mac 上提供本地开发经验,用于开发 Service Fabric 应用程序。

环境、框架和部署模型支持矩阵

不同的环境对框架和部署模型提供不同级别的支持。 下表介绍了支持的框架和部署模型组合。

应用程序类型 介绍依据 Azure Service Fabric 网格 Azure Service Fabric 群集(任意 OS) 本地群集 独立群集
Service Fabric 网格应用程序 资源模型(YAML 和 JSON) 支持 不支持 Windows - 支持,Linux 和 Mac - 不支持 Windows - 不支持
Service Fabric 本机应用程序 本机应用程序模型 (XML) 不支持 支持 支持 Windows - 支持

下表介绍了不同的应用模型以及针对 Service Fabric 为它们提供的工具。

应用程序类型 介绍依据 Visual Studio Eclipse SFCTL AZ CLI Powershell
Service Fabric 网格应用程序 资源模型(YAML 和 JSON) VS 2017 不支持 不支持 支持 - 仅网格环境 不支持
Service Fabric 本机应用程序 本机应用程序模型 (XML) VS 2017 和 VS 2015 支持 支持 支持 支持

后续步骤

了解有关 Service Fabric 的详细信息: