1. Azure性能与容量治理全景
在云上运行工作负载，性能问题往往不是“服务器不够快”这么简单。Azure 把计算、存储、网络、数据库等能力拆成可弹性伸缩的资源，性能由资源配置、服务层级、区域拓扑、并发模式与配额共同决定；容量则决定这些资源在业务峰值到来时是否仍然够用。性能与容量治理的目标，是让系统在可接受的用户体验下，以可预测的成本稳定运行，而不是在故障发生后被动扩容。
一、性能、容量与治理的边界
性能关注“单次请求或单位任务有多快、多稳”，典型指标是延迟、吞吐、错误率和饱和度。容量关注“在给定负载下还能承载多少”，典型指标是并发连接数、队列深度、存储 IOPS、数据库 DTU/vCore 余量、配额使用率。治理则是把两者纳入持续管理：定义目标、采集数据、设定阈值、触发扩缩容或优化、复盘成本。
三者关系可以用一个简单判断来理解：性能是“当前跑得好不好”，容量是“还能不能继续跑”，治理是“如何让它一直跑得好且花得值”。如果只盯 CPU 使用率，可能忽略存储限流；如果只看平均延迟，可能掩盖 P95 长尾。因此治理必须同时覆盖资源层、应用层和业务层。
二、成本与性能的权衡
Azure 的计费模型决定了性能与成本并非线性关系。以虚拟机为例，同一系列中 vCPU 和内存增加，单价上升，但单位算力成本可能下降；预留实例和节省计划能降低长期成本，却要求容量承诺。存储方面，Premium SSD 提供更低延迟和更高 IOPS，但每 GB 成本高于标准 HDD；Blob 的热、冷、归档层则用访问延迟换取存储单价下降。
权衡的核心不是“选最贵”或“选最便宜”，而是把性能目标翻译成资源规格与层级。例如一个内部报表 API，业务可接受 P95 延迟 800ms，那么不必为它配置最高档数据库；而一个支付回调接口要求 P99 小于 200ms，就需要预留足够 vCore、启用加速网络，并避免跨区域同步写入。常见做法是：先定义 SLO，再选最小可满足规格，最后用监控验证是否达标，而不是反过来先买大规格再找用途。
三、治理框架：从目标到闭环
Azure 性能与容量治理可以落成一个五段闭环：目标定义、可观测性、容量评估、弹性策略、成本复盘。目标定义阶段，把业务语言转成技术指标，例如“订单提交 95% 在 1 秒内完成”。可观测性阶段，用 Azure Monitor、Application Insights、Log Analytics 采集指标、日志和分布式追踪。容量评估阶段，结合历史趋势和压测结果，计算峰值余量。弹性策略阶段，用 VMSS、App Service 自动缩放、AKS HPA/Cluster Autoscaler、Azure SQL 无服务器等实现按需伸缩。成本复盘阶段，用 Cost Management 和 Advisor 识别低利用率资源、闲置磁盘和过期预留。
这个闭环的关键在于“可观测性”不是只开监控，而是把指标与业务结果关联。例如 Application Insights 中的依赖调用失败率，要能对应到某个存储账户的限流；Azure Monitor 中的 VM 磁盘队列长度，要能解释应用日志中的超时。否则数据很多，决策仍然靠猜。
四、关键指标：从资源到业务的分层
治理指标不能只停留在资源层。资源层指标（CPU、内存、磁盘 IOPS、网络吞吐、配额使用率）用于发现瓶颈；应用层指标（请求速率、并发数、P50/P95/P99 延迟、依赖失败率、重试次数）用于判断用户体验；容量层指标（峰值余量、数据库 DTU/vCore 消耗、存储限流、扩展触发次数）用于预测何时需要扩容；业务层指标（订单成功率、用户可感知延迟、单位请求成本、SLO 达成率）用于验证治理是否真正产生价值。
以 Azure SQL 为例，如果只看 CPU 使用率，可能忽略 log_write_wait_ms 或 PAGEIOLATCH 等待类型；如果只看 DTU 百分比，可能忽略连接池耗尽。更有效的做法是同时观察：资源饱和度（CPU、IO、内存）、等待类型（锁、日志写入、网络）、请求延迟分布（P95/P99）和错误率。当 P95 延迟上升且等待类型集中在日志写入时，优先考虑提升数据库层级或优化写入事务，而不是盲目增加应用实例。
五、一个可执行的容量判断示例
假设某 Web API 部署在 App Service 上，业务要求 P95 延迟不超过 500ms，当前观测到峰值并发 120，平均响应时间 180ms，P95 为 420ms，CPU 峰值 68%，内存峰值 72%。从数据看，当前容量尚有余量，但 P95 已接近目标。此时可以计算：若并发增长 30% 到 156，按线性估算 P95 可能达到 546ms，超出 SLO。治理动作不是立即升级套餐，而是先确认瓶颈：若 CPU 和内存均未饱和，可能是下游数据库或外部依赖导致，应先优化查询或增加缓存；若 CPU 在并发上升时快速逼近 90%，则考虑启用自动缩放规则，将最小实例数从 2 调到 3，并设置 CPU 大于 70% 持续 10 分钟触发扩容。
这个示例说明：容量判断需要目标、当前值、趋势和瓶颈定位四要素。缺少任何一项，扩容都可能变成成本浪费或无效操作。
六、治理落地的三个习惯
- 先定义 SLO，再谈规格。没有目标就无法判断“够不够”，也无法判断“贵不贵”。
- 把监控指标与业务结果关联。每个关键告警都应能回答“影响哪些用户、哪个功能、多严重”。
- 定期做成本与容量复盘。至少每月检查一次低利用率资源、过期预留、闲置磁盘和未使用的公网 IP，避免治理只关注性能而忽略成本。
Azure 性能与容量治理不是一次性项目，而是持续循环。理解性能与容量的区别、掌握成本与性能的权衡方法、建立从目标到复盘的治理框架，并围绕资源、应用、容量、业务四层指标持续观察，才能让工作负载在业务增长时保持稳定，在成本压力下保持理性。