此体系结构提供有关在 Azure 上设计任务关键型工作负载的指导。 它使用云原生功能最大限度地提高可靠性和运营效率。 它将适用于精心构建的任务关键型工作负载的设计方法应用到网络应用程序，其中工作负载通过公共终结点进行访问，并且不需要与其他公司资源的专用网络连接。
重要
该指南由生产级示例实现提供支持，该实现展示了 Azure 上的任务关键型应用程序开发。 在生产的第一步中，此实现是进一步进行解决方案开发的基础。
可靠性层
可靠性是一个相对的概念，要使工作负载具有适当的可靠性，它应该反映围绕它的业务需求（包括服务级别目标 (SLO) 和服务级别协议 (SLA)），来捕获应用程序应保持可用的时间百分比。
此体系结构面向 99.99% 的 SLO，对应的允许年停机时间为 52 分钟 35 秒。 因此，所有包含的设计决策都旨在实现此目标 SLO。
提示
若要定义现实的 SLO，请务必了解体系结构范围内所有 Azure 组件的可靠性目标和其他因素。 有关详细信息，请参阅有关定义可靠性目标的建议。 应聚合这些单独的数字，以确定应与工作负荷目标一致的复合 SLO。
关键设计策略
许多因素可能会影响应用程序的可靠性，例如从故障中恢复的能力、区域可用性、部署有效性和安全性。 此体系结构应用一组总体设计策略，旨在解决这些因素，并确保实现目标可靠性层。
层中的冗余
部署到主动-主动模型中的多个区域。 应用程序分布在处理活动用户流量的两个或多个 Azure 区域。
将可用性区域用于所有已考虑的服务，以最大程度地提高单个 Azure 区域中的可用性，将组件分布到区域中的物理独立数据中心。
选择支持全局分发的资源。
部署标记
将区域标记部署为缩放单元，其中可以独立预配一组逻辑资源，以跟上需求的变化。 每个标记还应用多个嵌套缩放单元，例如前端 API 和后台处理器，这些单元可以独立横向扩展。
可靠且可重复的部署
使用 Terraform 等技术应用基础结构即代码 (IaC) 原则，为基础结构组件提供版本控制和标准化操作方法。
实现零停机时间蓝/绿部署管道。 生成和发布管道必须完全自动化，才能使用应用的持续验证的蓝/绿部署，将标记部署为单个操作单元。
在所有已考虑的环境中应用环境一致性，在生产环境和预生产环境中使用相同的部署管道代码。 这消除了与跨环境部署和流程变化相关的风险。
通过将自动化测试作为 DevOps 过程的一部分（包括同步的负载和混乱测试）进行持续验证，以充分验证应用程序代码和底层基础结构的运行状况。
操作见解
具有用于可观测数据的联合工作区。 全局资源和区域资源的监视数据独立存储。 不建议使用集中式可观测性存储来避免单一故障点。 跨工作区查询用于实现统一的数据接收器和单一操作窗格。
构造分层运行状况模型，将应用程序运行状况映射到交通灯模型进行上下文化。 针对每个组件计算运行状况分数，然后在用户流级别聚合，并结合关键非功能要求（例如性能）来量化应用程序运行状况的系数。
体系结构
*下载此体系结构的 Visio 文件。
此体系结构的组件可以采用这种方式进行广泛分类。 有关 Azure 服务的产品文档，请参阅相关资源。
全局资源
全局资源生存期长，并共享系统的生存期。 它们具有在多区域部署模型上下文中全局可用的功能。
下面是有关组件的高级注意事项。 有关决策的详细信息，请参阅全局资源。
全局负载均衡器
全局负载均衡器对于可靠地将流量路由到区域部署至关重要，其保证级别取决于区域中后端服务的可用性。 此外，此组件应能够检查入口流量，例如通过 Web 应用程序防火墙。
Azure Front Door 用作所有传入客户端 HTTP 流量的全局入口点，Web 应用程序防火墙 (WAF) 功能应用于保护第 7 层入口流量。 它使用 TCP Anycast 通过 Microsoft 主干网络优化路由，并允许在出现降级的区域运行状况时进行透明故障转移。 路由依赖于自定义运行状况探测，其可检测关键区域资源的综合运行状况。 Azure Front Door 还提供内置内容分发网络 (CDN) 来缓存网站组件的静态资产。
另一个选项是 Microsoft Azure 流量管理器，这是基于 DNS 的第 4 层负载均衡器。 但是，由于必须发生 DNS 传播，因此所有客户端的失败并不透明。
数据库
与工作负荷相关的所有状态都存储在外部数据库 Azure Cosmos DB for NoSQL 中。 之所以选择此选项，是因为它在客户端和服务器端都具有性能和可靠性优化所需的功能集。 强烈建议帐户启用多主数据库写入。
注意
虽然多区域写入配置表示可靠性的黄金标准，但成本存在重大权衡，这应该得到适当的考虑。
该帐户将复制到每个区域标记，并且还启用了区域性冗余。 此外，会在容器级别启用自动缩放，以便容器根据需要自动缩放预配的吞吐量。
有关详细信息，请参阅任务关键型工作负载的数据平台。
容器注册表
Azure 容器注册表用于存储所有容器映像。 它具有异地复制功能，允许资源充当单个注册表，为具有多主数据库区域注册表的多个区域提供服务。
作为安全措施，仅允许访问所需的实体并对该访问进行身份验证。 例如，在实现中，管理员访问权限处于禁用状态。 因此，计算群集只能使用 Microsoft Entra 角色分配拉取映像。
区域资源
区域资源作为部署标记的一部分预配到单个 Azure 区域。 这些资源与其他区域中的资源完全不同。 可以独立删除或复制到其他区域。 但是，它们相互共享全局资源。
在此体系结构中，统一部署管道使用这些资源部署标记。
下面是有关组件的高级注意事项。 有关决策的详细信息，请参阅区域标记资源。
前端
此体系结构使用将请求发送到后端服务的单页应用程序 (SPA)。 优点是将网站体验所需的计算卸载到客户端而不是服务器。 SPA 作为静态网站托管在 Microsoft Azure 存储帐户中。
另一种选择是 Azure Static Web Apps，它引入了其他注意事项，例如证书的公开方式、与全局负载均衡器的连接以及其他因素。
静态内容通常使用内容分发网络 (CDN) 缓存在靠近客户端的存储中，以便可以快速提供数据，而无需直接与后端服务器通信。 这是一种划算的提高可靠性和降低网络延迟的的方法。 在此体系结构中，Azure Front Door 的内置 CDN 功能用于在边缘网络中缓存静态网站内容。
计算群集
后端计算运行由三个微服务组成的应用程序，且无状态。 因此，容器化是托管应用程序的适当策略。 选择 Azure Kubernetes 服务 (AKS) 是因为它符合大多数业务要求，Kubernetes 在许多行业被广泛采用。 AKS 支持高级可伸缩性和部署拓扑。 强烈建议使用 AKS 运行时间 SLA 层来托管任务关键型应用程序，因为它为 Kubernetes 控制平面提供可用性保证。
Azure 提供其他计算服务，例如 Azure Functions 和 Azure 应用服务。 这些选项以灵活性和密度为代价将额外的管理责任卸载到 Azure。
注意
避免在计算群集上存储状态，请记住标记的临时性质。 尽可能多地将状态保留在外部数据库中，以保持缩放和恢复操作的轻量级。 例如，在 AKS 中，Pod 经常更改。 将状态附加到 Pod 将增加数据一致性的负担。
区域消息中转站
为了优化性能，并在高峰负载期间保持响应能力，设计使用异步消息传送来处理密集型系统流。 当请求很快被确认回前端 API，请求也会在消息中转中中排队。 这些消息随后由后端服务使用，例如，处理对数据库的写入操作。
整个标记是无状态的，但在某些点除外，如消息中转站。 数据在中转站中排队时间比较短。 消息中转站必须保证至少传递一次。 这意味着如果在服务还原后中转站变得不可用，消息也会留在队列中。 但是，使用者有责任确定这些消息是否仍需要处理。 在处理消息并将其存储在全局数据库中后，队列将清空。
在此设计中，将使用 Azure 事件中心。 为检查点预配了额外的 Microsoft Azure 存储帐户。 对于需要高吞吐量（例如事件流式处理）的用例，建议选择 Azure 事件中心。
对于需要额外消息保证的用例，建议使用 Microsoft Azure 服务总线。 它允许使用客户端游标进行两阶段提交，以及内置死信队列和重复数据删除功能等功能。
有关详细信息，请参阅任务关键型工作负载的消息传送服务。
区域机密存储
每个标记都有其自己的 Azure Key Vault，用于存储机密和配置。 全局数据库存在像连接字符串一样的常见机密，也存在对单一标记而言唯一的信息，比如 Azure 事件中心连接字符串。 此外，独立资源可避免单一故障点。
部署管道
必须将任务关键型应用程序的生成和发布管道完全自动化。 因此，无需手动执行任何操作。 此设计演示了每次部署验证标记的完全自动化管道。 另一种替代方法是仅将滚动更新部署到现有标记。
源代码存储库
GitHub 用于源代码管理，提供一个高度可用的基于 git 的平台，用于在应用程序代码和基础结构代码上进行协作。
持续集成/持续交付 (CI/CD) 管道
在预生产环境和生产环境中生成、测试和部署任务型工作负荷需要自动化管道。 选择 Azure Pipelines，因为它丰富的工具集可以面向 Azure 和其他云平台。
另一种选择是针对 CI/CD 管道的 GitHub Actions。 添加的好处是源代码和管道可以并置。 但是，由于 CD 功能更丰富，选择了 Azure Pipelines。
生成代理
此实现使用 Microsoft 托管的生成代理来降低复杂性和管理开销。 自托管代理可用于需要强化安全态势的方案。
注意
使用自托管代理在任务关键 - 连接参考实现中进行了演示。
可观测性资源
应用程序和基础结构中的操作数据必须可用，以便有效操作并最大限度地提高可靠性。 此参考提供了实现应用程序整体可观测性的基线。
统一数据接收器
- Azure Log Analytics 用作统一接收器，用于存储所有应用程序和基础结构组件的日志和指标。
- Azure Application Insights 用作应用程序性能管理 (APM) 工具，用于收集所有应用程序监视数据并将其直接存储在 Log Analytics 中。
全局资源和区域资源的监视数据应独立存储。 不建议使用单个集中式可观测性存储来避免单一故障点。 跨工作区查询用于实现单个玻璃窗格。
在此体系结构中，监视区域中的资源必须独立于标记本身，因为如果拆毁了标记，仍要保留可观测性。 每个区域标记都有其自己的专用 Application Insights 和 Log Analytics 工作区。 资源是按区域预配的，但它们与标记不一样。
同样，共享服务（例如 Azure Front Door、Azure Cosmos DB 和容器注册表）中的数据将存储在 Log Analytics 工作区的专用实例中。
数据存档和分析
活动操作不需要的操作数据会从 Log Analytics 导出到 Azure 存储帐户，以实现数据保留目的，并为 AIOps 提供分析源，该源可用于优化应用程序运行状况模型和操作过程。
请求和处理器流
此图显示了参考实现的请求和后台处理器流。
此流的说明位于以下部分中。
网站请求流
向全局负载均衡器发送 Web 用户界面请求。 对于此体系结构，全局负载均衡器是 Azure Front Door。
已评估 WAF 规则。 WAF 规则通过防范各种攻击（例如跨站点脚本 (XSS) 和 SQL 注入）来积极影响系统的可靠性。 如果违反 WAF 规则并停止处理，Azure Front Door 将向请求者返回错误。 如果没有违反 WAF 规则，Azure Front Door 将继续处理。
Azure Front Door 使用传递规则来确定要转发请求的后端池。 如何将请求匹配到传递规则。 在此参考实现中，传递规则允许 Azure Front Door 将 UI 和前端 API 请求路由到不同的后端资源。 在这种情况下，模式“/*”与 UI 传递规则匹配。 此规则将请求路由到包含包含托管单页应用程序 (SPA) 静态网站的存储帐户的后端池。 Azure Front Door 使用分配给池中的后端的优先级和权重来选择要路由请求的后端。 将流量路由到源的方法。 Azure Front Door 使用运行状况探测来确保请求不会路由到不正常的后端。 SPA 由具有静态网站的所选存储帐户提供。
注意
Azure Front Door 经典版中的后端池和后端称为 Azure Front Door 标准层或高级版层中的源组和源。
SPA 对 Azure Front Door 前端主机进行 API 调用。 API 请求 URL 的模式为“/api/*”。
前端 API 请求流
WAF 规则的评估方式与步骤 2 中类似。
Azure Front Door 通过“/api/*”模式将请求与 API 传递规则匹配。 API 传递规则将请求路由到后端池，其中包含 NGINX 入口控制器的公共 IP 地址，这些地址知道如何将请求路由到 Azure Kubernetes 服务 (AKS) 中的正确服务。 与以前一样，Azure Front Door 使用分配给后端的优先级和权重来选择正确的 NGINX 入口控制器后端。
对于 GET 请求，前端 API 对数据库执行读取操作。 对于此参考实现，数据库是全局 Microsoft Azure Cosmos DB 实例。 Microsoft Azure Cosmos DB 具有多项功能，使它成为任务关键型工作负荷的不错选择，包括能够轻松配置多写入区域，从而自动故障转移读取和写入次要区域。 API 使用配置了重试逻辑的客户端 SDK 与 Azure Cosmos DB 通信。 SDK 根据 ApplicationRegion 参数确定要与之通信的可用 Azure Cosmos DB 区域的最佳顺序。
对于 POST 或 PUT 请求，前端 API 对消息中转站执行写入操作。 在引用实现中，消息中转站是 Azure 事件中心。 也可以选择 Microsoft Azure 服务总线。 处理程序稍后将从消息中转站读取消息，并执行对 Azure Cosmos DB 的任何必需写入。 API 使用客户端 SDK 执行写入。 可以为重试配置客户端。
后台处理器流
后台处理器处理来自消息中转站的消息。 后台处理器使用客户端 SDK 执行读取。 可以为重试配置客户端。
后台处理器对全局 Microsoft Azure Cosmos DB 实例执行适当的写入操作。 后台处理器使用配置为重试的客户端 SDK 连接到 Microsoft Azure Cosmos DB。 客户端的首选区域列表可以配置多个区域。 在这种情况下，如果写入失败，将在下一个首选区域中重试。
设计领域
建议在定义任务关键型体系结构时，了解这些设计领域的建议和最佳做法指南。
| 设计领域 | 说明 |
|---|---|
| 应用程序设计 | 允许缩放和错误处理的设计模式。 |
| 应用程序平台 | 针对潜在故障情况的基础结构选择和缓解措施。 |
| 数据平台 | 数据存储技术中的选择，通过评估所需的卷、速度、品种和真实性特征来告知。 |
| 网络和连接 | 将传入流量路由到标记的网络注意事项。 |
| 运行状况建模 | 通过客户影响分析相关的监视来确定整体应用程序运行状况的可观测性注意事项。 |
| 部署和测试 | CI/CD 管道策略和自动化注意事项，包括已合并的测试方案，例如同步负载测试和故障注入 （混乱）测试。 |
| 安全性 | 通过 Microsoft 零信任模型缓解攻击途径。 |
| 操作过程 | 与部署、密钥管理、修补和更新相关的过程。 |
** 表示特定于此体系结构的设计区域注意事项。
相关资源
有关此体系结构中使用的 Azure 服务的产品文档，请参阅以下文章。
- Azure Front Door
- Azure Cosmos DB
- Azure 容器注册表
- Azure Log Analytics
- Azure Key Vault
- Azure 服务总线
- Azure Kubernetes 服务
- Azure Application Insights
- Azure 事件中心
- Azure Blob 存储
部署此体系结构
部署参考实现，以便完全了解已考虑的资源，包括如何在任务关键型上下文中操作这些资源。 它包含一个部署指南，旨在说明在 Azure 上进行任务关键型应用程序开发的面向解决方案的方法。
后续步骤
如果想要通过对入口和出口流量的网络控制来扩展体系结构，请参阅此体系结构。