微服务性能调优实战：从全链路追踪到连接池、GC与异步化

1. 性能问题的表象与本质：先弄清楚调优到底在调什么

做微服务时间长了，你会遇到一个非常典型的场景：压测环境里单机接口响应时间稳定在 50ms 左右，一上生产、流量翻倍，同样的接口就变成 800ms，甚至直接超时。排查了半天，代码没变、数据库没变、中间件也没变，唯一变的是流量。这种问题如果靠拍脑袋猜，很容易陷入"加机器、加配置、改超时"的循环里，最后钱花了、机器加了，延迟反而更糟糕。

这时候需要冷静下来做一件事：搞清楚性能瓶颈到底卡在哪一层。

微服务架构下的性能调优，和单体应用有一个本质区别——单体应用的问题通常集中在应用本身、数据库或单台机器的资源竞争上，而微服务的问题往往是链路性的。一个请求从前端进入，经过网关、鉴权服务、业务服务 A、业务服务 B、缓存、数据库、消息队列，任何一环出现延迟叠加，最终到用户侧就是几十倍的放大。所以微服务调优的第一步，不是去优化某一段代码，而是先建立全链路的观测能力，搞清楚时间到底消耗在哪个环节。

我在实际项目里通常会把性能问题的表象和本质分开看：

• 表象：接口 RT（响应时间）升高、QPS（每秒请求数）上不去、成功率下降、CPU 使用率异常、线程池任务堆积。
• 本质可能来源：代码逻辑低效（如循环查库、大对象复制）、数据库慢查询或锁等待、缓存失效导致击穿、服务间调用超时配置不合理、线程池参数与流量不匹配、连接池耗尽、GC 频繁触发 STW（Stop The World）、序列化开销过大、网络带宽或 IO 瓶颈。

大多数团队踩的第一个坑，就是看到 CPU 飙高就以为是代码死循环，看到 RT 升高就以为是数据库慢查询，最后折腾一圈发现是某个 Feign 调用的超时时间设成了 30 秒，下游服务一抖动，上游线程池全部被占满。

所以我想先分享一个核心方法论：调优之前，先建立"可观测性三角"——全链路 Trace（调用链）、Metrics（监控指标）、Logging（日志）。这三样东西缺一不可，否则后面所有优化动作都是盲人摸象。

1.1 为什么微服务性能问题不能靠单机排查解决

在单体应用里，你可以在服务器上跑 top、jstack、jstat，看 JVM 内存和线程，问题基本能定位个八九不离十。但微服务架构下，一个请求可能横跨五六个服务，每跳过一个服务就多一次网络 IO、多一次序列化和反序列化、多一次线程切换。如果只会看单台机器的指标，你根本无法知道延迟是从哪一跳开始变大的。

举个例子，我之前排查过一个案例：下单接口在压测时 P99 延迟从 120ms 涨到 1500ms。单看应用 A 的日志，发现它在调用服务 B 时耗时 1 秒多；再看服务 B，处理逻辑本身只花了 50ms；继续往下追，发现 B 在调用 C 时等待了 900ms，而 C 是因为 Redis 连接池耗尽，在排队等连接。如果不铺全链路 Trace，你大概率会去优化 A 的代码，实际上 A 一点问题都没有。

这里给一个非常实用的工具组合：

• 调用链监控：SkyWalking 或 Zipkin，用来追踪每个请求经过的节点和耗时分布。
• Metrics：Prometheus + Grafana，监控服务 QPS、RT、错误率、JVM GC、线程池活跃数、连接池使用率。
• 日志聚合：ELK 或 Loki，排查具体异常和慢日志。

这三样不是"做不做都行"，而是微服务调优的底线。没有 Trace 就去调优，等于蒙着眼睛开车。

1.2 调优目标不是追求"快"，而是消除"不确定"

性能调优还有一个容易被忽略的点——调优的目标通常不是让平均延迟更低，而是让延迟的分布更稳定。

平均 RT 只是表象里的表象。假设一个接口平均 RT 是 100ms，但 P99 是 2 秒，这意味着 1% 的请求要等 2 秒，这对用户体验来说是灾难性的。微服务链路里的长尾延迟往往来自这些地方：

• GC 暂停：一次 Full GC 可能让所有线程停顿数百毫秒甚至几秒。
• 连接池排队：某个瞬间的流量尖峰导致连接不够用，请求全部排队。
• 超时重试：下游超时后，上游重试机制叠加，雪上加霜。
• 缓存穿透：热点 key 过期瞬间，大量请求打到数据库。

所以我在做性能调优时，关注的指标优先级是这样的：P99 > 错误率 > 平均 RT > QPS。先把 P99 压下去，让延迟分布变得紧凑，整个系统的稳定性才会有质的提升。后面我分享的实战案例，也是围绕这一原则展开的。

2. 从瓶颈定位到优化动作：一次典型的链路延迟排查实战

理论说完了，来点实际的。我以一次真实的压测调优过程为例，完整走一遍从定位到优化的链路。这个案例的背景是：一个电商核心交易服务，双十一前压测，接口"创建订单"的 P99 延迟从预期的 200ms 涨到了 1200ms，QPS 卡在 800 上不去，CPU 利用率只有 30%，明显不是资源不够的问题。

这个现象很典型——CPU 不高但 RT 很高，多半是线程在等待。等待的东西无非几类：锁、IO、连接、下游响应。接下来就是沿着调用链逐层拆。

2.1 调用链拆解：先确认时间消耗在哪个环节

我第一步做的是在 SkyWalking 上看 Trace 数据，发现耗时分布大概是这样的：

注意看，真正"属于自己代码逻辑"的时间只有 30ms，其余 90% 以上都耗在了对下游服务的调用上。这就是微服务性能调优和单体应用最大的区别：你的性能很多时候不由自己的代码质量决定，而由你依赖的所有下游服务的响应速度共同决定。

有了这个分布，接下来的优化优先级就非常清楚了：先搞定耗时最长的 Redis 查询，再解决库存服务调用，最后看数据库查询。

2.2 Redis 查询为什么慢：一次缓存穿透引发的连锁反应

服务 B 的 Redis 查询耗时 420ms，点进去看 Trace 发现，B 里执行了 12 次 Redis 操作，每次的耗时都在 30-50ms 不等。正常情况下 Redis 操作应该是亚毫秒级的，几十毫秒一次明显不正常。

排查路径如下：

1. 先看 Redis 服务端的慢日志，发现这些操作都集中在若干个 key 上，为热 key 争抢。
2. 再看 Redis 的 INFO 输出，发现 client 连接数达到了 2000，blocked_clients 有几十个，说明连接在排队。
3. 最终定位到根因：服务 B 的 Redis 连接池 maxTotal 设置只有 50，但服务的 QPS 是 800，每个请求要执行 12 次 Redis 操作，相当于每秒需要 9600 次 Redis 调用。50 个连接分摊下来，每个连接每秒要处理近 200 次操作，远超单连接的实际处理能力，于是大量请求在连接池排队。

这个问题的根源不是 Redis 性能差，而是连接池容量与请求量严重不匹配。很多人以为连接池越大越好，其实不然。连接池过大会导致 Redis 服务端维护大量空闲连接，浪费内存和 CPU；但连接池过小，在高并发下就是自缚手脚。

解决方案：

code复制JedisPoolConfig config = new JedisPoolConfig();
// 核心参数：按峰值 QPS 和单连接处理能力估算
config.setMaxTotal(200);
config.setMaxIdle(100);
config.setMinIdle(20);
config.setMaxWaitMillis(3000);  // 获取连接的最大等待时间

调整的核心理由：单连接在良好网络下每秒可以执行约 5-8 万次简单操作，考虑到批量操作和网络延迟，我按 1 万次/秒估算。800 QPS × 12 次 = 9600 次/秒，预留 2 倍余量，200 个连接完全够用。调大连接池后，Redis 查询耗时从 420ms 降到 20ms 以内。

2.3 库存服务调用的超时与重试：微服务雪崩的温床

第二个大头是 A 调用服务 D（库存服务）耗时 380ms。查看 Trace，发现服务 D 本身的处理时间只有 15ms，但 A 等待响应却花了 380ms。问题出在网络传输和超时配置上。

继续排查发现，A 调用 D 使用的 HTTP 客户端超时时间设置为 5 秒，连接池的最大连接数只有 20。压测时 QPS 一上来，连接池被打满，新请求只能排队等待空闲连接，排队时间直接成了 RT 的主要组成部分。

这个场景有很强的代表性——服务间 HTTP 调用的连接池参数，是微服务性能调优里最容易被忽视又最容易出问题的地方。很多团队上线服务时，连接池、超时时间都是默认值，流量小的时候看不出来，一到大促就集体爆炸。

我的调整建议如下：

yaml复制# Feign/RestTemplate 连接池配置
http:
  max-connections: 200          # 连接池总连接数
  max-connections-per-route: 100 # 单个目标服务的最大连接数
  connect-timeout: 500ms         # 建立连接超时
  read-timeout: 2000ms           # 等待响应超时
  connection-request-timeout: 200ms # 从连接池获取连接的超时

仔细看这几个超时的层级关系：总耗时 = 获取连接时间 + 连接建立时间 + 等待响应时间。连接请求超时一定要设置得比读超时短，否则在连接池耗尽时，请求会一直排队，等价于没有超时保护。

另外，重试策略也要谨慎。默认的 Feign 重试可能会导致下游接口被重复调用多次。在写操作接口上，重试必须考虑幂等性；在读操作上，重试的超时时间要逐次递减，不能全部用同一个值。否则一次小的抖动就会引发重试风暴，把下游服务打挂。

调整完连接池和超时后，A 调用 D 的耗时降到 30ms 以内，整个链路 P99 从 1200ms 降到了 300ms。但这还不够，接下来要处理数据库那个大头。

3. 数据库与缓存层：性能调优的深水区

链路里的 Redis 和 HTTP 连接池问题解决后，P99 降到了 300ms，但距离 200ms 的目标还有差距。剩下的主要耗时集中在数据库查询上（300ms 降到 80ms），以及一些隐藏的 GC 问题。

数据库在微服务架构里的地位很特殊：它是整个链路中最难水平扩展的组件，也是性能问题的重灾区。很多时候服务本身调得再快，数据库一个慢查询就能让所有努力归零。

3.1 慢 SQL 排查：索引失效的典型场景

打开数据库慢查询日志，发现一条 SQL 每次执行耗时 2 秒多：

sql复制SELECT * FROM order_detail 
WHERE user_id = ? 
AND status IN ('CREATED', 'PAID') 
AND create_time > ? 
ORDER BY create_time DESC 
LIMIT 20;

看表结构，order_detail 表的索引只有主键和 user_id 的单列索引。这条 SQL 的执行计划大概率是这样的：先用 user_id 索引定位到该用户的所有订单，然后进行文件排序（filesort），最后取前 20 条。如果某个用户的订单量巨大，文件排序的代价会非常高。

解决方式很直接——建复合索引：

sql复制ALTER TABLE order_detail 
ADD INDEX idx_user_status_time (user_id, status, create_time);

这里有个细节：user_id 上用等值查询，status 也是等值查询，create_time 是范围查询，索引顺序应该是 user_id → status → create_time。这个顺序是有讲究的，等值条件在前，范围条件在后，才能最大化索引利用率。

加了索引后，SQL 从 2 秒降到 20ms。这也是我反复强调的一点：遇到慢 SQL，先看执行计划，先看索引，不要急着改 SQL 结构。90% 的慢 SQL 问题都能通过合理的索引解决。

还有一个常见坑是隐式类型转换。如果表里的 user_id 是 varchar 类型，Java 代码里传的是 Long 类型，MySQL 会自动做隐式转换，导致索引失效。你在排查时看到"明明有索引但走全表扫描"，优先检查这一项。

3.2 缓存穿透、击穿、雪崩：一次给你讲透

数据库优化到 20ms 后，理论上已经可以了。但压测时发现一个现象：每过一个小时，数据库的 QPS 就会有一个尖峰，和订单查询接口的缓存失效时间完全吻合。这是典型的缓存穿透/击穿问题。

这三个概念很多人容易混淆，我用最直白的方式说清楚：

• 穿透：查一个根本不存在的数据，缓存没有，数据库也没有，导致每次请求都打数据库。
• 击穿：某个热点 key 在失效的瞬间，大量请求同时打到数据库。
• 雪崩：大量 key 同时过期，或者 Redis 宕机，所有请求像瀑布一样砸向数据库。

针对穿透，解决方案是在缓存查不到、数据库也查不到时，把空值也缓存起来，设置一个较短的过期时间（如 60 秒），避免每次请求都穿透到数据库。

针对击穿，方案是使用互斥锁（Mutex Key）：当缓存失效时，不是所有请求都去查数据库，而是只让一个请求去查，查完回填缓存，其他请求等待一段时间后重新读缓存。也可以用逻辑过期方案：缓存不设置物理过期时间，而是写入一个逻辑过期时间字段，发现逻辑过期后异步去更新。这种方式对一致性要求不高的场景很实用。

针对雪崩，核心是过期时间加随机因子。不要所有 key 都设置统一的过期时间，而是在基础过期时间上加上一个随机值，例如 300 秒加上 0-60 秒的随机数，避免大量 key 在同一时刻集体失效。

在压测中发现这个问题的根因是：代码里所有订单查询的缓存过期时间都写死了 3600 秒，每小时整点集体失效。加了随机因子后，数据库的尖峰彻底消失了。

3.3 JVM 与 GC 调优：被低估的延迟杀手

数据库和缓存搞定后，系统 P99 已经降到 120ms 左右，但距离 200ms 的目标反超了。压测过程中我发现一个诡异的现象：A 服务的 CPU 使用率不高，但有规律的毛刺。每隔几十秒，RT 就会突然涨一波，然后又恢复正常。

用 jstat 查了一下 GC 情况：

code复制jstat -gcutil <pid> 1000

发现 Full GC 的频率是每 30 秒一次，每次 STW 停顿 500ms 以上。这个停顿直接反映到 RT 上，成了 P99 的主要来源。

GC 调优的核心思路是：调整堆内存结构和分配比例，让对象更早被回收，减少晋升到老年代的数量。

我看了一下当时的 JVM 参数，新生代只有 1GB，老年代有 3GB，创建订单时会创建大量的中间对象，新生代很容易被撑爆，对象提前晋升到老年代，老年代一满就触发 Full GC。

调整方案如下：

code复制-Xms4g -Xmx4g
-Xmn2g                  # 新生代扩大到 2GB，给“朝生夕死”的对象更大的空间
-XX:SurvivorRatio=8     # Eden 与 Survivor 的比例
-XX:MaxTenuringThreshold=15 # 最大晋升阈值提升到 15
-XX:+UseG1GC            # 使用 G1 收集器
-XX:MaxGCPauseMillis=100

调大新生代后，大部分对象在 Minor GC 就被回收了，晋升到老年代的对象大幅减少。Full GC 从每 30 秒一次降到每 10 分钟一次，RT 毛刺消失了。

GC 调优没有银弹，需要根据实际业务场景反复试。但有一条经验可以分享：如果服务的 QPS 较高、对象朝生夕死特征明显，优先扩大新生代；如果服务有大量长生命周期对象（如缓存数据），则需要关注老年代的容量和 G1 的混合回收。另外，日志里多打印 GC 信息不会有坏处，线上问题排查时能省很多力气。

4. 线程池与异步化：微服务性能优化的隐藏杠杆

数据库、缓存、GC 都调完之后，接口的 P99 已经稳定在 120ms 以内，QPS 也到了 2000。但想要支撑双十一的流量预估（峰值 5000 QPS），还有一段路要走。这时候我考虑从架构层面做一些优化——线程池和异步化改造。

很多人优化性能是"头痛医头、脚痛医脚"：RT 高了查 SQL，SQL 慢了加索引。但微服务的性能天花板往往由线程模型决定。一个服务能扛多少并发，不是看 CPU 多强，而是看线程池能同时处理多少请求，以及这些请求在等待 IO 时是否白白占用了线程。

4.1 线程池参数：不是越大越好，而是匹配 IO 等待占比

先来看一个经典问题：服务 A 调用下游服务，平均耗时 100ms，其中 80ms 在等待网络响应（IO），20ms 在 CPU 计算。如果线程池有 200 个线程，每秒最多能处理多少请求？

根据 Little's Law 的简化公式：吞吐量 = 线程数 / 平均响应时间，即 200 / 0.1 = 2000 QPS。如果线程池扩到 400 个，吞吐量能到 4000 QPS。但线程数过多会带来线程上下文切换开销，CPU 也会被大量浪费在调度上，所以线程数的确定要基于 IO 密集型还是 CPU 密集型的判断。

业界常用的估算公式：

code复制IO 密集型应用：
线程数 = CPU 核心数 × 2 × (1 + 等待时间 / 计算时间)
CPU 密集型应用：
线程数 = CPU 核心数 + 1

我遇到过很多团队把线程池设置成 500 甚至 1000，结果 CPU 大量消耗在上下文切换上，TPS 反而下降。所以线程池参数是要按照业务特征去细算的，而不是凭感觉往大了设置。

对于 Java 服务中常见的 ThreadPoolTaskExecutor，核心参数可以这样设计：

java复制ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
executor.setCorePoolSize(50);
executor.setMaxPoolSize(200);
executor.setQueueCapacity(1000);
executor.setKeepAliveSeconds(60);
executor.setThreadNamePrefix("biz-exec-");
executor.setRejectedExecutionHandler(new CallerRunsPolicy());

queueCapacity 的设置尤其关键。如果队列太长，请求会长时间堆积在队列里，前端等着超时；如果队列太短，大量请求会直接触发拒绝策略。我的建议是：队列容量设置为 maxPoolSize 的 5 倍左右，配合 CallerRunsPolicy 拒绝策略。CallerRunsPolicy 的意思是，当线程池满载且队列已满时，不让请求直接失败，而是由调用方线程执行该任务。这相当于起到了天然的背压效果，调用方全链路感知到压力，自动放缓请求速度，而不是整条链路被压垮。

4.2 异步化改造：把"串行等待"变成"并行等待"

还是拿创建订单的接口举例。这个接口的业务逻辑大致如下：

1. 校验参数（10ms）
2. 查询商品信息（20ms）
3. 调用库存服务扣减库存（30ms）
4. 调用优惠券服务计算优惠（20ms）
5. 写入订单数据（20ms）
6. 发送消息通知（10ms）

串行执行的总耗时是 110ms。但实际上，步骤 2、3、4 之间并没有严格的先后依赖关系——它们都可以并行执行。步骤 5 依赖 2、3、4 的结果，所以必须等待前面完成。步骤 6 可以异步发送，不需要用户等待。

改造方式是用 CompletableFuture：

java复制CompletableFuture<ProductInfo> productFuture = CompletableFuture.supplyAsync(() -> productService.query(context), pool);
CompletableFuture<Void> stockFuture = CompletableFuture.runAsync(() -> stockService.deduct(context), pool);
CompletableFuture<CouponInfo> couponFuture = CompletableFuture.supplyAsync(() -> couponService.calc(context), pool);

CompletableFuture.allOf(productFuture, stockFuture, couponFuture).join();

// 并行执行完毕后，再执行写订单操作

改造后，步骤 2、3、4 并行执行，总耗时从 20+30+20=70ms 降到了 30ms（取三者最大值）。整个接口从 110ms 降到了 70ms，QPS 上限也从 2000 提升到 2800 左右。

这个优化方式非常简单，但收益非常可观。我在实际项目中见过太多因为"保持代码简单"而放弃异步化的团队，结果只能靠加机器来扛流量，成本高不说，还增加了服务间的网络调用次数，进一步加剧延迟。

4.3 异步化的边界：不是所有场景都适合

异步化是个好工具，但用不好也会引入新问题。我总结几个要注意的点：

第一，事务边界不能跨线程。Spring 的事务是绑定在线程上的，如果你在异步线程里执行 @Transactional 方法，事务管理可能会失效。处理方式是：把事务操作单独提取到一个方法中，在同一个线程内完成事务提交。

第二，上下文传递问题。异步线程里的 TraceId、用户信息、Token 等上下文信息，默认是不会传递的。线上排查问题时，如果日志里没有 TraceId，整个调用链就断掉了。需要用 TransmittableThreadLocal（TTL）或者手动把上下文参数传到子线程中。

第三，异步任务的异常处理。CompletableFuture 的异步任务如果发生异常，默认会存储在该 Future 对象中，如果没地方处理，异常会被吞掉。一定要用 exceptionally 或 whenComplete 显式处理异常，否则会出现"接口正常返回了，但数据没写入"的诡异问题。

这些坑在压测阶段通常不会暴露，但一上线就会变成 P0 故障。异步化改造的每一行代码，都要想清楚线程池是谁的、异常谁处理、上下文怎么传。

5. 全链路压测与容量规划：让调优结果可量化、可预期

经过前面的优化，系统的 P99 从 1200ms 降到了 80ms，QPS 从 800 提升到了 2800 左右。但这些数字都是在小流量压测下得到的，真正到大促时会怎样，心里还是没底。所以要搞一次全链路压测，验证整个系统的容量边界，找出链条上的最弱一环。

全链路压测和普通的接口压测不一样，它需要模拟真实用户请求，走完整条调用链，包括网关、各个微服务、缓存、数据库、消息队列。这样测出来的数据才是可信的。

5.1 压测方案设计：如何让压测结果更接近真实

我设计全链路压测的思路是这样的：

1. 流量模型建模：根据历史请求日志，统计出各类接口的调用比例、平均请求体大小、URL 分布。不要让压测工具只打一个接口，那样会高估系统的容量。
2. 压测数据隔离：压测流量会写入数据库和消息队列，如果不做隔离，会产生大量脏数据。常见的方案是在压测请求中打标记，在中间件层面识别并路由到影子表或影子队列。
3. 阶梯加压：从 100 QPS 开始，每 10 分钟翻倍，直到系统出现劣化。记录每个压力级别的 RT、错误率、CPU、内存、GC、连接池使用率，找到系统的拐点。
4. 容量水位评估：根据单机容量和集群规模，算出整体容量。我当时测出来的单机容量是 800 QPS，集群有 10 个节点，理论容量 8000 QPS，但因为有负载不均和服务间相互影响，实际容量按理论值的 70% 估算，即 5600 QPS，刚好覆盖峰值预估。

这里要特别说一句：容量规划的精度永远比你想的要低。微服务链路里，每个服务的能力都不一样，瓶颈永远出现在最弱的那一环。压测的核心目标不是得出一个令人满意的数字，而是找到链条上的短板。

5.2 限流与降级：给系统装上安全阀

压测过程中，我们发现库存服务的 QPS 超过 1500 后，错误率开始显著上升。数据库连接池是瓶颈，连接池总连接数 100，但库存服务有大量查询和写入操作，连接很快就不够用了。而且库存服务是核心依赖，不能简单地优化数据库或加索引，因为业务逻辑本身复杂。

这时候需要从架构层面考虑限流和降级策略。

限流主要是保护系统自身，防止流量把系统打垮。我用的是 Sentinel，针对热点接口配置了限流规则：

code复制接口: POST /api/order/create
QPS 阈值: 5000（集群维度）
降级策略: 快速失败，返回友好提示

限流的阈值要根据压测结果来设定。我的经验是设为"系统容量拐点的 80%"，既保护系统，又尽量不误伤正常流量。

降级则是保障核心功能不被非核心功能拖垮。比如创建订单成功后需要调用积分服务增加积分，如果积分服务变慢，不能因为积分服务而影响主交易链路。此时需要把积分调用改成异步执行，或者配置降级开关：当积分服务 RT 超过阈值时，直接跳过该调用，订单正常返回。

这个设计哲学在微服务里叫做依赖隔离——核心链路和非核心链路不能共享同样的资源池。我在实际项目里甚至会把读服务和写服务的线程池分开，避免读服务的流量尖峰把写服务的线程池占满，导致"只读不畅、写不进库"。

5.3 压测后的复盘：性能优化是持续过程

压测结束后，我习惯做一次细致的复盘，把所有观测到的异常数据整理成一张问题清单，标注优先级和负责人。比如这次压测中发现了三个新问题：某个接口的 JSON 序列化过于频繁、某个服务的内存占用过高、某个消息队列的消费能力不足。这些问题虽然不致命，但会限制后续的扩容空间。

要记住，性能调优不是一锤子买卖。业务在变、流量在变、代码在变，系统的性能特征也会随之变化。这次做好的调优，可能三个月后就失效了。所以我在项目里会固定安排"季度压测 + 月度巡检"的机制，让性能问题暴露在用户投诉之前。

6. 调优工具箱与实战经验总结

写到最后，把这次实战中用到的工具和经验做个整理，方便你在自己的项目中直接参考。

6.1 常用工具清单

6.2 调优顺序经验：不要跳步

根据这次实战，我的调优顺序基本固定为：

1. 可观测性先行：没有 Trace、Metrics、Log 就别提调优。
2. 外部依赖优先：先解决 Redis、MySQL、下游 HTTP 调用的耗时问题，再回头优化自己代码。
3. 连接池与线程池：确认所有池化资源的参数是否与压力匹配。
4. GC 与 JVM：排查延迟毛刺。
5. 异步化与并行化：从架构层面减少等待时间。
6. 限流与降级：为系统设置安全阀，防止极端流量打垮服务。

这个顺序不完全绝对，但大方向是对的。很多时候一顿操作猛如虎，最后发现最大的瓶颈偏偏是最不看重的 Redis 连接池。

6.3 几条实战心得

最后分享几条走了不少弯路才总结出来的经验。

第一，性能调优一定要有量化目标。没有目标的调优很容易变成无底洞。我每次调优前都会定一个明确指标，比如"P99 从 1200ms 降到 200ms 以内"“错误率低于 0.1%”，调优结束后再对照检验是否达成。

第二，不要迷信"高性能技巧"。很多人一上来就想用 Caffeine 本地缓存、Netty 异步非阻塞来解决问题。但很多时候，问题根源不过是一个索引、一个连接池参数。先把基础做扎实，再考虑高级优化手段。

第三，变更要有回滚预案。性能调优涉及线程池参数、JVM 参数、缓存策略等，频繁调整容易引入新问题。每次变更前记录变更内容、预期效果，观察一段时间后再做下一步调整。如果出现指标恶化，要知道如何快速回滚。

第四，调优结果一定要写进文档。我当时给整个项目写了一篇压测调优报告，记录了每个问题的现象、根因、解决方案和收益。三个月后团队再来一次新的业务迭代，直接参考这份文档，省了大量重复排查的时间。

微服务性能调优这件事，看起来是技术活，实际上更像是一个系统工程。每个环节都要有数据支撑，每次优化都要有决策依据。希望这些实战经验能让你少走一些弯路。如果你的系统也遇到了类似的问题，欢迎对照这篇文章里的方法一步步排查，应该会有不错的收获。