4、请求流程拆解：从接入层到持久层的全链路耗时分析
这一章，我们聊聊请求的全链路耗时。说白了，就是一条审计请求从客户端发出去，到最终拿到响应，中间每一站花了多少时间。我在项目中见过不少人，一提到优化就盯着数据库 SQL 调优，结果改了半天 QPS 还是上不去——因为瓶颈根本不在持久层。
为什么会这样？因为一个请求的路径比你想象的长得多。你想想看，它要经过网络、网关、业务逻辑、缓存、数据库，每一层都可能成为“坑”。
我个人习惯，接到一个慢接口，第一件事不是看代码，而是先画一张全链路耗时拆解图。位置不同，瓶颈不同，优化手段也完全不同。
4.1 接入层耗时：第一公里
接入层，就是请求进入我们系统的第一站。包括 DNS 解析、建立 TCP 连接、TLS 握手、负载均衡转发等。
我记得有一次，生产环境审计接口偶尔超时，排查了三天，最后发现是 DNS 解析偶尔抖动，导致连接建立延迟从 2ms 飙到 200ms。嗯，这里要注意：接入层的耗时，往往不是代码能解决的。
| 环节 | 典型耗时 | 优化方向 |
|---|---|---|
| DNS 解析 | 1-50ms | DNS 缓存、HTTPDNS、提前预热 |
| TCP 三次握手 | 1-3 RTT | 连接复用、长连接池 |
| TLS 握手 | 2-5 RTT | 会话复用、TLS 1.3 |
| 负载均衡转发 | 0.1-1ms | 内核调优、DPDK、减少转发层 |
curl -w 或者业务埋点来采集。我推荐在网关层统一打点，比在业务代码里打点要准。
4.2 逻辑层耗时：最容易“膨胀”的一层
请求一旦到了应用服务器，就进入逻辑层。这一层最复杂，也最容易出问题。我见过不少人在这里写“面条代码”，一个接口里调了十几个服务，串行执行，耗时直接翻倍。
逻辑层耗时主要来自三块：
- 服务间 RPC 调用：每次调用都有网络开销，串行调用尤其要命
- 业务计算：比如权限校验、数据聚合、格式转换
- 序列化/反序列化：特别是 JSON 序列化，大对象时很耗时
我个人习惯，在逻辑层用火焰图或者链路追踪来定位热点。有一次我发现一个审计接口里，80% 的耗时耗在一个“数据校验”函数上——其实大部分字段根本不需要校验。去掉后，接口耗时从 800ms 降到 120ms。
4.3 缓存层耗时：不是万能的，但不用是万万不能的
缓存层，是审计接口优化的“主力军”。审计数据往往有“读多写少”的特点，非常适合用缓存。但缓存也不是银弹——缓存穿透、缓存击穿、缓存雪崩，每一个都能让你头疼。
缓存层耗时通常很稳定，一般在 1-10ms 以内。但一旦发生缓存穿透，请求直接打到数据库，那延迟就会从 1ms 变成 100ms。
| 缓存模式 | 典型耗时 | 注意事项 |
|---|---|---|
| Redis 集群读取 | 1-5ms | 注意连接池大小和超时设置 |
| 本地缓存 | 0.1-0.5ms | 注意内存占用和一致性 |
| CDN 缓存 | 1-20ms | 适合静态审计规则等 |
4.4 持久层耗时：最后的“守门员”
持久层，就是数据库层。这一层往往是传统优化重点，但也是很多人的“盲区”——他们只盯着 SQL 调优，忽略了前面几层的影响。
持久层耗时主要包括：
- SQL 执行耗时：索引是否合理、查询是否高效
- 连接池等待耗时：连接池太小，请求排队
- 事务锁等待：行锁、表锁、间隙锁
- 磁盘 I/O 耗时：随机 I/O vs 顺序 I/O
我见过一个审计接口，SQL 本身只要 10ms，但连接池等待却花了 200ms。为什么会这样？因为连接池只配了 10 个，而并发请求有 100 个，90 个都在排队。这不是 SQL 的问题，是配置的问题。
4.5 全链路耗时汇总与优化清单
把上面四层的耗时装到一起，你就能画出一张“全链路耗时分布图”。我建议你拿到一个慢接口后，先做一次这样的拆解，找出 TOP 3 的耗时环节，然后逐一优化。
| 层级 | 典型耗时占比 | 常用优化手段 |
|---|---|---|
| 接入层 | 5%-15% | 连接复用、DNS 缓存、TLS 1.3 |
| 逻辑层 | 20%-50% | 并行调用、减少序列化、热点函数优化 |
| 缓存层 | 10%-20% | 多级缓存、防止穿透、本地缓存 |
| 持久层 | 20%-40% | SQL 调优、索引优化、连接池配置 |
你想想看，如果一个接口耗时 1000ms，逻辑层占了 500ms，你却去优化数据库，那顶多省下 200ms。但如果先把逻辑层的“串行调用”改成“并行调用”，可能一下子就省下 300ms。
好了，这张全链路耗时拆解的思路就是这么多。下一章，我们聊聊“如何用并行化手段压榨逻辑层性能”。不过，先把你手上那个慢接口的耗时分布画出来再说。