1. 课程导入与全景认知
在云上运行系统，性能问题往往不是“服务器不够快”这么简单。一个典型的电商大促场景中，应用响应时间从 200ms 恶化到 2s，可能同时涉及 EC2 实例的 CPU 积分耗尽、RDS 连接池被打满、ElastiCache 命中率骤降、以及 Auto Scaling 策略滞后于流量爬升。如果只盯着单一服务调优，很容易按下葫芦浮起瓢。这正是本课程要解决的核心问题：把性能优化与容量治理当作一个跨服务的系统工程来对待。
先明确两个概念。性能优化关注的是“在给定资源下，如何让请求更快、更稳、更省”，它的度量对象是延迟、吞吐、错误率和资源利用率；容量治理关注的是“资源供给如何随负载变化而伸缩，既不长期闲置也不在峰值崩溃”，它的度量对象是容量水位、伸缩响应时间、成本与冗余度。两者是一体两面：性能优化决定了单位资源能承载多少负载，容量治理决定了需要准备多少资源。只做性能优化不做容量治理，会在流量突增时失效；只做容量治理不做性能优化，则是在用更多机器掩盖低效代码。
本课程的核心目标：建立“可观测 → 定位瓶颈 → 优化 → 容量规划 → 验证 → 成本收敛”的闭环能力，而不是记住零散的调优参数。
为什么 AWS 上的性能与容量问题特别棘手？第一，共享责任模型意味着 AWS 负责云本身的容量，而实例规格选择、伸缩策略、连接管理、缓存设计由用户负责，边界容易混淆。第二，服务间耦合使得瓶颈会转移：给 Web 层加机器后，压力可能立刻转移到数据库。第三，按需计费让“多开机器”看似没有成本，但账单会滞后暴露浪费。第四，弹性本身有延迟，EC2 从触发到可用通常需要数十秒到数分钟，这段时间的流量必须由预留余量或缓冲层承接。
下面这张图给出了本课程的知识全景：从可观测数据出发，经过瓶颈定位，分别进入性能优化与容量治理两条主线，最终汇入成本与稳定性验证，并形成反馈闭环。
围绕这张全景图，课程按六个阶段展开。第一阶段建立可观测基础，学会用 CloudWatch 指标和 X-Ray 追踪把“慢”拆解成可量化的分段延迟；第二阶段训练瓶颈定位能力，重点掌握“扩容后瓶颈转移”的判断方法；第三阶段进入性能优化，覆盖计算、缓存、数据库、异步化四类高频手段；第四阶段进入容量治理，讨论水位设定、伸缩策略、计费模型组合；第五阶段做验证与成本收敛，用压测和伸缩演练确认方案有效；第六阶段是贯穿始终的反馈闭环。
学习路径上，建议按“先观测、后优化、再治理”的顺序推进。很多初学者一上来就调参数，结果因为没有基线数据，无法判断改动是否有效。正确的做法是先采集一段稳定期的指标作为基线，例如记录某 API 在正常负载下的 P95 延迟为 180ms、EC2 CPU 平均利用率 35%、RDS 连接数峰值 120。有了基线，任何优化都能用同一口径对比。
实战环境准备建议：准备一个独立的 AWS 测试账号或沙箱环境，避免影响生产。至少开通 EC2、RDS（可用最小规格）、ElastiCache、CloudWatch、Auto Scaling、Application Load Balancer 六项服务。为控制成本，测试实例优先选用 t3.micro 或 t4g.small，数据库选用 db.t3.micro，并在实验结束后及时停止或删除资源。建议开启 CloudWatch 的详细监控（1 分钟粒度），否则默认 5 分钟粒度会掩盖短时峰值。
还需要建立一个重要的认知：性能与容量没有“最优解”，只有“匹配当前业务目标的解”。一个内部报表系统可以接受 3 秒延迟，而一个支付接口必须控制在 200ms 以内，两者的优化投入完全不同。因此本课程在每个环节都会强调先明确 SLO（服务等级目标），再决定优化力度。例如把 SLO 定义为“P99 延迟 ≤ 500ms，可用性 ≥ 99.9%”，那么所有优化和容量决策都围绕这个目标展开，超出目标的过度优化就是浪费。
最后给出一个贯穿全课程的判断原则：先测量，再假设，后改动，必验证。任何一次调优或扩容，都应该能回答三个问题——改之前的数据是什么？改动的预期影响是什么？改之后数据是否真的变好了？如果这三个问题答不上来，说明这次改动只是“感觉上更快了”，而不是工程意义上的优化。接下来的章节将围绕这条原则，逐层展开具体的方法、工具与实战案例。