对于后端开发人员而言，gRPC 和 Dubbo 这两种主流 RPC 框架想必并不陌生。前者由阿里巴巴开源，专注于 Java 生态下的高性能服务治理；后者则出自 Google，基于 HTTP/2 与 Protobuf 协议，天生具备跨语言能力。在实际技术选型时，许多团队都会纠结于同一个问题：两者究竟谁的性能更优？
为了客观评估，我们设计了一个简单的基准测试：在相同的硬件环境下，让两个框架分别循环调用 100 万次，对比每秒可处理的请求数（QPS）。先来看最终数据：
启动并观察运行耗时
测试方法非常直接：通过 Maven 分别启动服务端和客户端，循环执行 100 万次远程调用，记录整个过程的耗时。
mvn exec:ja va -Dexec.mainClass=io.grpc.examples.helloworld.HelloWorldServer
mvn exec:ja va -Dexec.mainClass=io.grpc.examples.helloworld.HelloWorldClient
gRPC 的测试结果如下：
spend time: 126 can handle 7936 per second
这意味着 gRPC 处理 100 万次调用总共花费了 126 秒，每秒约能处理 7936 个请求。
Dubbo 性能测试
在本地启动 ZooKeeper
Dubbo 测试前需要先启动注册中心，这里我们选用 ZooKeeper。
zkServer.sh start
启动 Dubbo 本地服务
在服务实现类上添加 Dubbo 的 `@Service` 注解，并指定版本号。
@Service(version = "1.0.0")
public class HelloServiceImpl implements HelloService {
@Override
public String SayHello(String name) {
return "Hello , "+name;
}
}
Controller 中通过 `@Reference` 注入远程服务，同样执行 100 万次循环调用。
@RestController
public class HelloController {
private final Long testScale = 1000000L;
@Reference(version = "1.0.0")
HelloService helloService;
@GetMapping("sayHello")
public String sayHello( String name){
name = " world";
Long now = Instant.now().getEpochSecond();
for(int idx = 0; idx < testScale; idx++){
System.out.println( helloService.SayHello(String.format("%s:%d",name,idx)));
}
Long duration = Instant.now().getEpochSecond() - now;
System.out.println(String.format("can handle %d per second", testScale/duration));
return String.format("can handle %d per second", testScale/duration);
}
}
Dubbo 运行结果
同样是 100 万次调用，Dubbo 的输出如下：
can handle 12987 per second
每秒处理能力接近 13000 次，相比 gRPC 的 7936 次，优势非常明显。
总结与选型建议
7936 对 12987，差距一目了然。在此次简单对比测试中，Dubbo 的性能确实更胜一筹。这也从侧面解释了为什么 Dubbo 近年来在国内的受欢迎程度持续攀升——除了生态成熟、与 Spring 框架无缝集成外，底层通信效率也经得起实际验证。对于追求高吞吐量的 Java 微服务场景，Dubbo 无疑是更值得关注的选择。
