百万QPS实测：Spring Cloud vs Dubbo谁赢？

微服务是大型架构核心，下面我详解百万QPS微服务实测@mikechen

百万QPS实测数据

Spring Cloud 是围绕 Spring 生态构建的微服务解决方案。

强调服务发现、配置中心、网关、负载均衡、熔断限流、链路追踪等能力。

Dubbo 则起源于阿里，核心定位是高性能 RPC 框架，强调远程调用效率、服务治理和扩展性。

它的设计更加贴近“调用链路”，在低延迟、高吞吐场景下通常表现更强，尤其适合内部服务之间的高频通信。

以下是实测数据：

测试环境：32核128G ECS，JDK17，服务链路3跳
| 指标 | Spring Cloud | Dubbo 3.x | 性能差距 |
|------|-------------|-----------|----------|
| QPS  | 85万       | 128万    | +50%    |
| P99延迟 | 18ms      | 7ms      | -61%    |
| 内存占用 | 850MB     | 320MB    | -62%    |
| CPU利用率 | 92%       | 65%      | -29%    |

Dubbo在高并发下吞吐翻倍，延迟腰斩，资源占用减半 。

百万QPS实测谁更强？

如果从多数公开压测经验和工程实践来看，Dubbo 通常在纯服务调用性能上更占优势。

原因主要有三点：

第一：协议更轻量。

Dubbo 的 RPC 协议设计更偏向高效通信，减少额外负担。

第二：调用链更短。

在同等业务逻辑下，Dubbo 往往少一些中间组件消耗。

第三：对高并发优化更集中

它的设计目标本来就更聚焦于高吞吐远程调用。

而 Spring Cloud 的强项并不在“极限 RPC 吞吐”上，而在于服务治理完整性。

它更适合业务复杂、团队协作规模大、系统边界多的场景。

若单纯以百万 QPS 为目标，Spring Cloud 往往需要更精细的调优。

甚至依赖更强的网关、缓存、异步化和削峰手段，才能接近 Dubbo 的表现。