Dubbo将与开源中国共同策划【Dubbo云母语之路】系列文章，与大家一起回顾Apache Dubbo产品和社区的发展，展望未来的发展。
系列文章主要涵盖对Dubbo技术的解读、社区运营、应用案例的解析三大部分。 本篇是系列第四篇。
系列文章：
Dubbo云母语之路
云母语的重要一步——dubbo3APP级服务发现
Dubbo 3.0主动重构spring云服务治理
作者|郭浩(冷松鼠)阿里巴巴经济区块RPC框架负责人
协议是RPC的基础。 数据在连接上以什么格式传输，服务端如何决定接收到的请求的大小，在同一连接上是否可以同时存在多个请求，如果请求错误，应该如何响应……所有这些都是协议
从定义上讲，协议通过定义规则、格式和语义来约定数据在网络之间的传输方式。 RPC需要通信的两端能够识别相同的协议。
数据在互联网上以比特流的方式传输，如果本地协议不被对等方识别，对等方就无法从请求中获得有用的信息，只能和鸡谈鸭，无法实现上层的业务需求。
简单的协议需要定义数据交换格式、协议格式和请求方法。
数据交换格式在RPC中也称为串行化格式。 常用的排序有JSON/Protobuf/Hessian等，评价排序的优劣一般来自三个维度：
在选择序列化方案时，根据特定的需要，在这三个维度上相互取舍序列化的字节数组大小序列化和反序列化速率序列化的可读性协议。 序列化数组越小，越节省网络通信量，但序列化过程可能需要较长的时间。
基于文本的序列化方法(如JSONXML )通常容易被开发人员接受。 因为，与一系列字节数组相比，文本更容易理解，在各层的设备上也比较容易识别。 但是，可读性提高的结果是性能大幅下降。
协议格式与RPC框架密切相关，按功能分为两种。 一个是紧凑的协议，只提供用于调用的简单元数据和数据内容。 另一种是复杂类型的协议，通过携带框架层的元数据来提供增强功能。 这样的协议的代表之一是r插座。
请求方式与协议形式密切相关，常见的请求形式有同步请求/响应和异步请求/响应。 区别在于，客户端发出请求后，是否需要同步等待响应的返回。
如果不需要等待响应，一个链接可以同时存在多个未完成的请求。 这也称为多路复用。 另外，请求模型中有Streaming，一次完整的业务呼叫中存在多次RPC，每次都会传输部分数据，因此适合传输流数据。
有了这三个基本约定，就可以实现简单的RPC协议。
Dubbo3的核心内容之一是定义新一代RPC协议。 除了基本的通信功能之外，新协议还需要以下特性：
统一的多语言二进制格式，便于扩展对流和APP层全双工调用模型的支持
层设备识别这里我们对比一些常用的协议，来探索新协议的形态。
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 和 DataHTTP/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 框架将提供平滑的协议升级支持，力求尽可能少的改造代码或配置就能带来成倍的性能提升。
本文介绍了 RPC 协议的基础概念，比较了常用的一些协议，并在这些协议的优劣对比后提出了 Dubbo3.0 协议。
Dubbo3.0 协议将在易用性、跨平台、跨语言、高性能等方面取得更大的领先。预计在 2021 年 3 月，Dubbo3.0 协议将完整支持，请大家拭目以待。