此参考体系结构显示部署到 Azure Service Fabric 的微服务体系结构。 其中显示的基本群集配置可用作大多数部署的起点。
GitHub 中提供了此体系结构的参考实现。
体系结构
下载此体系结构的 Visio 文件。
注意
本文重点介绍用于 Service Fabric 的 Reliable Services 编程模型。 使用 Service Fabric 部署和管理容器不在本文范围之内。
工作流
该体系结构包括以下组件。 有关其他术语，请参阅 Service Fabric 术语概述。
Service Fabric 群集。 群集是一组通过网络连接在一起的虚拟机 (VM)，你在其中部署和管理微服务。
虚拟机规模集。 通过虚拟机规模集，可创建并管理一组完全相同的、负载均衡的、自动缩放的 VM。 这些计算资源还提供容错域和升级域。
节点。 节点是属于 Service Fabric 群集的 VM。
节点类型。 节点类型表示用于部署节点集合的虚拟机规模集。 Service Fabric 群集至少具有一个节点类型。
在具有多个节点类型的群集中，必须将一个节点声明为主节点类型。 群集中的主节点类型运行 Service Fabric 系统服务。 这些服务提供 Service Fabric 的平台功能。 主节点类型还会充当种子节点，这些节点是维护基础群集可用性的节点。
配置其他节点类型以运行服务。
服务。 服务执行独立的功能，可以独立于其他服务启动和运行。 服务实例被部署到群集中的节点。 Service Fabric 中有两种服务：
Service Fabric Explorer。 Service Fabric Explorer 是一种用于检验和管理 Service Fabric 群集的开源工具。
Azure Pipelines。 Azure Pipelines 是 Azure DevOps Services 的一部分，可运行自动化的生成、测试和部署。 还可以使用第三方持续集成和持续交付 (CI/CD) 解决方案（如 Jenkins）。
Azure Monitor。 Azure Monitor 收集并存储指标和日志，包括解决方案中 Azure 服务的平台指标，以及应用程序遥测数据。 使用此数据可以监视应用程序、设置警报和仪表板，以及针对故障执行根本原因分析。 Azure Monitor 与 Service Fabric 相集成，可从控制器、节点和容器以及容器和节点日志收集指标。
Azure Key Vault。 使用 Key Vault 存储微服务使用的任何应用程序机密，例如连接字符串。
Azure API 管理。 在此体系结构中，API 管理 充当 API 网关，该网关接受来自客户端的请求并将其路由到服务。
注意事项
这些注意事项实现 Azure 架构良好的框架的支柱原则，即一套用于改进工作负载质量的指导原则。
设计注意事项
此参考体系结构侧重于微服务体系结构。 微服务是一个进行了版本控制的小型独立代码单元。 它可通过服务发现机制发现，并且可以通过 API 与其他服务进行通信。 每个服务都是自包含服务，并且应实现单个业务功能。 有关如何将应用程序域分解为微服务的详细信息，请参阅使用域分析对微服务进行建模。
Service Fabric 提供了一个可高效地构建、部署和升级微服务的基础结构。 它还提供了用于自动缩放、管理状态、监视运行状况以及在发生故障时重启服务的选项。
Service Fabric 遵循应用程序模型，其中应用程序是微服务的集合。 应用程序清单文件中介绍了该应用程序。 此文件定义应用程序包含的服务类型，以及指向独立服务包的指针。
应用程序包通常还包含用于替代服务使用的某些设置的参数。 每个服务包都有一个清单文件，该文件描述了运行该服务所需的物理文件和文件夹，包括二进制文件、配置文件和只读数据。 服务和应用程序是独立进行版本控制的，可进行升级。
（可选）应用程序清单可以描述在创建应用程序实例时自动预配的服务。 这些被称为默认服务。 在此例中，应用程序清单还介绍了应该如何创建这些服务。 该信息包括服务的名称、实例计数、安全或隔离策略以及放置约束。
注意
如果想要控制服务的生命周期，请避免使用默认服务。 默认服务是在创建应用程序时创建的，并在应用程序运行时一直运行。
如需了解详细信息，请参阅想要了解 Service Fabric？。
应用程序到服务打包模型
微服务的一个宗旨是每个服务都可以独立部署。 在 Service Fabric 中，如果将所有服务分组到单个应用程序包中，而其中一个服务升级失败，则整个应用程序升级都将回退。 这种回退会阻止其他服务升级。
因此，在微服务体系结构中，建议使用多个应用程序包。 将一个或多个密切相关的服务类型置于单个应用程序类型中。 例如，如果团队负责具有以下属性之一的一组服务，请将服务类型置于同一应用程序类型中：
- 它们的运行持续时间相同，需要同时更新。
- 它们具有相同的生命周期。
- 它们共享依赖项或配置等资源。
Service Fabric 编程模型
将微服务添加到 Service Fabric 应用程序时，请确定它是否具有需要使其具有高可用性和可靠性的状态或数据。 如果是这样，它可以在外部存储数据还是将数据作为服务的一部分包含在内？ 如果不需要存储数据或想要将数据存储在外部存储中，请选择无状态服务。 如果以下陈述之一适用，请考虑选择有状态服务：
- 你想要维护服务中的状态或数据。 例如，需要该数据驻留在靠近代码的内存中。
- 不能容忍对外部存储的依赖。
如果你有要在 Service Fabric 上运行的现有代码，可将其作为来宾可执行文件运行，该文件是以服务形式运行的任意可执行文件。 此外，你也可以将可执行文件打包到具有部署所需的所有依赖项的容器中。
Service Fabric 将容器和来宾可执行文件都建模为无状态服务。 有关选择模型的指导，请参阅 Service Fabric 编程模型概述。
你负责维护运行来宾可执行文件的环境。 例如，假设来宾可执行文件需要 Python。 如果可执行文件不是自包含文件，则需要确保在环境中预先安装了所需的 Python 版本。 Service Fabric 不管理环境。 Azure 提供了多种用于设置环境的方法，包括自定义虚拟机映像和扩展。
要通过反向代理访问来宾可执行文件，请确保已将 UriScheme 属性添加到来宾可执行文件的服务清单中的 Endpoint 元素。
<Endpoints>
<Endpoint Name="MyGuestExeTypeEndpoint" Port="8090" Protocol="http" UriScheme="http" PathSuffix="api" Type="Input"/>
</Endpoints>
如果服务具有其他路由，请在 PathSuffix 值中指定路由。 该值不应带有前缀或后缀斜线 (/)。 另一种方法是在服务名称中添加路由。
<Endpoints>
<Endpoint Name="MyGuestExeTypeEndpoint" Port="8090" Protocol="http" PathSuffix="api" Type="Input"/>
</Endpoints>
有关详细信息，请参阅：
API 网关
API 网关（入口）位于外部客户端和微服务之间。 它充当反向代理，将来自客户端的请求路由到微服务。 它还可以执行横切任务，例如身份验证、SSL 终止和速率限制。
大多数情况下，建议使用 Azure API 管理，但 Traefik 是一种常用的开源替代方法。 这两种技术选项都与 Service Fabric 集成。
API 管理。 公开公共 IP 地址并将流量路由到服务。 它在与 Service Fabric 群集相同的虚拟网络中的专用子网中运行。
API 管理可以访问通过具有专用 IP 地址的负载均衡器公开的节点类型中的服务。 此选项仅在 API 管理的“高级”和“开发人员”层中可用。 对于生产工作负载，请使用高级层。 API 管理定价中介绍了定价信息。
有关详细信息，请参阅有关 Service Fabric 与 Azure API 管理的概述。
Traefik。 支持路由、跟踪、日志和指标等功能。 Traefik 在 Service Fabric 群集中以无状态服务的形式运行。 可通过路由来支持服务版本控制。
有关如何将 Traefik 设置为服务入口以及作为群集内的反向代理的信息，请参阅 Traefik 网站上的 Azure Service Fabric 提供程序。 有关将 Traefik 用于 Service Fabric 的详细信息，请参阅博客文章使用 Traefik 在 Service Fabric 上进行智能路由。
Traefik 与 Azure API 管理不同，它没有用于解析请求路由到的有状态服务（具有多个分区）的分区的功能。 有关详细信息，请参阅添加用于分区服务的匹配程序。
其他 API 管理选项包括 Azure 应用程序网关和 Azure Front Door。 这些服务可与 API 管理结合使用，用于执行路由、SSL 终止和防火墙等任务。
服务间通信
若要促进服务到服务的通信，请考虑以下建议：
通信协议。 在微服务体系结构中，服务需要在运行时以少量耦合进行相互通信。 要实现与语言无关的通信，HTTP 是一个行业标准，其中包含以不同语言提供的多种工具和 HTTP 服务器。 Service Fabric 支持所有这些工具和服务器。
对于大多数工作负载，建议使用 HTTP 而不是 Service Fabric 内置的服务远程处理。
服务发现。 要与群集内的其他服务进行通信，客户端服务需要解析目标服务的当前位置。 在 Service Fabric 中，服务可以在节点之间移动并导致服务终结点动态更改。
为了避免连接到过时的终结点，可使用 Service Fabric 中的命名服务来检索更新后的终结点信息。 不过，Service Fabric 还提供了一个内置的反向代理服务，用于抽象命名服务。 对于大多数方案，我们建议将此选项用作服务发现的基线，因为它更易于使用并可生成更简单的代码。
用于服务间通信的其他选项包括：
- 用于高级路由的 Traefik。
- 用于服务期望使用 DNS 的兼容性场景的 DNS。
- ServicePartitionClient<TCommunicationClient> 类，用于缓存服务终结点。 它可实现更佳的性能，因为调用直接在服务之间进行，无需中介或自定义协议。
可伸缩性
Service Fabric 支持缩放这些群集实体：
- 缩放每个节点类型的节点数
- 缩放服务
本部分重点介绍自动缩放。 可以选择在适当的情况下手动缩放。 例如，可能需要手动干预才能设置实例数。
初始群集配置以实现可伸缩性
当你创建 Service Fabric 群集时，请基于安全性和可伸缩性需求预配节点类型。 每个节点类型都映射到虚拟机规模集，并且可以独立进行缩放。
- 为具有不同可伸缩性或资源要求的每组服务创建节点类型。 首先为 Service Fabric 系统服务预配节点类型（该节点类型将成为主节点类型）。 创建单独的节点类型以运行公共或前端服务。 根据需要为后端以及专用或独立服务创建其他节点类型。 指定放置约束，以便仅将服务部署到所需的节点类型。
- 为每个节点类型指定持续性层。 持续性层表示 Service Fabric 影响虚拟机规模集中更新和维护操作的能力。 对于生产工作负载，请选择 Silver 或更高的持续性层。 有关每一层的信息，请参阅群集的持续性特征。
- 如果使用 Bronze 持续性层，则某些操作需要手动步骤。 具有 Bronze 持续性层的节点类型需要在横向缩减期间执行其他步骤。 有关缩放操作的详细信息，请参阅本指南。
缩放节点
Service Fabric 支持自动缩放以实现横向缩减和横向扩展。每种节点类型可以单独配置为自动缩放。
每个节点类型最多可以包含 100 个节点。 从一小部分节点开始，然后根据负载情况添加更多节点。 如果在某个节点类型中需要超过 100 个节点，则需要添加更多节点类型。 有关详细信息，请参阅 Service Fabric 群集容量计划注意事项。 虚拟机规模集不会立即缩放，因此在设置自动缩放规则时需考虑该因素。
要支持自动横向缩减，请将节点类型配置为具有 Silver 或 Gold 持续性层。 此配置可确保在 Service Fabric 完成重新定位服务之前延迟横向缩减。 它还确保虚拟机规模集告知 Service Fabric，VM 已删除而不是暂时停机。
有关在节点或群集级别进行缩放的详细信息，请参阅缩放 Azure Service Fabric 群集。
缩放服务
无状态服务和有状态服务采用不同的方法进行缩放。
对于无状态服务（自动缩放）：
- 使用对分区负载触发器求平均值。 此触发器根据缩放策略中指定的负载阈值确定服务何时进行横向缩减或横向扩展。 还可设置检查触发器的频率。 请参阅对采用基于实例的缩放的分区负载触发器求平均值。 通过此方法，可以纵向扩展到可用的节点数。
- 在服务清单中将
InstanceCount设置为 -1，这将指示 Service Fabric 在每个节点上运行服务实例。 此方法使服务能够随着群集的缩放而进行灵活缩放。 随着群集中的节点数发生更改，Service Fabric 将自动创建和删除服务实例以进行匹配。
注意
在某些情况下，建议手动缩放服务。 例如，如果你具有从 Azure 事件中心读取数据的服务，则可能需要专用实例以从每个事件中心分区读取数据。 这样可以避免对分区进行并发访问。
对于有状态服务，缩放由分区数、每个分区的大小和在计算机上运行的分区或副本数控制：
如果你正在创建分区服务，请确保每个节点都能获得足够的副本，以便在不会导致资源争用的情况下均匀分发工作负载。 如果添加更多节点，Service Fabric 会默认将工作负载分发到新计算机上。 例如，如果有 5 个节点和 10 个分区，则默认情况下 Service Fabric 将在每个节点上放置两个主要副本。 如果横向扩展节点，则可以实现更佳的性能，因为工作均匀分布在更多资源中。
有关利用此策略的场景的信息，请参阅在 Service Fabric 中进行缩放。
同样不支持添加或删除分区。 另一个常用的缩放选项是动态创建或删除服务或整个应用程序实例。 通过创建或删除新命名服务进行缩放中描述了该模式的一个示例。
有关详细信息，请参阅：
使用指标对负载进行均衡
根据设计分区的方式，可能存在具有副本的节点比其他节点获得更多的流量。 为避免这种情况，请对服务状态进行分区，使其分布在所有分区中。 使用具有良好哈希算法的按范围分区方案。 请参阅开始进行分区。
Service Fabric 使用指标来了解如何在群集中放置和均衡服务。 在创建该服务时，可为与服务关联的每个指标指定默认负载。 Service Fabric 在放置服务时或每当服务需要移动（例如，在升级过程中）以均衡群集中的节点时，会考虑使用该负载。
最初为服务指定的默认负载不会在服务的生命周期内发生更改。 要捕获服务的更改指标，建议监视服务，然后动态报告负载。 通过此方法，Service Fabric 可根据在给定时间内报告的负载来调整分配。 使用 IServicePartition.ReportLoad 方法报告自定义指标。 有关详细信息，请参阅动态负载。
可用性
将服务置于主节点类型以外的节点类型中。 Service Fabric 系统服务始终部署到主节点类型。 如果服务被部署到主节点类型，则它们可能会与系统服务争夺资源（并干扰系统服务）。 如果某个节点类型需要托管有状态服务，请确保至少具有五个节点实例，并选择 Silver 或 Gold 持续性层。
请考虑限制服务的资源。 请参阅资源治理机制。
下面是常见注意事项：
- 不要将资源受管控的服务与同一节点类型上资源未受管控的服务混合使用。 不受管控的服务可能会消耗过多的资源，并影响资源受管控的服务。 请指定放置约束，确保此类服务不在同一组节点上运行。 （这是一个隔舱模式示例。）
- 指定要为服务实例保留的 CPU 核心和内存。 有关资源治理策略的使用情况和限制的信息，请参阅资源治理。
为了避免出现单一故障点 (SPOF)，请确保每个服务的目标实例或副本数大于 1。 可用作服务实例或副本数的最大数量等于约束服务的节点数。
确保每个有状态服务至少具有两个可用的次要副本。 建议对生产工作负载使用五个副本。
有关详细信息，请参阅 Service Fabric 服务的可用性。
安全性
安全性针对蓄意攻击及滥用宝贵数据和系统提供保障措施。 有关详细信息，请参阅安全性支柱概述。
下面是在 Service Fabric 上保护应用程序的一些要点。
虚拟网络
考虑为每个虚拟机规模集定义子网边界以控制通信流。 每个节点类型在 Service Fabric 群集的虚拟网络中的子网中都有自己的虚拟机规模集。 可将网络安全组 (NSG) 添加到子网，以允许或拒绝网络流量。 例如，对于前端和后端节点类型，可将 NSG 添加到后端子网以仅接受来自前端子网的入站流量。
从群集调用外部 Azure 服务时，请使用虚拟网络服务终结点（如果 Azure 服务支持它）。 使用服务终结点可将服务保护到仅群集的虚拟网络。
例如，如果使用 Azure Cosmos DB 存储数据，请使用服务终结点配置 Azure Cosmos DB 帐户以仅允许来自特定子网的访问。 请参阅从虚拟网络访问 Azure Cosmos DB 资源。
终结点和服务间通信
不要创建不安全的 Service Fabric 群集。 如果群集向公共 Internet 公开管理终结点，匿名用户可连接到该终结点。 不支持将不安全群集用于生产工作负荷。 请参阅 Service Fabric 群集安全方案。
若要帮助保护服务间通信，请执行以下操作：
- 考虑在 ASP.NET Core 或 Java Web 服务中启用 HTTPS 端点。
- 在反向代理和服务之间建立安全连接。 有关详细信息，请参阅连接到安全服务。
如果使用 API 网关，可将身份验证任务卸载到网关。 请确保除非部署了额外的安全措施来对消息进行身份验证，否则不能直接访问单个服务（在不使用 API 网关的情况下）。
不要向公众公开 Service Fabric 反向代理。 这样做会导致公开 HTTP 终结点的所有服务可从群集外寻址。 这将引入安全漏洞，并可能不必要地在群集外部公开其他信息。 如果要公开访问服务，请使用 API 网关。 本文后面的 API 网关部分介绍了一些选项。
远程桌面可用于诊断和故障排除，但请务必将其关闭。 保持打开状态会导致安全漏洞。
机密和证书
将机密（例如连接字符串）存储到密钥保管库中的数据存储。 密钥保管库必须与虚拟机规模集位于同一区域。 若要使用密钥保管库，请执行以下操作：
验证服务对密钥保管库的访问权限。
在托管服务的虚拟机规模集上启用托管标识。
将机密存储在密钥保管库中。
以可以转换为键值对的格式添加机密。 例如，使用
CosmosDB--AuthKey。 生成配置时，双连字符 (--) 会转换为冒号 (:)。在服务中访问这些机密。
在 appSettings.json 文件中添加密钥保管库 URI。 在服务中，添加从密钥保管库读取、生成配置并从生成的配置访问机密的配置提供程序。
下面是一个示例，其中工作流服务以“CosmosDB--Database”格式将机密存储在密钥保管库中。
namespace Fabrikam.Workflow.Service
{
public class ServiceStartup
{
public static void ConfigureServices(StatelessServiceContext context, IServiceCollection services)
{
var preConfig = new ConfigurationBuilder()
…
.AddJsonFile(context, "appsettings.json");
var config = preConfig.Build();
if (config["AzureKeyVault:KeyVaultUri"] is var keyVaultUri && !string.IsNullOrWhiteSpace(keyVaultUri))
{
preConfig.AddAzureKeyVault(keyVaultUri);
config = preConfig.Build();
}
}
}
要访问机密，请在生成的配置中指定机密名称。
if(builtConfig["CosmosDB:Database"] is var database && !string.IsNullOrEmpty(database))
{
// Use the secret.
}
不要使用客户端证书访问 Service Fabric Explorer。 改用 Microsoft Entra ID。 请参阅支持 Microsoft Entra 身份验证的 Azure 服务。
不要将自签名证书用于生产环境。
保护静态数据
如果你已将数据磁盘附加到 Service Fabric 群集的虚拟机规模集，并且服务将数据保存在这些磁盘上，则必须对磁盘进行加密。 有关详细信息，请参阅通过 Azure PowerShell（预览版）对虚拟机规模集中的 OS 和附加的数据磁盘进行加密。
有关保护 Service Fabric 的详细信息，请参阅：
复原
要从故障中恢复并保持完全正常运行的状态，应用程序必须实现某些复原能力模式。 下面是一些常见模式：
此参考实现使用开放源代码选项 Polly 来实现所有这些模式。
监视
在了解监视选项之前，建议先阅读这篇关于通过 Service Fabric 诊断常见场景的文章。 可以考虑在这些集合中监视数据：
下面是用于分析该数据的两个主要选项：
- Application Insights
- Log Analytics
可使用 Azure Monitor 设置用于监视的仪表板并向操作员发送警报。 一些第三方监视工具也与 Service Fabric 集成，例如 Dynatrace。 有关详细信息，请参阅 Azure Service Fabric 监视合作伙伴。
应用程序指标和日志
应用程序遥测提供有助于监视服务的运行状况并识别问题的数据。 若要在服务中添加跟踪和事件，请执行以下操作：
- 如果通过 ASP.NET Core 开发服务，请使用 Microsoft.Extensions.Logging。 对于其他框架，请使用所选的日志库，例如 Serilog。
- 通过使用 SDK 中的 TelemetryClient 类添加自己的检测，并在 Application Insights 中查看数据。 请参阅将自定义检测添加到应用程序。
- 使用 EventSource 记录 Windows (ETW) 事件的事件跟踪。 默认情况下，此选项在 Visual Studio Service Fabric 解决方案中可用。
Application Insights 提供许多内置的遥测：请求、跟踪、事件、异常、指标、依赖项。 如果服务公开 HTTP 端点，请通过调用 Microsoft.AspNetCore.Hosting.IWebHostBuilder 的 UseApplicationInsights 扩展方法来启用 Application Insights。 有关为 Application Insights 检测服务的信息，请参阅以下文章：
- 教程：使用 Application Insights 在 Service Fabric 上监视和诊断 ASP.NET Core 应用程序
- 用于 ASP.NET Core 的 Application Insights
- Application Insights .NET SDK
- 适用于 Service Fabric 的 Application Insights SDK
要查看跟踪和事件日志，请将 Application Insights 用作结构化日志记录的接收器之一。 通过调用 AddApplicationInsights 扩展方法，使用检测密钥配置 Application Insights。 在此示例中，检测密钥以机密形式存储在密钥保管库中。
.ConfigureLogging((hostingContext, logging) =>
{
logging.AddApplicationInsights(hostingContext.Configuration ["ApplicationInsights:InstrumentationKey"]);
})
如果服务不公开 HTTP 端点，则需要编写用于将跟踪发送到 Application Insights 的自定义扩展。 有关示例，请参阅参考实现中的工作流服务。
ASP.NET Core 服务使用 ILogger 接口进行应用程序日志记录。 要使这些应用程序日志在 Azure Monitor 中可用，请将 ILogger 事件发送到 Application Insights。 Application Insights 可将关联属性添加到 ILogger 事件，这对于可视化分布式跟踪很有用。
有关详细信息，请参阅：
Service Fabric 运行状况和事件数据
Service Fabric 遥测包括有关 Service Fabric 群集及其实体（其节点、应用程序、服务、分区和副本）的操作和性能的运行状况指标和事件。 运行状况和事件数据可能来自：
EventStore。 这个有状态系统服务收集与群集及其实体相关的事件。 Service Fabric 使用 EventStore 来编写 Service Fabric 事件，以提供有关群集的信息，用于进行状态更新、故障排除和监视。 EventStore 还可以在给定时间内关联来自不同实体的事件，以识别群集中的问题。 该服务通过 REST API 公开这些事件。
有关如何查询 EventStore API 的信息，请参阅查询群集事件的 EventStore API。 可以通过使用适用于 Windows 的 Azure 诊断扩展 (WAD) 配置群集，在 Log Analytics 中查看 EventStore 中的事件。
HealthStore。 这个有状态服务提供群集当前运行状况的快照。 它聚合层次结构中由实体报告的所有运行状况数据。 数据在 Service Fabric Explorer 中可视化。 HealthStore 还将监视应用程序升级。 可在 PowerShell、.NET 应用程序或 REST API 中使用运行状况查询。 请参阅 Service Fabric 运行状况监视简介。
自定义运行状况报告。 请考虑实现内部监视程序服务，这些服务可定期报告自定义运行状况数据，例如运行服务的故障状态。 可在 Service Fabric Explorer 中读取运行状况报告。
基础结构指标和日志
基础结构指标可帮助你了解群集中的资源分配。 下面是用于收集此信息的主要选项：
- WAD。 在 Windows 上收集节点级别的日志和指标。 可以通过在映射到节点类型的任何虚拟机规模集上配置 IaaSDiagnostics VM 扩展，使用 WAD 以收集诊断事件。 这些事件可能包括 Windows 事件日志、性能计数器、ETW/清单系统和操作事件以及自定义日志。
- Log Analytics 代理。 配置 MicrosoftMonitoringAgent VM 扩展，以将 Windows 事件日志、性能计数器和自定义日志发送到 Log Analytics。
通过上述方法收集的指标类型存在一些重叠，例如性能计数器。 如果存在重叠，建议使用 Log Analytics 代理。 由于 Log Analytics 代理不使用 Azure 存储，因此延迟较低。 此外，IaaSDiagnostics 中的性能计数器无法轻松注入 Log Analytics。
有关使用 VM 扩展的信息，请参阅 Azure 虚拟机扩展和功能。
要查看数据，请将 Log Analytics 配置为显示通过 WAD 收集的数据。 有关如何配置 Log Analytics 以从存储帐户读取事件的信息，请参阅为群集设置 Log Analytics。
还可查看与 Service Fabric 群集、工作负载、网络流量、挂起的更新等相关的性能日志和遥测数据。 请参阅通过 Log Analytics 实现性能监视。
Log Analytics 中的服务映射解决方案提供有关群集拓扑（即每个节点中运行的进程）的信息。 将存储帐户中的数据发送到 Application Insights。 将数据导入到 Application Insights 可能存在一些延迟。 如果要实时查看数据，请考虑使用接收器和通道配置事件中心。 有关详细信息，请参阅使用 WAD 的事件聚合和收集。
依赖服务指标
- Application Insights 中的应用程序映射通过使用在服务之间进行的 HTTP 依赖项调用和已安装的 Application Insights SDK 来提供应用程序的拓扑。
- Log Analytics 中的服务映射提供有关出/入外部服务的入站和出站流量的信息。 服务映射还与其他解决方案（例如更新或安全性）集成。
- 自定义监视程序可报告外部服务的错误情况。 例如，如果服务无法访问外部服务或数据存储 (Azure Cosmos DB)，则它可能会提供错误运行状况报告。
分布式跟踪
在微服务体系结构中，通常使用多个服务来完成一项任务。 通过在分布式跟踪中使用上下文字段（例如操作 ID 和请求 ID）来关联来自这些服务中的每一个的遥测数据。
通过使用 Application Insights 中的应用程序映射，可以生成分布式逻辑操作的视图并将应用程序的整个服务图可视化。 还可使用 Application Insight 中的事务诊断来关联服务器端遥测。 有关详细信息，请参阅统一的跨组件事务诊断。
关联使用队列以异步方式调度的任务也很重要。 有关在队列消息中发送相关遥测的详细信息，请参阅队列检测。
有关详细信息，请参阅：
警报和仪表板
Application Insights 和 Log Analytics 支持一种广泛的查询语言（Kusto 查询语言），可用于检索和分析日志数据。 使用查询创建数据集并在诊断仪表板中将其可视化。
当特定资源中出现特定情况时，请使用 Azure Monitor 警报通知系统管理员。 例如，通知可以是电子邮件、Azure 函数或 Webhook。 有关详细信息，请参阅 Azure Monitor 中的警报。
日志搜索预警规则允许定期针对 Log Analytics 工作区定义和运行 Kusto 查询。 如果查询结果符合特定条件，则将创建警报。
成本优化
使用 Azure 定价计算器估算成本。 Microsoft Azure 架构良好的框架的成本优化支柱描述了其他注意事项。
此处提供了对于此体系结构中使用的某些关键服务需要考虑的事项。
Azure Service Fabric
需为创建 Service Fabric 群集时选择的计算实例、存储、网络资源和 IP 地址付费。 Service Fabric 需为部署付费。
虚拟机规模集
在此体系结构中，微服务被部署到作为虚拟机规模集的节点中。 需为作为群集的一部分部署的 Azure VM 和底层基础结构资源（例如存储和网络）付费。 虚拟机规模集本身不收取额外费用。
Azure API 管理
Azure API 管理是用于将来自客户端的请求路由到群集中的服务的网关。
有多种定价选项。 “消耗”选项按使用量付费并包括网关组件。 根据工作负载的不同，请选择 API 管理定价中所述的选项。
Application Insights
可以使用 Application Insights 来收集所有服务的遥测，以结构化的方式查看跟踪和事件日志。 Application Insights 的定价是一种基于引入的数据量和数据保留选项的即用即付模型。 有关详细信息，请参阅管理 Application Insights 的使用情况和成本。
Azure Monitor
对于 Azure Monitor Log Analytics，需要为数据引入和保留付费。 有关详细信息，请参阅 Azure Monitor 定价。
Azure Key Vault
使用 Azure Key Vault 将 Application Insights 的检测密钥存储为机密。 Azure 在两个服务层级中提供密钥保管库。 如果不需要受 HSM 保护的密钥，请选择“标准层”。 有关每层中的功能的信息，请参阅 Key Vault 定价。
Azure DevOps Services
此参考体系结构使用 Azure Pipelines 进行部署。 通过 Azure Pipelines 服务，可以免费获得 Microsoft 托管的作业（每月 CI/CD 时长为 1,800 分钟）和 1 个自托管作业（每月不限时长）。 额外的作业需要收费。 有关详细信息，请参阅 Azure DevOps 服务定价。
有关微服务体系结构中的 DevOps 注意事项，请参阅针对微服务的 CI/CD。
如需了解如何将带有 CI/CD 的容器应用程序部署到 Service Fabric 群集，请参阅此教程。
部署此方案
要部署此体系结构的参考实现，请按照 GitHub 存储库中的步骤操作。