2、性能指标与监控体系：QPS、TPS、延迟、吞吐量、Apdex、全链路监控
聊性能调优，第一个绕不开的话题就是——你到底要优化什么？
我见过不少团队，一上来就堆机器、改配置，忙活半天，结果连核心指标都没对齐。说白了，你连「快」的标准都没定义清楚，怎么知道优化到位了？
这一章，咱们就把这些基础指标掰开揉碎。你搞懂了它们，监控体系才能搭得稳。
2.1 QPS 与 TPS：别傻傻分不清
这两个词高频出现，但很多人混着用。我习惯这么区分：
- QPS（Queries Per Second）：每秒查询数。偏重读场景，比如一次 GET 请求。
- TPS（Transactions Per Second）：每秒事务数。偏重写场景，或者一个完整业务操作。
举个例子。你打开一个电商详情页，浏览器发了一个请求，后端查了缓存、查了数据库，返回数据。这算一次 QPS。但如果你下单，从扣库存、生成订单、到支付回调，这一整套才算一次 TPS。
核心区别：QPS 关注单次请求，TPS 关注完整业务链路。
我在项目中遇到过一个问题：某个接口 QPS 很高，但 TPS 很低。一查，原来是前端疯狂轮询订单状态，每次轮询算一次 QPS，但真正的下单事务没几个。这其实是个设计问题，不是性能问题。
我的习惯：压测时，先看 TPS 是否达标，再看 QPS 是否合理。如果 TPS 上不去，光堆 QPS 没意义。
2.2 延迟：用户感知的「慢」
延迟，就是用户从发出请求到收到响应的时间。我把它拆成三段：
- 网络延迟：数据在网络上传输的时间。
- 排队延迟：请求在队列里等着被处理的时间。
- 服务延迟：实际处理请求的时间。
你想想看，用户说「慢」，到底是哪一段慢了？
我曾经排查过一个案例：接口平均延迟 200ms，但偶尔飙到 5 秒。查了半天，发现是某个线程池满了，请求在队列里排了 4 秒多。这就是典型的排队延迟问题。
注意：不要只看平均延迟。P99 延迟才是用户体验的真相。P99 延迟 1 秒，意味着 1% 的用户要等 1 秒以上。对于高并发系统，这 1% 可能就是你的核心用户。
2.3 吞吐量：系统能扛多少
吞吐量，说白了就是系统在单位时间内能处理多少请求。单位可以是 QPS，也可以是 TPS，或者每秒处理的字节数。
吞吐量和延迟的关系，有点像跷跷板。你压得太狠，吞吐量上去了，延迟必然飙升。我习惯用「利特尔法则」来估算：
吞吐量 = 并发数 / 平均延迟举个例子。你的系统平均延迟是 100ms，并发数是 100，那理论吞吐量就是 1000 QPS。但实际往往达不到，因为还有锁竞争、上下文切换这些开销。
我的经验：压测时，先固定并发数，观察吞吐量和延迟的变化。找到那个「拐点」——再增加并发，吞吐量不涨了，延迟开始飙升。那个点就是系统的极限。
2.4 Apdex：用户满意度量化
Apdex（Application Performance Index）是一个很有意思的指标。它不直接看快慢，而是看用户满不满意。
它的算法很简单：
- 设定一个「满意」的阈值 T（比如 500ms）。
- 响应时间 ≤ T 的请求，算「满意」。
- 响应时间在 T 到 4T 之间的，算「容忍」。
- 响应时间 > 4T 的，算「失望」。
然后算一个分数：
Apdex = (满意请求数 + 容忍请求数 / 2) / 总请求数分数范围 0 到 1。0.94 以上算优秀，0.85 以上算良好。
我为什么推荐这个指标？因为它更贴近业务。你想想看，P99 延迟是 800ms，但 Apdex 是 0.98，说明大部分用户还是满意的。反过来，P99 延迟只有 200ms，但 Apdex 只有 0.7，说明你的阈值设得太低了，用户其实觉得慢。
避坑指南：我曾经把 T 设成 100ms，结果 Apdex 一直很低。后来发现，用户对某些操作（比如导出报表）的容忍度其实很高。所以 T 值要根据业务场景来定，别一刀切。
2.5 全链路监控：别让问题藏起来
微服务架构下，一个请求要经过十几个服务。出问题了，你都不知道是哪个环节慢。
全链路监控就是干这个的。它给每个请求分配一个 Trace ID，然后记录它经过的每一个服务、每一次调用、每一段耗时。
我常用的工具是 Zipkin 和 Jaeger。它们都基于 Google 的 Dapper 论文。核心思路就三点：
- Trace：一次完整的请求链路。
- Span：链路中的一次调用（比如调用数据库、调用下游服务）。
- Annotation：Span 中的关键事件（比如开始时间、结束时间）。
举个例子，一个下单请求的 Trace 可能是这样的：
Trace ID: abc123
├── Span A: 网关 (耗时 10ms)
│ ├── Span B: 订单服务 (耗时 200ms)
│ │ ├── Span C: 调用库存服务 (耗时 80ms)
│ │ └── Span D: 写入数据库 (耗时 100ms)
│ └── Span E: 调用支付服务 (耗时 150ms)
一眼就能看出来，瓶颈在订单服务的数据库写入上。
我的建议：全链路监控不是搭完就完事了。你得定期看「热点图」，找出那些频繁出现的长耗时 Span。我见过一个团队，监控搭了半年，从来不看，等于白搭。
2.6 监控体系怎么搭
指标和工具都有了，怎么搭成体系？我一般分三层：
| 层级 | 关注点 | 指标示例 | 工具示例 |
|---|---|---|---|
| 基础设施层 | CPU、内存、磁盘、网络 | CPU 使用率、内存占用、IOPS | Prometheus + Node Exporter |
| 应用层 | QPS、TPS、延迟、错误率 | P99 延迟、Apdex、错误数 | Prometheus + Micrometer |
| 业务层 | 业务指标、用户体验 | 下单成功率、支付耗时 | 自定义埋点 + Grafana |
嗯，这里要注意：不要一开始就追求大而全。我习惯先搭应用层，把 QPS、延迟、错误率这三个核心指标先抓起来。等稳定了，再往下补基础设施，往上补业务。
警告：监控本身也会消耗性能。尤其是全链路监控，每个 Span 都要采样、传输、存储。我建议采样率不要超过 10%，除非你在做压测或排查特定问题。
最后说一句。指标是死的，人是活的。你搭了再漂亮的监控大盘，如果没人看、没人分析，那就是个摆设。我每次上线新功能，都会盯着 Grafana 看半小时，确认指标没异常才放心。这个习惯，救过我不少次。