共计 3834 个字符，预计需要花费 10 分钟才能阅读完成。
作者 | 郭浩（项升）阿里巴巴经济体 RPC 框架负责人
导读：Dubbo 社区策动了【Dubbo 云原生之路】系列文章，和大家一起回顾 Apache Dubbo 产品和社区的倒退，并展望未来倒退。系列文章次要涵盖 Dubbo 技术解读、社区经营、利用案例解析三大部分。本文为系列第 4 篇。
前言
协定是 RPC 的根底。数据在连贯上以什么格局传输，服务端如何确定收到申请的大小，同一个连贯上能不能同时存在多个申请，申请如果出错了应该怎么响应……这些都是须要协定解决的问题。
从定义上讲，协定通过定义规定、格局和语义来约定数据如何在网络间传输。RPC 须要通信的两端都可能辨认同一种协定。数据在网络上以比特流的形式传输，如果本端的协定对端不辨认，对端就无奈从申请中获取到有用信息，就会呈现鸡同鸭讲的状况，无奈实现下层的业务需要。
一个简略的协定须要定义数据替换格局，协定格局和申请形式。
数据交换格局在 RPC 中也叫做序列化格局。罕用的序列化有 JSON / Protobuf / Hessian 等，评估序列化优劣个别从三个维度：
- 序列化后的字节数组大小
- 序列化和反序列化速度
- 序列化后的可读性
协定在选取序列化形式时，依照具体的需要在这三个维度中相互取舍。序列化后的数组越小，越节俭网络流量，但序列化过程可能更耗费工夫。JSONXML 这类基于文本的序列化形式往往更容易被开发者承受，因为相比于一连传的字节数组，文本更容易被了解，在各层设施中都能比拟容易的辨认，但可读性进步的结果是性能大幅升高。
协定格局是和 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 框架将提供平滑的协定降级反对，力求尽可能少的革新代码或配置就能带来成倍的性能晋升。
系列文章：
- Dubbo 云原生之路：ASF 毕业一周年、3.0 可期
- Dubbo 迈出云原生重要一步 – 利用级服务发现解析
总结
本文介绍了 RPC 协定的根底概念，比拟了罕用的一些协定，并在这些协定的优劣比照后提出了 Dubbo3.0 协定。Dubbo3.0 协定将在易用性、跨平台、跨语言、高性能等方面获得更大的当先。预计在 2021 年 3 月，Dubbo3.0 协定将残缺反对，请大家刮目相待。
“阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术畛域、聚焦云原生风行技术趋势、云原生大规模的落地实际，做最懂云原生开发者的公众号。”
