1. 性能优化全景：为什么需要全链路优化？

大家好，我是这门课的主讲。在开始之前，我想先问一个问题：你负责的 API，真的「快」吗？

很多团队跟我说，他们的接口平均响应时间只有 20 毫秒，看起来很快。但一到双十一大促，用户就开始投诉「转圈圈」。为什么？因为平均延迟会骗人。我见过太多这样的案例了——平均 20ms，但 TP99 却高达 2 秒。这意味着 1% 的请求要等 2 秒，对于千万级日活的系统，那就是每天几万人在骂娘。

所以，性能优化不是拍脑袋的事。它需要一套完整的衡量体系，和一个全局的视角。今天这一章，我们就来搭好这个「全景图」。

1.1 为什么不能只优化一个点？

说白了，一个 API 请求从客户端发出，到拿到结果，中间要经过 DNS 解析、网络传输、负载均衡、网关、业务服务、缓存、数据库…… 这一整条链路上，任何一个环节慢了，用户感知到的就是「慢」。

我曾经接手过一个项目，业务团队花了两个月优化数据库查询，把单次查询从 500ms 降到了 10ms。结果上线后，用户反馈根本没变化。一查才发现，问题出在客户端的 HTTP 连接池配置上——每次请求都在重建连接，握手耗时占了总时间的 80%。

这就是典型的「局部最优，全局失效」。你想想看，如果只盯着一个点，很容易陷入这种困境。全链路优化的核心思想就是：从用户端到数据端，端到端地审视每一个环节。

1.2 API 性能的衡量指标

聊优化之前，得先知道怎么「量」。我习惯用四个核心指标来给 API 做体检。它们各有侧重，缺一不可。

指标	定义	关注点	我的经验
QPS	每秒查询数（Queries Per Second）	系统的吞吐能力，能扛多大流量	QPS 上去了，延迟往往会跟着涨，要一起看
TP99	99% 的请求在多少毫秒内完成	长尾延迟，用户体验的「痛点」	我一般优先优化 TP99，而不是平均值
延迟	请求从发出到收到响应的总耗时	用户直观感受，快就是快	要区分平均延迟、P50、P99、P999
吞吐量	单位时间内成功处理的请求数	系统的处理能力，跟 QPS 类似但更侧重总量	吞吐量上不去，加机器也不一定有用

举个例子。一个接口平均延迟 50ms，看起来不错。但 TP99 是 1000ms。这意味着什么？100 个请求里，有 1 个要等 1 秒。如果你的系统每天处理 1 亿请求，那就是 100 万次糟糕体验。用户不会管你平均是多少，他只记得自己「卡了一下」。

1.3 全链路优化的核心思想

全链路优化，说白了就是一句话：找到整个请求路径上最慢的那个环节，把它干掉，然后找下一个。

但实际操作起来，没那么简单。我把它拆成三个核心思想：

• 端到端视角： 从用户点击按钮，到数据落盘，再到响应返回，全程可观测。不能只看服务端。
• 分层治理： 每一层都有自己的优化手段，不能混为一谈。网关的问题用网关的手段，DB 的问题用 DB 的手段。
• 量化驱动： 没有数据，就没有优化。每次改动前先测基线，改完再测对比。凭感觉优化，大概率白干。

我记得有一次，团队里一个小伙子在代码里加了一堆缓存，觉得肯定能提速。结果上线后 TP99 反而涨了。一查，缓存穿透导致大量请求直接打到数据库，把 DB 打挂了。这就是典型的「没有量化，盲目优化」。

1.4 分层策略：从客户端到数据层

我把全链路分成五层。每一层都有它的优化重点。下面这张图，就是我这门课的整体框架。

嗯，这张图我画了很久。每一层都是一个独立的优化战场，但它们又互相影响。比如，你在数据层做了读写分离，查询快了，但业务层的线程池可能就成了新瓶颈。这就是为什么需要「全链路」的视角。

1.5 避坑指南：新手最容易犯的三个错误

我带过不少团队，也踩过不少坑。下面这三个，是我见过最普遍的：

• 只看平均值： 平均延迟 50ms，TP99 2000ms。这种系统，用户感知就是「卡」。我建议把 TP99 作为核心优化目标。
• 盲目加缓存： 缓存不是银弹。不加监控就上缓存，很容易出现缓存穿透、数据不一致。我曾经见过一个系统，缓存命中率只有 20%，还占了一大堆内存。
• 忽略客户端： 很多后端工程师觉得性能问题都是服务端的事。其实，客户端的连接池、超时设置、重试策略，对整体延迟影响巨大。我见过一个案例，客户端超时设了 30 秒，服务端其实 200ms 就返回了，但用户等的是 30 秒——因为客户端在傻等。

1.6 本章小结

这一章，我们搭好了全链路优化的「世界观」。记住几个关键点：

• 性能优化必须端到端，不能只看一个点。
• 衡量指标用 QPS、TP99、延迟、吞吐量，别被平均值骗了。
• 分层治理，每一层有每一层的玩法。
• 量化驱动，没有数据就没有优化。