全新升级的 Triple 协议
Apache Dubo
在微服务协议选型方面我们看到越来越多的应用从 Dubbo2 TCP 二进制协议迁移到 Dubbo3 Triple 协议 (兼容 gRPC),以充分利用 Triple 的高效、全双工、Streaming 流式通信模型等能力;Triple+HTTP/2 的组合很好的解决了后端服务穿透性等问题,但在阿里及众多社区企业的实践中,我们发现基于 Triple 构建的微服务对于前端设备接入成本仍然比较高,用户需要通过网关协议转换来接入 Triple 后端服务(类似之前 Dubbo2 泛化调用),对于开发测试、运维等成本都非常高。
基于以上背景,我们对 Dubbo3 中的 Triple 协议进行了全面升级:Triple 协议是 Dubbo3 设计的基于 HTTP 的 RPC 通信协议规范,它完全兼容 gRPC 协议,支持 Request-Response、Streaming 流式等通信模型,可同时运行在 HTTP/1 和 HTTP/2 之上。
curl \
--header "Content-Type: application/json" \
--data '{"sentence": "Hello Dubbo."}' \
https://host:port/org.apache.dubbo.sample.GreetService/sayHello
基于 Triple 协议,你可以轻松地构建 Dubbo 后端微服务体系,由于 Triple 面向 HTTP 协议的易用性设计,前端设备如 Web、Mobile、标准 HTTP 等可以更轻松的接入后端体系,同时,Triple 与 gRPC 协议完全兼容性可实现与 gRPC 体系的互通。

Dubbo 框架提供了 Triple 协议的多种语言实现,它们可以帮助你构建浏览器、gRPC 兼容的 HTTP API 接口:你只需要定义一个标准的 Protocol Buffer 格式的服务并实现业务逻辑,Dubbo 负责帮助生成语言相关的 Server Stub、Client Stub,并将整个调用流程无缝接入如路由、服务发现等 Dubbo 体系。针对某些语言版本,Dubbo 框架还提供了更贴合语言特性的编程模式,即不绑定 IDL 的服务定义与开发模式,比如在 Dubbo Java 中,你可以选择使用 Java Interface 和 Pojo 类定义 Dubbo 服务,并将其发布为基于 Triple 协议通信的微服务。
协议设计目标与适用场景
Apache Dubo
基于 Triple 协议,你可以实现以下目标:
调用标准 gRPC 服务端,发送 Content-type 为标准 gRPC 类型的请求:application/grpc, application/grpc+proto, and application/grpc+json
-
调用 Dubbo 服务端,发送 Content-type 为 Triple 类型的请求:application/json, application/proto, application/triple+wrapper
处理 gRPC 客户端发送的 Content-type 为标准 gRPC 类型的请求:application/grpc、application/grpc+proto、application/grpc+json
处理 Dubbo 客户端发送的 Content-type 为 Triple 类型的请求:application/json、application/proto、application/grpc+wrapper
-
处理 cURL、浏览器等发送的 Content-type 为 Triple 类型的请求:application/json、application/proto、application/grpc+wrapper



协议规范(Specification)
Apache Dubbo
与 gRPC 协议的关系详解
Apache Dubbo
上面提到 Triple 完全兼容 gRPC 协议,那既然 gRPC 官方已经提供了多语言的框架实现,为什么 Dubbo 还要通过 Triple 重新实现一遍那?核心目标主要有以下两点:
首先,在协议设计上,Dubbo 参考 gRPC 与 gRPC-Web 两个协议设计了自定义的 Triple 协议:Triple 是一个基于 HTTP 传输层协议的 RPC 协议,它完全兼容 gRPC 的同时可运行在 HTTP/1、HTTP/2 之上。
-
其次,Dubbo 框架在每个语言的实现过程中遵循了符合框架自身定位的设计理念,相比于 grpc-java、grpc-go 等框架库,Dubbo 协议实现更简单、更纯粹,尝试在实现上规避 gRPC 官方库中存在的一系列问题。
gRPC 本身作为 RPC 协议规范非常优秀,但原生的 gRPC 库实现在实际使用存在一系列问题,包括实现复杂、绑定 IDL、难以调试等,Dubbo 在协议设计与实现上从实践出发,很好的规避了这些问题:
原生的 gRPC 实现受限于 HTTP/2 交互规范,无法为浏览器、HTTP API 提供交互方式,你需要额外的代理组件如 grpc-web、grpc-gateway 等才能实现。在 Dubbo 中,你可以直接用 curl、浏览器访问 Triple 协议服务.
gRPC 官方库强制绑定 Protocol Buffers,唯一的开发选择就是使用 IDL 定义和管理服务,这对于一些多语言诉求不强的用户是一个非常大的使用负担。Dubbo 则在支持 IDL 的同时,为 Java、Go 等提供了语言特有的服务定义与开发方式。
在开发阶段,以 gRPC 协议发布的服务非常难以调试,你只能使用 gRPC 特定的工具来进行,很多工具都比较简陋 & 不成熟。而从 Dubbo3 开始,你可以直接使用 curl | jq 或者 Chrome 开发者工具来调试你的服务,直接传入 JSON 结构体就能调用服务。
首先,gRPC 协议库有超过 10 万行代码的规模,但 Dubbo (Go、Java、Rust、Node.js 等) 关于协议实现部分仅有几千行代码,这让代码维护和问题排查变得更简单。
谷歌提供的 gRPC 实现库没有使用主流的第三方或语言官方协议库,而是选择自己维护了一套实现,让整个维护与生态扩展变得更加复杂。比如 grpc-go 自己维护了一套 HTTP/2 库而不是使用的 go 官方库。Dubbo 使用了官方库的同时,相比 gRPC 自行维护的 http 协议库维持了同一性能水准。
-
gRPC 库仅仅提供了 RPC 协议实现,需要你做很多额外工作为其引入服务治理能力。而 Dubbo 本身是不绑定协议的微服务开发框架,内置 HTTP/2 协议实现可以与 Dubbo 服务治理能力更好的衔接在一起。
curl \
--header "Content-Type: application/json" \
--data '{"sentence": "Hello Dubbo."}' \
https://host:port/org.apache.dubbo.sample.GreetService/sayHello
多语言实现
ApacheDubo
基于 Triple 协议设计,我们计划为尽可能多的语言提供轻量的 RPC 协议实现,让 Triple 协议互通可以完整的覆盖多套语言栈,与 gRPC 兼容且具备更好的易用性。同时,Dubbo 会继续在一些被广泛用于微服务开发的语言(如Java、Go等)提供完善的微服务治理能力,让 Dubbo 成为一套可以连接前后端的微服务开发体系。
另外,Java 版本的协议实现在性能上与 grpc-java 库基本持平,甚至某些场景下比 grpc-java 性能表现还要出色。而这一切还是建立在 Dubbo 版本协议的实现复杂度远小于 gRPC 版本的情况下,因为 grpc-java 维护了一套定制版本的 HTTP/2 协议实现。
Dubbo Rust 已经完整实现了 gRPC 协议兼容部分,目前正在推进 HTTP/1 等模式下的 unary RPC 调用支持。
Node.js 语言已经完整实现了 gRPC 协议兼容部分,目前正在推进 HTTP/1 等模式下的 unary RPC 调用支持。
总结
Apache Dubbo
欢迎大家持续关注,对这部分建设感兴趣的开发者,请搜索钉钉群号:37290003945 加入 ApacheDubbo 社区交流群持续关注各个项目开发进展,探索构建基于 HTTP 的高效且具备高度易用性的项目。
[1] Triple Specification
https://cn.dubbo.apache.org/zh-cn/overview/reference/protocols/triple-spec/
[2] 互操作性示例
本文分享自微信公众号 - Apache Dubbo(ApacheDubbo)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。