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

性能效率设计原则

性能效率是工作负载适应需求变化的能力。 工作负荷必须能够在 不影响用户体验的情况下处理负载增加。 相反， 当负载减少时，工作负荷必须节省其资源。 容量（指示 CPU 和内存) (资源可用性）是一个重要因素。

工作负荷设计不应仅依赖于预预配的容量，这可确保性能达到一定限制。 如果超出该限制，则工作负荷可能会出现性能问题，甚至遇到中断。 当负载低于该限制时，资源会继续不必要地运行，从而产生成本。

你需要一个全面的策略来维持一段时间内的性能目标。 在设计过程中，性能注意事项不应是事后考虑的问题，只有在生产中出现问题时才能解决。 相反， 应采用一种思维模式，即性能是设计早期阶段的关键考虑因素。 最初，无需任何特定性能目标即可生成系统。 但从那里，测试和衡量每个开发阶段的性能，以确保进度和有效性。 在整个过程中持续优化这些目标，并整合从生产中吸取的经验教训，可以提前显著缓解潜在问题。

这些设计原则有助于 构建管理资源容量的策略 ，以充分满足预期使用情况的业务需求。 此外，在非高峰时段减少浪费。 确定策略后，使用 “性能效率”清单巩固设计。

性能效率与有效使用工作负载资源有关。 如果没有良好的策略，你可能无法预测和满足用户需求。 你可能必须采用长期预测和预预配容量的方法，这不能让你充分利用云平台。

协商现实的性能目标

定义了预期的用户体验，并且有一个策略来根据预先建立的业务要求制定基准和衡量目标。

从性能角度来看，最好有明确定义的性能目标来启动设计过程。 若要设置这些目标，需要充分了解业务要求以及预期工作负荷将提供的服务质量。 与业务利益干系人协作定义期望。 确定对关键流的用户体验的可接受影响，而不是只关注技术指标。

存在循环依赖项。 无法度量尚未定义的内容，也不能在没有度量的情况下进行定义。 因此，在通过集体协议 实现可接受的阈值的满意定义之前，衡量工作负荷性能 也很重要。

性能和可靠性目标之间存在很强的相关性，这有助于确定性能、可用性和复原能力方面的服务质量。 如果没有明确的定义，衡量、警报和测试性能就很困难。 建立目标并通过一段时间的测试确定实际数字后，可以针对这些目标实现持续测试的自动化。

遵循在宏级别定义目标的最佳做法，即使它们是近似的或在某个范围内。

方法	优点
通过了解技术概念、使用可用的基础结构探索设计可能性，并使用具体试验的结果（如果可用）来准备有效的协商。 使用历史数据 了解使用模式和瓶颈。 从外部因素中获取见解，例如 市场分析、专家和行业标准的输入。	可以根据实际见解做出 明智的决策 。 性能目标侧重于基于可行、行业最佳做法和当前市场趋势的用户体验。
与业务所有者协作 ，了解用户承诺的质量和法规合规性（如果适用）。 在此阶段，请保持宽广的视角 ，避免深入了解细节。 根据投资明确 表示可接受的性能。 了解业务背景和 预期增长。	你将 避免做出 可能与业务目标不一致的假设。 它还在工作负载团队中提高清晰度和积极性。 具有有关功能和非功能性要求的业务上下文可能会发现其他 Azure Well-Architected 支柱中的设计更改， 并帮助你做出明智的权衡。 尽早定义参数有助于避免与以后潜在解决方案重新设计相关的成本。 它使你能够确保 性能目标涵盖未来的预测，以便使当前工作与长期目标保持一致。
在体系结构关系图中确定工作负荷流并设置流的优先级。 将每个流的性能容差定义为 从期望到不可接受的性能范围。 考虑路径的关键性、使用频率和体系结构强度，评估每个流的入口点和退出点。	通过确定流的优先级，可以将资源集中在对用户和业务成果影响最大的 关键领域 。 通过将系统分解为各个部分和依赖项，可以了解每个组件的功能及其对性能的影响。 你还会意识到潜在的问题。 它有助于建立性能基线并推动优化。
开始生成性能模型 考虑使用模式是显示季节性变化还是每日变化。 考虑业务的成本、运营和关键性。 使用行业标准量化指标 和聚合方法，例如使用百分位数。 评估业务约束施加的需求和供应预期 和限制。 纳入增长前景。	性能模型提供 对资源的最佳使用见解 ，并帮助进行战略规划。 行业标准有助于基准测试。 未来证明可确保性能目标保持相关性并能够适应变化。

设计以满足容量要求

提供足够的供应来满足预期需求。

主动衡量性能非常重要。 衡量性能涉及 测量基线 并初步了解哪些系统组件可能会带来挑战。 无需执行完整性能测试或通过精细优化即可实现此目的。 通过执行这些初始步骤，可以在开发生命周期的早期为有效的性能管理奠定基础。

将系统作为一个整体来检查，而不是专注于单个组件。 在此阶段避免微调。 进行精细的性能改进会导致其他方面的权衡。 随着整个生命周期的推进，开始用户验收测试或进入生产环境，可以快速确定哪些方面需要进一步优化。

方法	好处
评估已标识流的弹性需求。 了解可跨技术堆栈实现的设计模式，考虑应用程序以及基础计算层和数据层。	你可以对需要更多容量的现有组件以及需要额外组件来分配负载的区域 定义可伸缩性要求 。 你已注意到系统中的潜在瓶颈，并 设计补偿控件，例如添加缓存功能以降低延迟和系统负载。
跨技术堆栈选择合适的资源，这样就可以实现性能目标并与系统集成。 请考虑 满足可伸缩性要求的功能。 在资源分配和系统要求之间找到适当的平衡点，以便有效地处理意外的激增。	通过分析资源的不同功能，可以确保每个组件都有助于 系统的整体功能和性能。 可以利用自动触发缩放操作 的内置功能 。 正确调整资源大小可以满足需求的变化，而无需过度预配，从而节省成本。
根据需求和所选资源的功能进行容量规划，以丰富性能模型。 使用预测建模技术 来预测可能发生的可预测和意外更改的容量变化。 定义可转换为技术要求的性能目标。	可以在不过度预配的情况下 高效使用资源 并满足需求，从而避免不必要的成本。 你了解设计选择如何影响性能。
实现验证技术要求和设计选择的概念证明。	概念证明有助于 验证设计， 以确定系统是否可以满足性能目标以及这些目标是否现实。 根据预期的负载，可以验证预期容量是否满足性能目标。 此外，验证设计选项的成本影响。
记录性能测试策略。 包括测试计划的用例、不同方法和节奏。 定义性能测试计划概述的操作过程。 对计划中的测试用例进行会审并设置其优先级。 专注于提供对性能目标的有价值见解并协调容量规划的案例。	确保 测试系统的正确方面。 可以有效地分配资源，并以符合业务优先级和要求的方式进行测试。
记录性能监视策略。 评估每个已标识流的不同抽象级别的指标。	可以跟踪在整个开发周期中实现性能目标的 进度 。

实现和维持性能

在系统使用时以及随着系统的发展，防止性能下降。

开发不是一次性的。 这是一个持续的过程。 预期性能会随着功能的变化而发生变化。 用户模式和配置文件存在差异，甚至其他 Azure Well-Architected 支柱中的优化变化。 任何更改都可能导致工作负载资源紧张。

保护系统免受更改 的影响，使其不会在性能目标上滑回。 在开发过程中集成测试和监视。 在生产环境中使用实际负载测试系统的性能，并在生产之前通过自动测试模拟该负载。 在这两种情况下，都应有用于验证的监视做法。

在整个开发生命周期中， 在不同的阶段执行各种类型的测试。 在初始阶段，测试概念证明，以确保性能结果不会完全出乎意料。 随着开发的进展，进行 手动、低工作量的测试 以建立基准。 在生成阶段，开始开发 自动化的常规性能测试 ，用于评估测试计划中定义的延迟、压力级别、负载容量和其他特征。

监测必须是这项工作不可或缺的一部分，而不是孤立的工作。 可以看到 系统及其资源随时间推移的性能。然后，你可以微调它们以最大化其价值，并确保它们继续满足性能标准。

请记住，为了响应更改，性能目标会随时间而变化。 根据经过测试和监视的指标更新性能模型。 明确指示增加、减少或不影响流的性能。

始终准备好与业务利益干系人重新谈判和重置期望。

方法	好处
在 Azure Pipelines 中集成例行性能测试。 选择可以集成测试的管道。 相反，选择可以集成到管道中的测试工具。	自动测试节省时间并提供一致性，以便 更轻松地检测回归或改进。 这些项目允许持续监视一段时间内的任何偏差或偏移，以便保持一致的性能和质量。
将性能测试正式化为 可以批准或拒绝发布升级和最终部署到生产环境的质量入口。	这些检查点可确保 部署的每个阶段都满足所需的性能标准 ，然后再转到下一阶段。 检查点有助于防止意外的性能回归。 例如，如果性能明显低于预期，则可能会在改进之前阻止发布。
设置一个可重复的过程，用于监视 生产中的实际事务以及与性能目标偏差。 在生产中使用综合事务。 设置有关性能回归的监视警报。	你需要深入了解系统在无法通过测试模拟 的实际负载下的实际性能 。 然后，可以主动识别问题和改进领域，例如潜在的瓶颈、未充分利用的资源和其他问题。
仔细查看性能测试结果和监视数据，并对其进行优化，直到达到性能目标。 确定从这些评审派生的操作的优先级，并将其添加到积压工作，以便计划执行。	根据测试结果， 可以捕获和比较数据 并开始分析趋势。 优化工作由数据驱动。
培养专注于性能的编码技能。 具有体现性能驱动编码模式的编码标准。	没有性能问题的代码可以使 测试周期更高效 ，因为测试可以专注于更重要的问题。 编码模式有助于避免返工，并保持编码风格一致。
解决使用量增加、功能更改和数据随时间推移累积以维持性能时的性能侵蚀问题。 如果微调仅带来短期好处，请重置预期并建立新目标。	在降级发展成对用户体验产生负面影响的问题之前，可以 保留性能状态 ，超出可接受的范围。 更改目标会重置性能模型，你不会浪费时间来优化已达到其容量的系统。

通过优化提高效率

在定义的性能目标内提高系统效率，以增加工作负载价值。

在初始阶段设置的目标基于合理的用户体验级别，考虑到各种约束。 应 重新评估和调整目标，以进一步增强体验。 为了进一步增强体验，它需要清楚地了解系统的使用方式、它是如何演变的，以及平台或技术是如何随时间变化的。 监视、优化、测试和部署的周期是一个持续的过程。

效率优化工作允许工作负载以较低的资源消耗工作。 它们可能会导致工作负荷处于过度预配状态，并具有备用容量。 使用该容量来提高系统的可靠性。 消除容量以提高系统成本。 或者重新调整容量的用途，以支持现有资源上的新产品功能。

当系统提高效率时，请抓住机会设置和维护新的性能目标。

方法	好处
为性能优化分配专用周期 ，以解决功能领域的非功能要求和优化。 此优化的目标是资源、代码、数据保留、数据库查询等。	可以 构建性能驱动的优化文化。 让团队负责主动监视性能模式，并微调应用程序。
使用新的设计模式和组件来增强体系结构，这些模式和组件可以提高性能，这是你以前由于时间或预算有限而没有考虑的。	新的设计和组件可以优化系统， 从而提供更好的用户体验。 例如，可以使用缓存或添加内容分发网络组件。 它还可以带来长期的成本效益。
使用监视工具来分析历史趋势 ，并确定从性能优化工作中获益最大的流和代码实现路径。 为此，我们建议 (APM) 工具和探查器进行应用程序性能监视。 确定系统中的操作热路径和其他潜在瓶颈。	确定反复出现的问题区域后，团队可以 专注于收益最高的区域。
了解最新技术，随时了解 可提高性能的技术创新。 利用为依赖框架和库发布的新版本。 同样，在更新和修补平台资源时，请使用平台资源的新功能。	采用新技术通常是 寻找改进机会的激励因素。 通过这些更新，过去可能速度较慢的代码可能会变快。 你还希望了解某些更新对性能有何负面影响。

后续步骤

性能效率清单