Azure 上的任务关键型体系结构
本文系列提供了在 Azure 上设计任务关键型工作负荷的指导。 它优先考虑云原生功能，以最大限度地提高可靠性和运营效率。 它为 Well-Architected 任务关键型工作负荷应用设计方法。
关键设计策略
许多因素可能会影响应用程序的可靠性，例如从故障、区域可用性、部署有效性和安全性中恢复的能力。 应用一组总体设计策略来解决这些因素，并确保实现目标可靠性层。
任务关键型工作负荷通常以 SLO 99.99% 或更高版本为目标，这相当于允许的年停机 52 分 35 秒。 因此，所有包含的设计决策都旨在实现此目标 SLO。
层中的冗余
部署到 主动-主动模型中的多个区域。 该应用程序分布在两个或多个处理活动用户流量的 Azure 区域。
利用所有已考虑的服务 的可用性区域 ，在单个 Azure 区域中最大化可用性，将组件分布到区域中物理上独立的数据中心。
选择支持 全局分发的资源。
部署标记
将区域戳部署为 缩放单元 ，其中可以独立预配一组逻辑资源，以跟上需求的变化。 每个标记还应用多个嵌套缩放单元，例如前端 API 和后台处理器，这些单元可以独立扩展和横向扩展。
可靠且可重复的部署
使用 Terraform 等技术应用 基础结构即代码（IaC）原则 ，为基础结构组件提供版本控制和标准化作方法。
实现 零停机时间蓝/绿部署管道。 生成和发布管道必须完全自动化，才能将戳记部署为单个作单元，并使用应用了持续验证的蓝/绿部署。
在所有考虑的环境中应用 环境一致性 ，在生产和预生产环境中使用相同的部署管道代码。 这消除了与部署和跨环境处理变体相关的风险。
通过将自动化测试作为 DevOps 过程的一部分（包括同步的负载和混乱测试）进行 持续验证 ，以完全验证应用程序代码和底层基础结构的运行状况。
操作见解
具有 联合工作区以获取可观测性数据。 全局资源和区域资源的监视数据单独存储。 不建议使用集中式可观测性存储来避免单一故障点。 跨工作区查询用于实现统一的数据接收器和单一窗格的作。
构造 分层运行状况模型 ，用于将应用程序运行状况映射到用于上下文化的交通灯模型。 运行状况分数针对每个单个组件进行计算，然后在用户流级别聚合，并结合关键非功能要求（例如性能）作为量化应用程序运行状况的系数。
设计领域
建议在定义任务关键型体系结构时浏览这些设计领域，了解建议和最佳做法指南。
| 设计领域 | DESCRIPTION |
|---|---|
| 应用程序平台 | 针对潜在故障情况的基础结构选择和缓解措施。 |
| 应用程序设计 | 允许缩放和错误处理的设计模式。 |
| 网络和连接 | 将传入流量路由到戳记的网络注意事项。 |
| 数据平台 | 数据存储技术中的选择，通过评估所需的卷、速度、多样性和真实性特征来告知。 |
| 部署和测试 | CI/CD 管道和自动化注意事项的策略，包括已合并的测试方案，例如同步负载测试和故障注入（混沌）测试。 |
| 运行状况建模 | 通过客户影响分析相关的监视来确定整体应用程序运行状况的可观测性注意事项。 |
| 安全性 | 通过零信任模型Microsoft缓解攻击途径。 |
| 作过程 | 与部署、密钥管理、修补和更新相关的过程。 |