你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
对分布式应用程序进行性能优化
在此系列中，我们将演练数个云应用程序方案，介绍开发团队如何使用负载测试和指标来诊断性能问题。 这些文章基于我们在开发示例应用程序时执行的实际负载测试。 GitHub 上提供每个方案的代码。
方案：
什么是性能？
性能通常使用吞吐量、响应时间和可用性进行衡量。 性能目标应该基于业务运营。 面向客户的任务可能有比操作任务（例如生成报表）更严苛的要求。
请定义一个服务级别目标 (SLO)，后者用于为每个工作负荷定义性能目标。 为实现此目标，通常需要将性能目标细分成一组关键性能指标 (KPI)，例如：
- 特定请求的延迟或响应时间
- 每秒执行的请求数
- 系统生成异常的速率。
性能目标应该明确包含目标负载。 另外，并非所有用户都会获得完全相同的性能级别，即使是在同时访问系统并完成相同的工作。 因此，SLO 应以百分比形式拟订。
例如，SLO 可能为：“在 90% 的情况下，客户端请求会在 500 毫秒内获得响应，负载高达 25,000 次请求/秒。”
对分布式系统进行性能优化的难点
诊断分布式应用程序中的性能问题可能极具挑战性。 下面是一些难点：
单个业务事务或操作通常涉及系统的多个组件。 可能难以获取单个操作的整体端到端视图。
资源的消耗跨多个节点。 若要获取一致性视图，需将日志和指标聚合到一个位置。
云提供弹性缩放。 自动缩放是一种用于处理负载峰值的重要方法，但也可能会掩盖潜在问题。 另外就是难以知道哪些组件需要缩放，以及何时缩放。
工作负载通常不会跨核心或线程进行缩放。 了解工作负载的要求并寻求更好的优化大小非常重要。 某一些大小提供了受约束的核心和禁用的超线程，以改进面向单核和每核心许可的工作负载。
级联故障可能导致根本问题所在位置的上游出现故障。 因此，问题的第一个信号可能出现在根源以外的其他组件中。
常规最佳做法
性能优化既是艺术也是科学，但我们可以通过系统方法让它更接近科学。 下面是一些最佳做法：
启用遥测来收集指标。 检测代码。 按有关监视的最佳做法操作。 使用关联跟踪，以便在一个事务中查看所有步骤。
监视 90/95/99 百分位值，而不仅仅是平均值。 平均值可能会掩盖离群值。 指标的采样率也很重要。 如果采样率过低，可能会漏掉表明存在问题的峰值或离群值。
一次解决一个瓶颈。 建立一个假设，然后一次更改一个变量，对假设进行测试。 去掉一个瓶颈以后，通常会在上游或下游出现另一个瓶颈。
错误和重试可能会对性能造成很大影响。 如果发现后端服务正在限制系统，请横向扩展或尝试优化使用情况（例如，通过优化数据库查询）。
查找常见的性能反模式。
查找并行化机会。 瓶颈的两种常见来源是消息队列和数据库。 两种情况都可以通过分片来解决。 有关详细信息，请参阅水平数据分区、垂直数据分区和功能数据分区。 查找可能表明读取或写入负载不均衡的热分区。
后续步骤
阅读性能优化方案