bigywater.tech
Spring · 135

Dubbo 对比:RPC 与 HTTP 的差别

Dubbo 和 HTTP 到底差在哪?RPC 一定更小更快吗?连接数为什么差那么多?超时之后会不会被重复执行?这篇用 Dubbo 3.3.6(dubbo 与 tri 两种协议)和 JDK 自带的 HTTP 服务,中间放计数代理,在同一台机器上量出来。

334 对 191
一次 hello 的请求字节数:dubbo 协议比 HTTP/1.1 还大,小请求不占便宜
1 对 50
50 个线程并发调用时用到的 TCP 连接数:dubbo/tri 对 HTTP/1.1
3 次
dubbo 默认配置下,超时的 slow 调用服务端真正被执行的次数

字节数

实测 · 本机执行输出 
  dubbo:1 次调用共 166 / 43 字节(含建立连接),每次调用增量 334 / 86 字节;用了 1 个 TCP 连接
  tri:1 次调用共 351 / 182 字节(含建立连接),每次调用增量 139 / 157 字节;用了 1 个 TCP 连接
  http:1 次调用共 95 / 87 字节(含建立连接),每次调用增量 191 / 175 字节;用了 1 个 TCP 连接

小请求 dubbo 不占优势;载荷大了二进制序列化小约三成。

大载荷

实测 · 本机执行输出 
  dubbo:每次调用增量 2836 / 2586 字节
  tri:每次调用增量 2645 / 2650 字节
  http:每次调用增量 3987 / 3931 字节

200 个 long + 200 字符,dubbo 2836、tri 2645、JSON 3987。

延迟与吞吐

实测 · 本机执行输出 
  dubbo 单线程:20000 次调用,线程 1,总耗时 1865 ms,吞吐 10720 次/秒,延迟 p50 83 µs,p99 207 µs
  dubbo 8 线程:40000 次调用,线程 8,总耗时 1182 ms,吞吐 33826 次/秒,延迟 p50 208 µs,p99 650 µs
  tri 单线程:20000 次调用,线程 1,总耗时 2541 ms,吞吐 7869 次/秒,延迟 p50 113 µs,p99 289 µs
  tri 8 线程:40000 次调用,线程 8,总耗时 1735 ms,吞吐 23049 次/秒,延迟 p50 314 µs,p99 993 µs
  http 单线程:20000 次调用,线程 1,总耗时 2687 ms,吞吐 7442 次/秒,延迟 p50 124 µs,p99 253 µs
  http 8 线程:40000 次调用,线程 8,总耗时 2069 ms,吞吐 19332 次/秒,延迟 p50 394 µs,p99 789 µs

dubbo 协议最快,tri 与 HTTP/1.1 接近。

连接模型

实测 · 本机执行输出 
  dubbo:TCP 连接数 1
  tri:TCP 连接数 1
  http:TCP 连接数 50

dubbo、tri 单连接多路复用;HTTP/1.1 并发即连接。

失败语义

实测 · 本机执行输出 
  dubbo 默认重试:slow 失败:RpcException;服务端 slow 被执行了 3 次
  dubbo retries=0:slow 失败:RpcException;服务端 slow 被执行了 1 次
  tri 默认重试:slow 失败:RpcException;服务端 slow 被执行了 1 次
  http:slow 失败:HttpTimeoutException;服务端 slow 被执行了 1 次

dubbo 默认超时重试 2 次,非幂等方法要关。

分步演示

Dubbo 对比
本步的对象

    本文用到的工具与边界

    • 本机 macOS 27 arm64 / OpenJDK 21.0.12(Homebrew) / Spring Boot 4.0.8(Spring Framework 7.0.9、Tomcat 11.0.24) / Spring Cloud 2025.1.3;用 javac 编译、java 直接运行,依赖由 Maven 从 Maven Central 解析;数字每次运行会有小幅抖动。Dubbo 用 API 方式配置(ServiceConfig / ReferenceConfig),直连不用注册中心,同一个服务同时导出 dubbo 与 tri 两个协议;HTTP 对照是 JDK 的 com.sun.net.httpserver + java.net.http.HttpClient(HTTP/1.1),JSON 是手写的;线上字节数由一个 Python TCP 代理统计;延迟与吞吐是回环网络上的单次实验,有抖动,只用来看量级
    • 没有验证:Dubbo 与 Spring Boot 4 的整合(starter 是否可用);带注册中心(Nacos / ZooKeeper)与服务治理;protobuf / IDL 方式的 Triple 与 gRPC 互通(见 gRPC 一文);Netty 或 Spring MVC 的 HTTP 服务端作为对照;TLS 下的握手成本;序列化的兼容性(新增字段、字段类型变化);tri 协议超时后默认只执行 1 次的原因;流式调用;负载均衡与集群容错的其他策略
    京ICP备2026067502号-1京公网安备11010502063487号