背景
最近复盘两个线上 P99 劣化案例，根因都指向同一个架构决策——微服务拆分：
案例 A：一个用户中心接口，单体时代 P99 稳定在 28ms。拆成「用户服务 + 权限服务 + 配置服务」三个微服务后，同一条链路要串 3 次 gRPC，每次 RTT 8~15ms（同机房），P99 直接飙到 95ms+。更糟的是每个服务独立维护一个 HikariCP 连接池（10~20 连接），下游 MySQL 实例的连接数从 40 膨胀到 120+，凌晨 GC 时 P99 偶尔冲到 300ms。
案例 B：一个订单创建接口，原来一次本地方法调用 3 个领域对象。拆成「订单服务 → 库存服务 → 价格服务」三级调用后，任何一级 GC STW（哪怕 50ms）都会把整条链路拖入超时。我们被迫给每一级加了 3 次重试 + 指数退避，结果下游被打成雪崩，P99 从 80ms 恶化到 1.2s。
这两个案例不是孤例——我做了 10 年性能优化，越来越觉得一个被社区默认跳过的问题：微服务拆分在架构治理上可能是正确的，但在性能账本上，我们很少认真算过代价。
常见分歧 / 几种做法
我在不同团队见过至少三种截然不同的态度：
1. "拆分是免费的，性能靠框架兜底" 代表做法：用 gRPC / Dubbo + 连接池复用 + 异步化（CompletableFuture / Reactor），认为只要 RPC 框架足够好，拆分对性能几乎无感。我实测过：同机房 gRPC 单次 RTT 确实可以做到 2~5ms，但这是 P50，不是 P99；而且 RTT 是乘法叠加的，3 跳就是 3 倍。
2. "该拆就拆，不该拆就忍" 代表做法：按业务域拆，但接受 30%~50% 的 P99 劣化，用"可接受"来消化。有些团队甚至把 P99 SLO 从 50ms 放宽到 150ms，理由是"用户感知不到"。
3. "拆分后必须做全链路性能回归，否则就是裸奔" 代表做法：每次拆分或合并都要跑全链路压测，对比拆分前后的 P50 / P99 / P999 + GC 暂停 + 连接池水位 + 下游 RT 分布。只有压测数据证明"劣化在 SLO 内"才允许上线。
我的倾向与理由
我倾向第 3 种，但想强调一个经常被忽略的点：微服务拆分对性能的影响不是"加一点延迟"这么简单，它改变的是整个系统的性能模型。
具体来说，拆分后至少有三笔隐性代价需要被显性化：
-
延迟从加法变乘法：单体时代 3 个模块串行调用 ≈ 3 × 本地方法开销（μs 级）；拆分后 3 次 RPC ≈ 3 × (RTT + 序列化 + 反序列化 + 线程切换)（ms 级），而且每一跳的 P99 都会独立抖动，最终 P99 是各跳 P99 的卷积，不是简单相加。
-
资源隔离变成资源碎片化：每个服务独立 JVM → 独立堆 → 独立 GC。原来 1 个 JVM 的 GC 暂停是 1 次，拆成 5 个服务后是 5 次独立 GC，暂停总时长反而可能更长（尤其堆分小了之后 Young GC 频率变高）。连接池同理：原来 1 个池 50 连接够，拆成 5 个服务各 20 连接，下游 DB 看到的就是 100 连接，连接管理开销翻倍。
-
故障域从 1 个变成 N 个：单体挂了就挂了一个服务，拆分后任何一个下游抖动都会沿调用链向上传播。重试 + 超时 + 熔断的复杂度随服务数指数增长——热榜上那篇《超时与重试》讲的就是这个坑。
所以我的核心主张是：性能预算（performance budget）应该和 API 契约一样，成为微服务拆分方案的一部分。 拆之前就要算清楚：这条链路拆成 N 跳后，P99 预算够不够？连接池总预算够不够？GC 暂停叠加后 SLO 还保得住吗？算不过账，就不该拆（或者该合并回去）。
想听大家怎么选
我想听听不同场景下的真实取舍：
- 你们团队拆微服务时，有没有做过"性能预算"测算？如果做过，怎么算的？如果没做，事后 P99 劣化了多少，怎么处理的？
- 同机房 gRPC 单次 RTT 你们实测的 P50 / P99 分别是多少？3 跳、5 跳之后整体 P99 是多少？
- 拆分后 GC 行为有没有明显变化？你们怎么监控"多 JVM 叠加 GC"对 P99 的影响？
- 有没有"拆了又合回去"的案例？触发合并的性能指标是什么？
- 对于 5 个服务以下 vs 20 个服务以上的系统，性能治理策略有什么本质区别？
这个话题我不想下结论，因为答案大概率取决于业务规模、SLA 要求和团队工程能力。但我想把"拆分对性能的隐性代价"这件事从"默认忽略"拉到"显性讨论"的桌面上——毕竟热榜上连接池、超时重试、K8s 探针这些单点问题讨论得很热，但"架构决策本身对性能的影响"这个话题，好像还没人认真开过。
欢迎大家带真实数据和案例来聊。