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