Dubbo是阿里开源的的rpc框架，现已成为Apache的顶级项目。Dubbo在国内的大公司中使用较多，具有良好的服务治理能力。
在阿里停止维护一段时间后，2017年又重新开始维护，2.x的最新版本为2.7版本。2021年Dubbo更新到了3.0版本，相对于2.x版本，有了巨大的变化。博主将通过两篇文章分别对dubbo2和dubbo3进行简单的介绍，本文主要介绍dubbo3。

RPC框架原理与实践
Dubbo原理与实践(1)
Dubbo原理与实践(2)

---

dubbo3服务发现

dubbo3 与 dubbo2 的服务发现配置是完全一致的，不需要改动什么内容。

但就实现原理上而言，dubbo3 引入了全新的服务发现模型，即应用级服务发现(dubbo2是接口级的)， 在工作原理、数据格式上已完全不能兼容老版本服务发现。

dubbo3 格式的 Provider 地址不能被 dubbo2 的 Consumer 识别到，反之 Dubbo2 的消费者也不能订阅到 dubbo3的Provider。

dubbo3 默认保持了接口级地址发现的行为，这保证了dubbo2用户可以直接无感升级到 dubbo3。
而如果要开启应用级服务发现，则需要通过配置显式开启（双注册、双订阅）。

应用级服务发现

概括来说，dubbo3 引入的应用级服务发现主要有以下优势：

• 适配云原生微服务变革。云原生时代的基础设施能力不断向上释放，像 Kubernetes 等平台都集成了微服务概念抽象，dubbo3 的应用级服务发现是适配各种微服务体系的通用模型。
• 提升性能与可伸缩性。支持超大规模集群的服务治理一直以来都是 dubbo 的优势，通过引入应用级服务发现模型，从本质上解决了注册中心地址数据的存储与推送压力，相应的 Consumer 侧的地址计算压力也成数量级下降；集群规模也开始变得可预测、可评估（与 RPC 接口数量无关，只与实例部署规模相关）。

下面举个例子来说明dubbo3 服务发现模型在性能提升和可伸缩性方面的优势：

假设一个微服务应用定义了 100 个接口（dubbo 中的服务），则需要往注册中心中注册 100 个服务，如果这个应用被部署在了 100 台机器上，那这 100 个服务总共会产生 100 * 100 = 10000 个虚拟节点；而同样的应用， 对于 dubbo3 来说，新的注册发现模型只需要 1 个服务（只和应用有关和接口无关）， 只注册和机器实例数相等的 1 * 100 = 100 个虚拟节点到注册中心。

在这个简单的示例中，dubbo 所注册的地址数量下降到了原来的 1 / 100，对于注册中心、订阅方的存储压力都是一个极大的释放。更重要的是， 地址发现容量彻底与业务 RPC 定义解耦开来，整个集群的容量评估对运维来说将变得更加透明：部署多少台机器就会有多大负载，不会像 dubbo2 一样， 因为业务 RPC 重构就会影响到整个集群服务发现的稳定性。

通信协议

Dubbo3 提供了 Triple(dubbo3)、dubbo2 协议，这是 dubbo 框架的原生协议。

除此之外，dubbo3 也对众多第三方协议进行了集成，并将它们纳入 dubbo 的编程与服务治理体系， 包括 gRPC、Thrift、JsonRPC、Hessian2、REST 等。以下重点介绍 Triple 与 Dubbo2 协议。

为什么是Triple协议

Triple协议是dubbo3推出的主力协议，它是在dubbo1和dubbo2两代协议的基础上，适应云原生技术标准化浪潮而产生的。

RPC协议的选择

协议是rpc的核心，它规范了数据在网络中传输的内容和格式。除了必须的请求，响应数据外，通常还包括额外的控制数据，如单次请求的序列化方式、超时时间，压缩方式和鉴权信息等。

rpc协议的的设计需要考虑如下内容：

• 通用性：统一的二进制格式，跨语言，跨平台，多传输层协议支持。
• 扩展性：协议增加字段，升级，支持用户扩展和附加业务数据。
• 性能：越快越好。
• 穿透性：能够被各种终端设备识别和转发，如网关和代理服务器等。

事实上，rpc协议主要包括两部分内容，通信协议和序列化协议，具体可参见本文开头列出的rpc框架原理与实践。这里主要介绍通信协议。

RPC的通信协议可以基于tcp，也可以基于http。相比构建于tcp传输层的私有rpc通信协议，构建于http之上的通信解决方案具有更好的通用性，如webServices或者REST架构。

选择构建于http之上的rpc通信协议，有两个明显的优势：

• http语义和可扩展性能很好的满足rpc调用需求。
• 通用性强，http协议几乎被网络上的所有设备所支持，具有很好的协议穿透性。

当然，也存在比较明显的问题：

• 典型的Request-Response模型，一个链路上一次只能有一个等待的Request请求，会产生HOL(Head-of-line blocking，队首阻塞)。
• 使用更通用、更易于阅读的头部传输格式，但性能相当差。
• 无直接 Server Push 支持，需要使用 Polling，Long-Polling 等变通模式。

gRPC

dubbo2的通信协议是基于tcp的，google的gRpc则是基于http2之上。

gRpc的优势由http2和protobuf继承而来：

• 基于 http2 的协议足够简单，用户学习成本低，天然有 server push/ 多路复用 / 流量控制能力。
• 基于 Protobuf 的序列化协议则提供了多语言跨平台二进制兼容能力，可以跨语言。
• 基于协议本身的生态比较丰富，k8s/etcd 等组件的天然支持协议，云原生的事实协议标准。

但是也存在部分问题：

• 对服务治理的支持比较基础，更偏向于基础的 RPC 功能，协议层缺少必要的统一定义，对于用户而言直接用起来并不容易。
• 强绑定 protobuf 的序列化方式，需要较高的学习成本和改造成本，对于现有的偏单语言的用户而言，迁移成本不可忽视。

Dubbo3最终选择兼容 gRPC ，以 http2 为基础构建新的协议，也就是 Triple。

Triple介绍

容器化应用程序和微服务的兴起促进了针对负载内容优化技术的发展。客户端中使用的传统通信协议(Restful或其他基于HTTP的自定义协议)难以满足应用在性能、可维护性、扩展性和安全性等方面的需求。一个跨语言、模块化的协议会逐渐成为新的应用开发协议标准。自从2017年gRPC协议成为CNCF的项目后，包括k8s、etcd等越来越多的基础设施和业务都开始使用gRPC的生态，作为云原生的微服务框架，Dubbo的新协议也完美兼容了gRPC。并且，对于gRPC协议中的一些不完善的部分，Triple也将进行增强和补充。

那么，Triple协议是否解决了上面提到的一系列问题呢？

• 性能上，Triple协议采取了metadata和payload分离的策略，避免中间设备如网关进行payload的解析和反序列化，从而降低响应时间。
• 路由支持上，由于metadata支持用户添加自定义header，用户可以根据header更方便的划分集群或者进行路由，这样发布的时候切流灰度或容灾都有了更高的灵活性。
• 安全性上，支持双向TLS认证等加密传输能力。
• 易用性上，Triple除了支持原生gRPC所推荐的Protobuf序列化外，使用通用的方式支持了Hessian/JSON等其他序列化，能让用户更方便的升级到Triple协议。对原有的Dubbo服务而言，修改或增加Triple协议只需要在声明服务的代码中添加一样协议配置即可，改造成本几乎为0。

Triple协议现状

• Triple协议完整兼容gprc、客户端/服务端可以和原生grpc客户端打通。
• 目前已经经过大规模生产实践验证，达到生产级别。

Triple特点和优势

• 具备跨语言互通的能力，传统的多语言多SDK模式和Mesh化跨语言模式都需要一种更通用易扩展的数据传输格式。
• 提供更完善的请求模型，除了Request/Response模型，还应该支持Streaming和Bidirectional。
• 易扩展、穿透性高，包括但不限于Tracing/Monitoring等支持，能被各层设备识别，如网关设施等。而且对Service Mesh部署友好，降低用户理解难度。
• 多种序列化方式支持、平滑升级。
• 支持Java用户无感知升级，不需要定义繁琐的IDL文件，仅需要简单的修改协议名便可以轻松升级到Triple协议。

总结

在API领域，最重要的趋势是标准化技术的崛起。Triple协议是Dubbo3推出的主力协议。它采用分层设计，其数据交换格式基于Protobuf协议开发，具备优化的序列化/反序列化效率。当然还支持多种其他的序列化方式，支持多语言。在传输层协议上，Triple选择了HTTP/2，相较于HTTP/1.1，其传输效率有了很大提升。此外，HTTP/2作为一个成熟的开放标准，具备丰富的安全、流控等能力，同时拥有良好的互操作性。Triple不仅可以用于Server服务端调用，也可以支持浏览器、移动APP和IoT设备与后端服务的交互，同时Triple协议无缝支持Dubbo3的全部服务治理能力。

在Cloud Native的潮流下，跨平台、跨厂商、跨环境的系统间互操作性的需求必然会催生基于开发标准的RPC技术，而gRPC顺应了历史趋势，得到了越来越广泛的应用。在微服务领域，Triple协议的提出和落地，是Dubbo3迈上云原生微服务的一大步。

参考资料

[1]. https://dubbo.apache.org/zh/docs/v3.0/