你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
任务关键型工作负载的设计原则
任务关键型设计方法以五项关键设计原则为基础，这些原则可作为跨关键设计领域的后续设计决策的指南针。 强烈建议你熟悉这些原则，以更好地了解其影响以及与不遵守相关的权衡。
重要
本文是 Azure Well-Architected 任务关键型工作负载 系列的一部分。 如果不熟悉本系列，建议从 什么是任务关键型工作负载开始？
这些任务关键型设计原则共鸣并扩展了 Azure Well-Architected 框架的质量支柱-可靠性、安全性、成本优化、卓越运营和性能效率。
可靠性
最高可靠性 - 基本追求最可靠的解决方案，确保正确理解权衡。
| 设计原则 | 注意事项 |
|---|---|
| 主动/主动设计 | 若要最大程度地提高可用性并实现区域容错，应尽可能使用主动/主动部署模型将解决方案组件分布到多个可用性区域和 Azure 区域。 |
| 爆破半径减少和故障隔离 | 在 Azure 等高度分布式多租户云环境中，无法避免故障。 通过预测故障和相关影响（从单个组件到整个 Azure 区域），可以采用可复原的方式设计和开发解决方案。 |
| 观察应用程序运行状况 | 在缓解影响应用程序可靠性的问题之前，必须先检测并了解这些问题。 通过监视应用程序相对于已知正常状态的操作，可以检测甚至预测可靠性问题，从而快速采取补救措施。 |
| 驱动器自动化 | 应用程序停机的主要原因之一是人为错误，无论是由于部署测试不足的软件还是配置错误。 为了尽量减少人为错误的可能性和影响，必须努力在云解决方案的所有方面实现自动化以提高可靠性;自动测试、部署和管理。 |
| 自我修复设计 | 自我修复描述系统通过连接到解决方案中的故障模式的预定义修正协议自动处理故障的能力。 这是一个高级概念，需要高度的系统成熟度和监视和自动化，但应该从一开始就希望最大程度地提高可靠性。 |
| 避免复杂性 | 在设计解决方案和所有操作流程时避免不必要的复杂性，以提高可靠性和管理效率，从而最大程度地降低故障的可能性。 |
性能效率
可持续性能和可伸缩性 - 针对端到端解决方案的可伸缩性进行设计，没有性能瓶颈。
| 设计原则 | 注意事项 |
|---|---|
| 横向扩展设计 | 横向扩展是一个概念，侧重于系统通过水平增长响应需求的能力。 这意味着，随着流量的增长，将并行添加更多的资源单位，而不是增加现有资源的大小。 系统能够通过缩放单元处理预期和意外的流量增长，通过进一步降低单个资源故障的影响，对整体性能和可靠性至关重要。 |
| 超大规模自动化 | 整个解决方案中的缩放操作应完全自动化，以最大程度地减少流量意外或预期增加对性能和可用性的影响，确保了解执行缩放操作所需的时间，并与应用程序运行状况模型保持一致。 |
| 持续验证和测试 | 应在 CI/CD 进程中执行自动测试，以推动对每个应用程序更改进行持续验证。 应包含针对具有同步混沌试验的性能基线的负载测试，以验证现有阈值、目标和假设，并帮助快速识别复原能力和可用性的风险。 此类测试应在过渡和测试环境中执行，也可以在开发环境中进行。 针对生产环境运行一部分测试也很有用，尤其是与蓝/绿部署模型结合使用，以在接收生产流量之前验证新的部署标记。 |
| 使用托管计算服务减少开销 | 通过将基础结构部署和维护转移到托管服务提供商，使用托管计算服务和容器化体系结构可显著减少设计、操作和缩放应用程序的持续管理和操作开销。 |
| 基线性能和识别瓶颈 | 使用来自每个系统组件的详细遥测数据进行性能测试，可以识别系统中的瓶颈，包括需要相对于其他组件进行缩放的组件，并且应将此信息合并到容量模型中。 |
| 模型容量 | 容量模型允许规划给定负载配置文件的资源规模级别，并另外公开系统组件彼此之间的性能，从而启用系统范围的容量分配规划。 |
卓越运营
设计运营 - 经过精心设计，持续进行可靠且自信的运营管理。
| 设计原则 | 注意事项 |
|---|---|
| 松散耦合组件 | 松散耦合可实现应用程序组件的独立和按需测试、部署和更新，同时最大程度地减少支持、服务、资源或审批的团队间依赖关系。 |
| 自动生成和发布过程 | 完全自动化的生成和发布过程可减少摩擦并提高部署更新的速度，实现跨环境的可重复性和一致性。 自动化缩短了开发人员推动更改的反馈循环，从而获取有关代码质量、测试覆盖率、复原能力、安全性和性能的见解，从而提高开发人员的工作效率。 |
| 开发人员敏捷性 | 持续集成和持续部署 (CI/CD) 自动化允许使用生命周期与关联功能分支的生命周期相关的短期开发环境，从而提升开发人员的灵活性，并在工程周期内尽早推动验证，以最大程度地降低 bug 的工程成本。 |
| 量化操作运行状况 | 所有组件和资源的完整诊断检测可实现日志、指标和跟踪的持续可观测性，但也有助于运行状况建模，从而根据可用性和性能要求量化上下文中的应用程序运行状况。 |
| 演练恢复和练习失败 | 业务连续性 (BC) 和灾难恢复 (DR) 规划和实践演练至关重要，应经常进行，因为学习可以迭代地改进计划和过程，以在计划外停机时最大限度地提高复原能力。 |
| 接受持续运营改进 | 优先考虑系统和用户体验的例行改进，使用运行状况模型通过反馈机制了解和衡量运营效率，使应用程序团队能够以迭代方式了解和解决差距。 |
安全性
始终安全 - 设计端到端安全性，以保持应用程序稳定性并确保可用性。
| 设计原则 | 注意事项 |
|---|---|
| 监视整个解决方案的安全性并计划事件响应 | 关联安全和审核事件，为应用程序运行状况建模并识别活动威胁。 使用安全信息和事件管理 (SIEM) 跟踪工具建立自动和手动过程以响应事件。 |
| 针对潜在威胁建模和测试 | 确保适当的资源强化，并建立识别和缓解已知威胁的过程，使用渗透测试来验证威胁缓解，以及静态代码分析和代码扫描。 |
| 标识和保护终结点 | 通过安全功能和设备（例如防火墙或 Web 应用程序防火墙）监视和保护内部和外部终结点的网络完整性。 使用行业标准方法来防范常见攻击途径，例如分布式拒绝服务 (DDoS) 攻击，如 SlowLoris。 |
| 防范代码级漏洞 | 识别并缓解代码级漏洞（如跨站点脚本或 SQL 注入），并将安全修补纳入代码库所有部分（包括依赖项）的操作生命周期。 |
| 自动化并使用最小特权 | 推动自动化以最大程度地减少人工交互的需求，并在应用程序和控制平面上实现最低特权，以防止数据外泄和恶意执行组件场景。 |
| 对数据进行分类和加密 | 根据风险对数据进行分类，并应用行业标准静态加密和传输中加密，确保密钥和证书安全存储并正确管理。 |
成本优化
引入更高的可靠性时，存在明显的成本权衡，应在工作负载要求上下文中仔细考虑。
最大程度地提高可靠性可能会影响解决方案的总体财务成本。 例如，资源重复以及跨区域分配资源以实现高可用性会产生明显的成本影响。 为了避免成本过高，请不要过度设计或过度预配超出相关业务要求。
此外，在基本可靠性概念（如采用基础结构即代码、部署自动化和混沌工程）中，工程投资会增加成本。 这在时间和精力方面都付出了代价，可以投入到其他地方来提供新的应用程序功能和特性。
云原生设计
Azure 本机托管服务 - Azure 本机托管服务具有优先级，因为其管理和操作开销较低，并且与应用程序堆栈中的一致配置和检测紧密集成。
路线图一致性 - 将即将推出的全新和改进的 Azure 服务功能纳入正式发布 (正式发布) ，以保持与 Azure 的领先优势保持密切联系。
采用预览版功能并缓解已知差距 - 虽然正式发布 (GA) 服务优先支持性，但会积极探索 Azure 服务预览以快速整合，向 Azure 产品组提供技术和可操作的反馈，以解决差距。
Azure 登陆区域对齐 - 可在 Azure 登陆区域内 部署，并与 Azure 登陆区域设计方法保持一致，但也完全正常运行，可在登陆区域外的裸露环境中部署。
后续步骤
查看与任务关键型工作负载相关的跨领域关注点。