RPC 协议 on Apache Dubbo

协议概述

Mon, 01 Jan 0001 00:00:00 +0000

Dubbo 作为一款 RPC 框架内置了高效的 RPC 通信协议，帮助解决服务间的编码与通信问题，目前支持的协议包括：

triple，基于 HTTP/1、HTTP/2 的高性能通信协议，100% 兼容 gRPC，支持 Unary、Streming 等通信模式；支持发布 REST 风格的 HTTP 服务。
dubbo，基于 TCP 的高性能私有通信协议，缺点是通用性较差，更适合在 Dubbo SDK 间使用；
任意协议扩展，通过扩展 protocol 可以支持任意 RPC 协议，官方生态库提供 JsonRPC、thrift 等支持。

协议选型

开发者该如何确定使用哪一种协议那？ 以下是我们从使用场景、性能、编程易用性、多语言互通等方面对多个主流协议的对比分析：

协议	性能	网关友好	流式通信	多语言支持	编程API	说明
triple	高	高	支持，客户端流、服务端流、双向流	支持（Java、Go、Node.js、JavaScript、Rust）	Java Interface、Protobuf(IDL)	在多语言兼容、性能、网关、Streaming、gRPC 等方面最均衡的协议实现，官方推荐。支持 `application/json` 格式 payload http 直接访问。
dubbo	高	低	不支持	支持（Java、Go）	Java Interface	性能最高的私有协议，但前端流量接入、多语言支持等成本较高

以下是 triple、dubbo 两个主要协议的具体开发、配置、运行态信息：

协议名称	配置值	服务定义方式	默认端口	传输层协议	序列化协议	是否默认
triple	tri	- Java Interface - Java Interface+SpringWeb注解 - Java Interface+JaxRS注解 - Protobuf(IDL)	50051	HTTP/1、HTTP/2	Protobuf Binary、Protobuf-json	否
dubbo	dubbo	- Java Interface	20880	TCP	Hessian、Fastjson2、JSON、JDK、Avro、Kryo 等	是

注意

自 3.3 版本开始，triple 协议支持以 rest 风格发布标准的 http 服务，因此框架中实际已不存在独立的 rest protocol 扩展实现，
考虑到对过往版本的兼容性，当前 Dubbo 各个发行版本均默认使用 dubbo 通信协议。对于新用户而言，我们强烈建议在一开始就明确配置使用 triple 协议，老用户也尽快参考文档实现协议的平滑迁移。

多协议扩展

以下是当前 Dubbo 官方生态库提供的拓展协议实现。如果要扩展更多自定义协议，请参考 SPI 扩展手册或使用教程 - 协议扩展。

协议概述

Mon, 01 Jan 0001 00:00:00 +0000

请参考文档其他部分了解 triple 协议规范规范和基本使用方式。本文只展开 triple 协议 Java 实现中的一些具体细节内容。

编程模式

使用 triple 协议时，开发者可以使用 Java Interface、Protobuf(IDL) 两种方式定义 RPC 服务，两种服务定义方式的协议能力是对等的，仅影响开发者的编程体验、序列化方式，具体选用那种开发模式，取决于使用者的业务背景。

Java接口

适合于 Dubbo 老用户、没有跨语言诉求的开发团队，具备学习成本低的优势，Dubbo2 老用户可以零成本切换到该协议。

服务定义范例：

public interface DemoService {
 String sayHello(String name);
}

这种模式下，序列化方式可以选用 Hessian、JSON、Kryo、JDK、自定义扩展等任意编码协议。在使用体验上，可以说与老版本 dubbo 协议没有任何区别，只需要改一个 protocol 配置项即可，因此对于 dubbo 协议迁移到 triple 也会更平滑。

请通过【进阶学习 - 通信协议】查看 java Interface + Triple 协议的具体使用示例。

Protobuf

使用 Protobuf(IDL) 的方式定义服务，适合于当前或未来有跨语言诉求的开发团队，同一份 IDL 服务可同时用于 Java/Go/Node.js 等多语言微服务开发，劣势是学习成本较高。

syntax = "proto3";
option java_multiple_files = true;
package org.apache.dubbo.springboot.demo.idl;

message GreeterRequest {
 string name = 1;
}
message GreeterReply {
 string message = 1;
}

service Greeter{
 rpc greet(GreeterRequest) returns (GreeterReply);
}

通过 Dubbo 提供的 protoc 编译插件，将以上 IDL 服务定义预编译为相关 stub 代码，其中就包含 Dubbo 需要的 Interface 接口定义，因此在后续编码上区别并不大，只不过相比于前面的用户自定义 Java Interface 模式，这里由插件自动帮我们生成 Interface 定义。

Dubbo协议

Mon, 01 Jan 0001 00:00:00 +0000

Dubbo 缺省协议采用单一长连接和 NIO 异步通讯，适合于小数据量大并发的服务调用，以及服务消费者机器数远大于服务提供者机器数的情况。dubbo RPC是dubbo体系中最核心的一种高性能、高吞吐量的远程调用方式，我喜欢称之为多路复用的TCP长连接调用。

主要用于两个dubbo系统之间作远程调用，特别适合高并发、小数据的互联网场景。反之，Dubbo 缺省协议不适合传送大数据量的服务，比如传文件，传视频等，除非请求量很低。

长连接：避免了每次调用新建TCP连接，提高了调用的响应速度。
多路复用：单个TCP连接可交替传输多个请求和响应的消息，降低了连接的等待闲置时间，从而减少了同样并发数下的网络连接数，提高了系统吞吐量。

Transporter: mina, netty, grizzy
Serialization: dubbo, hessian2, java, json
Dispatcher: all, direct, message, execution, connection
ThreadPool: fixed, cached

缺省协议，使用基于 netty 3.2.5.Final 和 hessian2 3.2.1-fixed-2(Alibaba embed version) 的 tbremoting 交互。

连接个数：单连接
连接方式：长连接
传输协议：TCP
传输方式：NIO 异步传输
序列化：Hessian 二进制序列化
适用范围：传入传出参数数据包较小（建议小于100K），消费者比提供者个数多，单一消费者无法压满提供者，尽量不要用 dubbo 协议传输大文件或超大字符串。
适用场景：常规远程服务方法调用

约束

参数及返回值需实现 Serializable 接口
参数及返回值不能自定义实现 List, Map, Number, Date, Calendar 等接口，只能用 JDK 自带的实现，因为 hessian 会做特殊处理，自定义实现类中的属性值都会丢失。
Hessian 序列化，只传成员属性值和值的类型，不传方法或静态变量，兼容情况由吴亚军提供

数据通讯	情况	结果
A->B	类A多一种属性（或者说类B少一种属性）	不抛异常，A多的那个属性的值，B没有，其他正常
A->B	枚举A多一种枚举（或者说B少一种枚举）	A使用多出来的枚举进行传输
A->B	枚举A多一种枚举（或者说B少一种枚举）	A不使用多出来的枚举进行传输
A->B	A和B的属性名相同，但类型不相同	抛异常
A->B	serialId 不相同	正常传输

接口增加方法，对客户端无影响，如果该方法不是客户端需要的，客户端不需要重新部署。输入参数和结果集中增加属性，对客户端无影响，如果客户端并不需要新属性，不用重新部署。

多协议

Mon, 01 Jan 0001 00:00:00 +0000

区别于普通的 RPC 框架，Dubbo 作为一款微服务框架提供了非常灵活的协议支持，它不绑定一个单一通信协议。因此你可以发布在一个进程中同时发布多个 RPC 协议、调用不同的 RPC 协议。接下来我们就详细介绍多协议的具体使用场景与使用方式。

使用场景

有很多场景可能会用到不同的协议，包括安全性、性能、与第三方系统互调等业务诉求。本文我们不分析具体的业务需求，而是从 Dubbo 框架提供的多协议能力出发分析框架能提供的多协议能力：

作为服务提供者（provider），同一个服务发布为多个协议，供不同消费端调用
作为服务提供者（provider），多个服务分别发布为不同协议，供不同消费端调用
作为服务消费者（consumer），指定以某个特定协议调用某一个服务

使用方式

同一个服务发布为多个协议

如果使用 Spring Boot，可以修改 application.yml 或 application.properties 如下：

dubbo:
 protocols:
 dubbo-id:
 name: dubbo
 port: 20880
 tri-id:
 name: tri
 port: 50051

对于 Spring XML：

<dubbo:protocol id="dubbo-id" name="dubbo" port="20880"/>
<dubbo:protocol id="triple-id" name="tri" port="50051"/>

接下来为服务配置（默认不配置的情况下，服务会发布到以上所有协议配置）：

@DubboService(protocol="dubbo-id,triple-id")
private DemoServiceImpl implements DemoService {}

多个服务分别发布为不同协议

如果使用 Spring Boot，可以修改 application.yml 或 application.properties 如下：

dubbo:
 protocols:
 dubbo-id:
 name: dubbo
 port: 20880
 tri-id:
 name: tri
 port: 50051

接下来为不同的服务分别配置不同的协议引用：

Tripe 3.3 新特性

Mon, 01 Jan 0001 00:00:00 +0000

全新的 Rest 支持

特性

在3.3版本中，基于现有 HTTP 协议栈，triple实现了全面的 REST 风格服务导出能力，无需使用泛化或网关层协议转换，无需配置，用户即可通过 HTTP 协议去中心化直接访问后端的 Triple 协议服务。同时，针对高级 REST 用法，如路径定制、输出格式定制和异常处理，提供了丰富的注解和 SPI 扩展支持。其主要特性包括：

Triple协议融合
重用Triple原有HTTP协议栈，无需额外配置或新增端口，即可同时支持 HTTP/1、HTTP/2 和 HTTP/3 协议的访问。
去中心化
可直接对外暴露 Rest API，不再依赖网关应用进行流量转发，从而提升性能，并降低因网关引发的稳定性风险。安全问题可通过应用内部扩展解决，这一实践已在淘宝内部的 MTOP 中得到验证。
支持已有servlet设施
支持 Servlet API 和 Filter，用户可以重用现有基于 Servlet API 的安全组件。通过实现一个 Servlet Filter，即可集成 OAuth 和 Spring Security 等安全框架。
多种方言
考虑到大部分用户习惯使用 SpringMVC 或 JAX-RS 进行 REST API 开发，Triple Rest 允许继续沿用这些方式定义服务，并支持大部分扩展和异常处理机制（具备原框架 80% 以上的功能）。对于追求轻量级的用户，可使用 Basic 方言，Triple 的开箱即用 REST 访问能力即基于此方言导出服务。
扩展能力强
提供超过 20 个扩展点，用户不仅可以轻松实现自定义方言，还能灵活定制参数获取、类型转换、错误处理等逻辑。
开箱即用
REST 能力开箱即用，只需启用 Triple 协议，即具备 REST 直接访问服务能力。
高性能路由
路由部分采用优化的 Radix Tree 和 Zero Copy 技术，提升路由性能。
OpenAPI无缝集成(TBD)
即将完成 OpenAPI 集成，开箱即用支持导出 OpenAPI Schema，引入 Swagger 依赖可直接使用 Web UI 来进行服务测试。有了 OpenAPI Schema 可使用 Postman、Apifox 等API工具来管理和测试 API，利用 OpenAPI 生态可轻松实现跨语言调用。未来会进一步支持 Schema First 的方式，先和前端团队一起定义 OpenAPI, 前端基于 OpenAPI 来生成调用代码和 Mock，后端基于 OpenAPI 来生成 Stub 来开发服务，极大提升协同效率。

示例

Triple 协议背压机制

Mon, 01 Jan 0001 00:00:00 +0000

概述

背压（Backpressure）是流式通信中的核心机制，用于协调数据生产者和消费者之间的速率差异。当消费者处理数据的速度跟不上生产者发送数据的速度时，背压机制能够通知生产者放慢发送速度，从而防止内存溢出和系统崩溃。

Triple 协议基于 HTTP/2 构建，天然支持流式通信。在 Dubbo 3.3.7 版本中，Triple 协议新增了完整的背压支持，提供了与 gRPC 兼容的 API，使开发者能够精细控制流式调用中的数据发送和接收速率。

核心概念

背压类型

Triple 协议支持两种类型的背压控制：

背压类型	描述	控制方向
发送端背压（Send-Side Backpressure）	控制数据发送速率，避免发送方发送过快导致接收方缓冲区溢出	出站流量控制
接收端背压（Receive-Side Backpressure）	控制数据接收速率，让接收方按自己的处理能力请求数据	入站流量控制

核心 API

Dubbo 提供了一套与 gRPC 兼容的背压 API，位于 org.apache.dubbo.common.stream 包下：

API	描述
`CallStreamObserver<T>`	背压控制的基础接口，提供 `isReady()`、`setOnReadyHandler()` 等方法
`ClientCallStreamObserver<ReqT>`	客户端背压控制接口，继承自 `CallStreamObserver`，增加 `disableAutoRequestWithInitial()` 方法
`ServerCallStreamObserver<RespT>`	服务端背压控制接口，继承自 `CallStreamObserver`，增加 `disableAutoRequest()` 方法
`ClientResponseObserver<ReqT, RespT>`	客户端响应观察者，通过 `beforeStart()` 回调配置背压

API 分类

背压 API 按使用场景分为高级 API 和低级 API：

高级 API（发送端背压）

isReady() - 检查流是否准备好接收更多数据
setOnReadyHandler(Runnable) - 设置流变为可写状态时的回调

低级 API（接收端背压）

Triple Rest 用户手册

Mon, 01 Jan 0001 00:00:00 +0000

注意

从 Dubbo 3.3 版本开始，原 Rest 协议已移至 Extensions 库，由 Triple 协议来对 Rest 提供更全面的支持，如需继续使用原 Rest 协议，可引入对应 dubbo-spi-extensions 库依赖

前言

从 Dubbo 3.3 版本开始，Triple 协议重用已有的 HTTP 协议栈，实现了全面的 REST 风格服务导出能力。无需使用泛化或网关层协议转换，无需配置，用户即可通过 HTTP 协议去中心化直接访问后端的 Triple 协议服务。同时，针对高级 REST 用法，如路径定制、输出格式定制和异常处理，提供了丰富的注解和 SPI 扩展支持。其主要特性包括：

Triple协议融合
重用Triple原有HTTP协议栈，无需额外配置或新增端口，即可同时支持 HTTP/1、HTTP/2 和 HTTP/3 协议的访问。
去中心化
可直接对外暴露 Rest API，不再依赖网关应用进行流量转发，从而提升性能，并降低因网关引发的稳定性风险。安全问题可通过应用内部扩展解决，这一实践已在淘宝内部的 MTOP 中得到验证。
支持已有servlet设施
支持 Servlet API 和 Filter，用户可以重用现有基于 Servlet API 的安全组件。通过实现一个 Servlet Filter，即可集成 OAuth 和 Spring Security 等安全框架。
多种方言
考虑到大部分用户习惯使用 SpringMVC 或 JAX-RS 进行 REST API 开发，Triple Rest 允许继续沿用这些方式定义服务，并支持大部分扩展和异常处理机制（具备原框架 80% 以上的功能）。对于追求轻量级的用户，可使用 Basic 方言，Triple 的开箱即用 REST 访问能力即基于此方言导出服务。
扩展能力强
提供超过 20 个扩展点，用户不仅可以轻松实现自定义方言，还能灵活定制参数获取、类型转换、错误处理等逻辑。
开箱即用
REST 能力开箱即用，只需启用 Triple 协议，即具备 REST 直接访问服务能力。
高性能路由
路由部分采用优化的 Radix Tree 和 Zero Copy 技术，提升路由性能。
OpenAPI无缝集成(TBD)
即将完成 OpenAPI 集成，开箱即用支持导出 OpenAPI Schema，引入 Swagger 依赖可直接使用 Web UI 来进行服务测试。有了 OpenAPI Schema 可使用 Postman、Apifox 等API工具来管理和测试 API，利用 OpenAPI 生态可轻松实现跨语言调用。未来会进一步支持 Schema First 的方式，先和前端团队一起定义 OpenAPI, 前端基于 OpenAPI 来生成调用代码和 Mock，后端基于 OpenAPI 来生成 Stub 来开发服务，极大提升协同效率。

快速开始

让我们从一个简单的例子开始了解 Triple Rest。您可以直接下载已有的示例项目以快速上手，假设您已经安装好 Java、Maven 和 Git