Wong Kosheng做分布式系统性能优化这些年，我最大的体会是：互联网应用一旦拆成微服务跑在集群里，性能问题就不再是“某一行代码慢”那么简单，而是一连串依赖关系、资源配置、框架行为和偶发故障共同作用的结果。这篇文章我不想讲高深的理论，而是想把这几年在互联网分布式系统性能优化上的工程实践、排查方法和多语言示例，以随笔的形式整理出来，给正在写后端、维护中间件或者做架构设计的同行一份参考。它不会告诉你“终极优化大法”，只会告诉你性能问题来了之后，第一步做什么、第二步做什么，以及每一步背后的理由。
1. 一次线上事故让我重新理解了“性能瓶颈”
1.1 事故概况：P99 从 500ms 飙到 8 秒
去年下半年，我们团队维护的订单查询服务突然告警：接口 P99 延迟从平时的 500ms 左右直接飙到 8 秒以上。当时第一反应是查数据库慢查询，结果一条像样的慢 SQL 都没有；再看 CPU 和内存，也都正常。这个现象让所有人都很困惑——按常规思路，接口慢要么是计算慢、要么是 IO 慢、要么是等待慢，可 CPU 不高说明不是计算瓶颈，数据库没慢查询说明 SQL 本身没问题，内存正常说明 GC 压力也不算大。那这 8 秒的时间到底耗在哪里？
我拉出链路追踪系统的调用链数据，发现一次请求在整个链路上要经过网关、鉴权服务、订单服务、商品服务、库存服务、优惠券服务六个节点。其中订单服务自身只花了 200ms，但整条链路的耗时却高达 8 秒。问题几乎是指向了下游——商品服务和库存服务之间，有一个第三方商品状态同步接口，它的超时时间被设置成了 15 秒，而那个接口的错误率恰好在这段时间突然升高，所有上游请求都卡在等待这个接口返回上。更糟糕的是，这个等待不是“等一个请求”，而是几百个并发的请求同时占住了 Tomcat 的工作线程，线程池被打满之后，后面来的请求全部在队列里排队，排队时间越积越长。
1.2 定位链路：六层依赖里的时间黑洞
这个事故的排查过程其实很有复盘价值。我当时的排查顺序是这样的：先看网关层监控，网关本身的耗时正常，错误率也没有异常；接着看订单服务自身的接口监控，发现本地方法执行时间并不长，耗时全部集中在调用下游的环节；于是打开链路追踪系统，把请求的 span 列表按耗时倒序排列，一眼就看到商品服务的三方调用 span 耗时 7.8 秒，占整条链路的 97% 以上。
接下来要回答的问题从“哪里慢”变成了“为什么这个调用这么慢”。我把商品服务的日志拉出来，发现这个第三方接口的错误率确实在上升，但它本身不是完全不可用，而是响应时间变得极不稳定，有时 100ms 返回，有时直接挂到超时。问题在于，商品服务对它的调用没有设置独立的线程池隔离，也没有配置熔断策略，默认的超时时间又是非常宽松的 15 秒。于是当第三方接口变慢时，商品服务的工作线程被大量占用，紧接着库存服务和订单服务的数据拉取也全部排队等待，故障就像涟漪一样往外扩散。
1.3 分布式性能问题的三个层次
这次事故之后，我把分布式系统的性能问题总结成三个层次：第一层是单点计算慢，包括业务代码低效、算法复杂度高、GC 停顿、内存分配频繁等，这类问题在单机时代最常遇到，排查手段也最成熟；第二层是依赖调用慢，包括网络抖动、第三方接口变慢、DNS 解析超时、序列化开销过高等，这类问题在微服务架构里最普遍，也是分布式环境特有的；第三层是资源竞争与排队，线程池被打满、数据库连接池耗尽、信号量或限流器触发，这类问题的特点是“系统看起来还活着，但请求就是进不去”。
这三个层次不是彼此独立的，很多时候是层层叠加的。但区分它们有一个非常实际的好处：不同层次的优化手段完全不同。单点计算慢需要改代码、调算法；依赖调用慢需要设超时、做熔断、改通信方式；资源竞争需要调线程池参数、连接池大小、限流阈值。如果连问题属于哪个层次都没搞清楚，做再多优化也只是碰运气。所以我在带团队时反复强调一句话：先定层，再动手。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 动手之前先建基线：可观测性才是性能优化的前提
2.1 可观测性三件套要这样配合
很多团队做性能优化失败，不是优化手段不行，而是缺少足够的数据来确认问题到底在哪。我见过不少项目，监控面板上只有 CPU、内存、磁盘三个指标，一旦出了性能问题，大家只能靠猜。现代分布式系统的可观测性至少应该覆盖三个维度：Metrics、Tracing、Logging，三者各管一段。
Metrics 负责回答“系统健康吗”，常用的有 RED 方法和 USE 方法。RED 是 Rate（每秒请求量）、Error（每秒错误数）、Duration（延迟分布），适合服务端视角；USE 是 Utilization（资源利用率）、Saturation（资源饱和度）、Errors（资源错误），适合基础设施视角。Tracing 负责回答“请求走到哪一步慢了”，核心是 traceId 在全链路中的透传，以及每个 span 的耗时记录。Logging 负责回答“当时发生了什么”，关键路径上的方法入口和出口要有结构化日志，至少包含耗时、入参、出参、错误码这几个字段。
三件套的配合方式很关键：先用 Metrics 发现异常，再用 Tracing 缩小范围，最后用 Logging 确认细节。我遇到过一些团队，把链路追踪的采样率调到 100%，结果 Tracing 系统自身先扛不住了，反而影响了业务性能。实际生产环境里，全局采样率设在 5% 到 10%，再对错误请求和慢