Dubbo 与开源中国共同策划【Dubbo 云原生之路】系列文章，和你们一块儿回顾 Apache Dubbo 产品和社区的发展，并展望将来发展。系列文章主要涵盖 Dubbo 技术解读、社区运营、应用案例解析三大部分。本篇为系列第四篇。redis

系列文章：json

Dubbo 云原生之路数组

Dubbo 3.0 前瞻之：应用级服务发现缓存

Dubbo 3.0 前瞻之：重塑 Spring Cloud 服务治理安全

做者 | 郭浩（项升）阿里巴巴经济体 RPC 框架负责人

协议是 RPC 的基础。数据在链接上以什么格式传输，服务端如何肯定收到请求的大小，同一个链接上能不能同时存在多个请求，请求若是出错了应该怎么响应……这些都是须要协议解决的问题。网络

从定义上讲，协议经过定义规则、格式和语义来约定数据如何在网络间传输。RPC 须要通讯的两端都可以识别同一种协议。数据在网络上以比特流的方式传输，若是本端的协议对端不识别，对端就没法从请求中获取到有用信息，就会出现鸡同鸭讲的状况，没法实现上层的业务需求。负载均衡

一个简单的协议须要定义数据交换格式，协议格式和请求方式。框架

数据交换格式在 RPC 中也叫作序列化格式。经常使用的序列化有 JSON/Protobuf/Hessian 等，评价序列化优劣通常从三个维度：异步

序列化后的字节数组大小
序列化和反序列化速度
序列化后的可读性

协议在选取序列化方式时，按照具体的需求在这三个维度中互相取舍。序列化后的数组越小，越节省网络流量，但序列化过程可能更消耗时间。JSON\XML 这类基于文本的序列化方式每每更容易被开发者接受，由于相比于一连传的字节数组，文本更容易被理解，在各层设备中都能比较容易的识别，但可读性提升的后果是性能大幅下降。分布式

协议格式是和 RPC 框架紧密相关的，按照功能划分有两种，一种是紧凑型协议，只提供用于调用的简单元数据和数据内容。另一种是复合型协议，会携带框架层的元数据用来提供功能上的加强，这类协议的一个表明就是 RSocket。

请求方式和协议格式息息相关，常见的请求格式有同步 Request/Response 和异步 Request/Response，区别是客户端发出一个请求后，是否须要同步等待响应返回。若是不须要等待响应，一个连接上就能够同时存在多个未完成的请求，这也被叫作多路复用。另外的请求模型有 Streaming ，在一次完整的业务调用中存在屡次 RPC，每次都传输一部分数据，适合流数据传输。

有了这三个基本约定，就能实现一个简单的 RPC 协议了。

Dubbo3 的一个核心内容就是定义下一代 RPC 协议。除了基础的通讯功能，新协议还应该具备如下特性：

统一的跨语言二进制格式
支持 Streaming 和应用层全双工调用模型
易于扩展
可以被各层设备识别

这里咱们对比一些经常使用的协议，来探索新协议的形态。

HTTP/1.1

HTTP/1.1 应该是应用最普遍的协议，简单清晰的语法，跨语言以及对原生移动端的支持都让其成为了事实上最被普遍接受的 RPC 方案。

然而从 RPC 协议的诉求上讲， HTTP1.1 主要有如下几个问题

队头阻塞(HOL)致使其在单链接的性能低下，尽管支持了 pipeline 但仍没法避免响应按序返回
基于文本的协议每次请求都会重复携带不少繁杂无用的头部信息，浪费带宽影响性能
纯粹的 Request/Response 请求模型，没法实现 Server Push，只能依靠客户端轮询，一样 Streaming 的全双工也是不安全的

RESP

RESP 是 Redis 使用的通讯协议，其简洁易于理解的格式也助力了 Redis 各语言客户端的快速发展。可是这种相似 HTTP/1.1 的协议也存在着一样的性能问题。

序列化表达能力弱，一般还须要借助其余序列化方式辅助，然而协议中又不支持设置特定序列化方式，只能依靠客户端约定
一样存在队头阻塞问题，pipeline 没法从根本上解决单链接性能问题
Pub/Sub 在单链接状况下也有数量瓶颈

Dubbo2.0

Dubbo2.0 协议直接定义在 TCP 传输层协议上，为协议功能定义提供了最大的灵活性，但同时也正是由于这样明显的灵活性优点，RPC 协议广泛都是定制化的私有协议。

Dubbo 协议体 Body 中有一个可扩展的 attachments 部分，这给 RPC 方法以外额外传递附加属性提供了可能，是一个很好的设计。可是相似的 Header 部分，却缺乏相似的可扩展 attachments，这点可参考 HTTP 定义的 Ascii Header 设计，将 Body Attachments 和 Header Attachments 作职责划分。

Body 协议体中的一些 RPC 请求定位符如 Service Name、Method Name、Version 等，能够提到 Header 中，和具体的序列化协议解耦，以更好的被网络基础设施识别或用于流量管控
扩展性不够好，欠缺协议升级方面的设计，如 Header 头中没有预留的状态标识位，或者像 HTTP 有专为协议升级或协商设计的特殊 packet
在 Java 版本的代码实现上，不够精简和通用。如在链路传输中，存在一些语言绑定的内容；消息体中存在冗余内容，如 Service Name 在 Body 和 Attachments 中都存在

HTTP/2.0

HTTP/2.0 保留了 HTTP/1 的全部语义，在保持兼容的同时，在通讯模型和传输效率上作了很大的改进，主要也是为了解决 HTTP/1 中的问题。

支持单条链路上的 Multiplexing，相比于 Request - Response 独占链路，基于 Frame 实现更高效利用链路，StreamId 提供了上下文状态，client 能够根据 StreamId 支持乱序 Response 返回
头部压缩 HPACK，基于静态表和动态表实现了 Header 缓存，减小传输数据量
Request - Stream 语义，原生支持 Server Push 和 Stream 数据传输
Binary Frame，二进制分帧，能够单独处理 Header 和 Data

HTTP/2.0 虽然克服了以上问题，但也存在着一些争议点，好比在 TCP 的上层进行流量控制的必要性以及对 HTTP 语义经过 HPACK 兼容是否过于繁琐复杂。

gRPC

相比较于一些框架将应用层协议构建在裸 TCP 上，gRPC 选择了 HTTP/2.0 做为传输层协议。经过对 Header 内容和 Payload 格式的限定实现上层协议功能。下面是 gRPC 的一些设计理念。

Coverage & Simplicity，协议设计和框架实现要足够通用和简单，能运行在任何设备之上，甚至一些资源首先的如 IoT、Mobile 等设备
Interoperability & Reach，要构建在更通用的协议之上，协议自己要能被网络上几乎全部的基础设施所支持
General Purpose & Performant，要在场景和性能间作好平衡，首先协议自己要是适用于各类场景的，同时也要尽可能有高的性能
Payload Agnostic，协议上传输的负载要保持语言和平台中立
Streaming，要支持 Request - Response、Request - Stream、Bi-Steam 等通讯模型
Flow Control，协议自身具有流量感知和限制的能力
Metadata Exchange，在 RPC 服务定义以外，提供额外附加数据传输的能力

在这样的设计理念指导下，gRPC 最终被设计为一个跨语言、跨平台的、通用的协议。功能上基本已经彻底具有或能够轻易扩展出须要的新功能。然而咱们知道，软件工程没有银弹，相比较于裸 TCP 专有协议，极限性能上 gRPC 确定是要差一些。可是对大部分应用来讲，相比较于 HTTP/1.1 的协议，gRPC/HTTP2 已经在性能上取得了很大的进步，同时又兼顾了可读性。

序列化上，gRPC 被设计成保持 payload 中立，但实际的跨语言场景须要一个强规范的接口定义语言来保证序列化结果的一致。在 gRPC 的官方实现中，protobuf 和 json 分别用来支持性能场景和开发效率场景。从序列化方式的选择到协议的各维度比较，基于 gRPC 扩展出新的协议是最优的选择。

Dubbo3.0

Dubbo3.0 的协议基于 gRPC ，在应用层、异常处理、协议层负载均衡支持和 Reactive 支持上提供了扩展。主要有三个目标：

在分布式大规模集群场景下，提供更完善的负载均衡，以获取更高性能和保证稳定性
支持 tracing/monitoring 等分布式标准扩展，支持微服务标准化以及平滑迁移
Reactive 语义在协议层加强，可以提供分布式 back-pressure 能力和更完善的 Streaming 支持

除了协议层的支持，Dubbo3.0 新协议还包括易用性方面的支持，包括同时支持 IDL compiler 和 Annotation Compiler。客户端将更完善的支持原生异步回调，Future 异步和同步调用。服务端将使用非反射调用。这将十分显著的提高客户端和服务端性能。从用户迁移的角度，Dubbo 框架将提供平滑的协议升级支持，力求尽量少的改造代码或配置就能带来成倍的性能提高。