你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn

任务关键型工作负荷的设计原则

任务关键型设计方法由五项关键设计原则为基础,这些原则是跨关键设计领域的后续设计决策的指南针。 我们强烈建议你熟悉这些原则,以更好地了解它们的影响和与不遵守相关的权衡。

显示五项任务关键型设计原则的关系图:可靠性、性能效率、卓越运营、安全性和成本优化以具有相互关联的循环模式排列。

可靠性

设计原则 注意事项
主动/主动设计 若要最大程度地提高可用性并实现区域容错,应尽可能使用主动/主动部署模型将解决方案组件分布在多个可用性区域和 Azure 区域。
爆炸半径减少和故障隔离 在 Azure 等高度分布式的超大规模云环境中,无法避免故障。 通过预测故障和相关影响,从各个组件到整个 Azure 区域,可以采用复原方式设计和开发解决方案。
观察应用程序运行状况 在缓解影响应用程序可靠性的问题之前,必须先检测和理解它们。 通过监视应用程序相对于已知正常状态的作,可以检测甚至预测可靠性问题,从而快速采取补救措施。
驱动自动化 应用程序停机的主要原因之一是人为错误,无论是部署测试不足的软件还是配置不当。 为了尽量减少人为错误的可能性和影响,在云解决方案的各个方面努力实现自动化以提高可靠性至关重要:自动化测试、部署和管理。
自我修复设计 自我修复描述了系统通过连接到解决方案中故障模式的预定义修正协议自动处理故障的能力。 这是一个高级概念,它要求在监视和自动化方面具有较高的系统成熟度,但应该是从一开始就实现可靠性最大化的愿望。
避免复杂性 在设计解决方案和所有作流程时避免不必要的复杂性,以提高可靠性和管理效率,尽量减少故障的可能性。

性能效率

设计原则 注意事项
横向扩展设计 横向扩展是一个概念,侧重于系统通过水平增长应对需求的能力。 这意味着,随着流量的增长,将并行添加更多资源单元,而不是增加现有资源的大小。 一个系统通过缩放单元来处理预期和意外的流量增加,对于整体性能和可靠性至关重要,因为这样可以进一步减少单个资源故障的影响。
超大规模自动化 整个解决方案中的伸缩操作应完全自动化,以最大程度地减少流量意外或预期增加对性能和可用性的影响,确保理解并掌握执行伸缩操作所需的时间,并与应用程序健康模型保持一致。
持续验证和测试 应在 CI/CD 进程中执行自动测试,以推动每个应用程序更改的持续验证。 应包含针对具有同步混沌试验的性能基线的负载测试,以验证现有阈值、目标和假设,并帮助快速识别复原能力和可用性的风险。 此类测试应在过渡和测试环境中进行,也可以在开发环境中(可选)进行。 还可以对生产环境运行一部分测试,特别是结合蓝/绿部署模型在接收生产流量之前验证新的部署标记。
使用托管计算服务减少开销 使用托管计算服务和容器化体系结构,可以显著减少设计、运营和扩展应用程序的持续管理和运营开销,因为基础设施的部署和维护由托管服务提供商负责。
建立基线性能并确定瓶颈 通过每个系统组件的详细遥测数据进行性能测试,可以识别系统中的瓶颈,包括需要相对其他组件进行调整的组件,此信息应被整合到容量模型中。
模型容量 容量模型可以为给定的负载配置文件规划资源规模,并且展示系统组件之间的互动表现,从而实现系统整体容量分配规划。

卓越运营

设计原则 注意事项
松散耦合组件 松散耦合可实现应用程序组件的独立按需测试、部署和更新,同时最大程度地减少团队间依赖项以支持、服务、资源或审批。
自动执行生成和发布过程 完全自动化的生成和发布过程可减少摩擦并提高部署更新的速度,从而在环境中实现可重复性和一致性。 自动化缩短了开发人员推动更改的反馈循环,从而获取有关代码质量、测试覆盖率、复原能力、安全性和性能的见解,从而提高了开发人员的工作效率。
开发人员敏捷性 通过持续集成和持续部署(CI/CD)自动化,可以使用与关联功能分支相关的生命周期的短期开发环境,从而在工程周期中尽早促进开发人员敏捷性并推动验证,以最大程度地降低 bug 的工程成本。
量化操作健康 所有组件和资源的完整诊断检测可实现日志、指标和跟踪的持续可观测性,但也有助于运行状况建模,以量化上下文中的应用程序运行状况,以满足可用性和性能要求。
排练恢复和练习失败 业务连续性(BC)和灾难恢复(DR)规划和实践演练至关重要,应经常进行,因为学习可以迭代改进计划和过程,以在计划外停机时最大程度地提高复原能力。
接受持续运营改进 优先改进系统和用户体验,使用运行状况模型通过反馈机制了解和衡量运营效率,使应用程序团队能够以迭代方式理解和解决差距。

安全

设计原则 注意事项
监视整个解决方案的安全性并计划事件响应 将安全和审核事件关联到对应用程序运行状况进行建模并识别活动威胁。 使用安全信息和事件管理(SIEM)工具来跟踪事件,建立自动化和手动过程以响应事件。
针对潜在威胁建模和测试 确保适当的资源强化和建立过程来识别和缓解已知威胁,使用渗透测试来验证威胁缓解,以及静态代码分析和代码扫描。
识别和保护终结点 通过安全功能或设备(如防火墙或 Web 应用程序防火墙)监视和保护内部和外部终结点的网络完整性。 使用行业标准方法来防范分布式拒绝Of-Service(DDoS)攻击(如 SlowLoris)等常见攻击途径。
防范代码级漏洞 识别和缓解代码级漏洞,例如跨站点脚本或 SQL 注入,并将安全修补纳入代码库的所有部分(包括依赖项)的作生命周期。
自动执行和使用最低权限 推动自动化,最大程度地减少人工交互的需求,并在应用程序和控制平面上实现最低特权,以防止数据外泄和恶意执行组件方案。
对数据进行分类和加密 根据风险对数据进行分类,并在静态和传输中应用行业标准加密,确保密钥和证书安全存储并正确管理。

成本优化

与引入更高的可靠性相关的成本权衡明显,在工作负荷要求上下文中应仔细考虑这种权衡。

最大程度地提高可靠性可能会影响解决方案的整体财务成本。 例如,重复资源和跨区域分配资源以实现高可用性具有明显的成本影响。 为了避免超额成本,请不要过度设计或过度预配超出相关业务需求。

此外,与工程方面的投资相关的基本可靠性概念带来了额外的成本,例如采用基础结构即代码、部署自动化以及自动化测试。 这在时间和精力方面都付出了代价,这些时间与精力都可能投入到其他位置,以提供新的应用程序功能和功能。

后续步骤

设计区域是相互关联的,因此一个区域中的更改可能会影响其他区域。 首先,从业务最关键的领域开始,然后查看注意事项和建议,以了解你的选择如何在整个体系结构中创建权衡。