Dubbo 3.0 前瞻之:常用协议对比及 RPC 协议新形态探索-阿里云开发者社区

开发者社区> 阿里巴巴云原生小助手> 正文

Dubbo 3.0 前瞻之:常用协议对比及 RPC 协议新形态探索

简介: 协议是 RPC 的基础。数据在连接上以什么格式传输,服务端如何确定收到请求的大小,同一个连接上能不能同时存在多个请求,请求如果出错了应该怎么响应……这些都是需要协议解决的问题。
+关注继续查看

头图.png

作者 | 郭浩(项升)  阿里巴巴经济体 RPC 框架负责人

【Dubbo 3.0 前瞻系列】:

导读:Dubbo 社区策划了【Dubbo 云原生之路】系列文章,和大家一起回顾 Apache Dubbo 产品和社区的发展,并展望未来发展。系列文章主要涵盖 Dubbo 技术解读、社区运营、应用案例解析三大部分。本文为系列第 4 篇。

前言

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

从定义上讲,协议通过定义规则、格式和语义来约定数据如何在网络间传输。RPC 需要通信的两端都能够识别同一种协议。数据在网络上以比特流的方式传输,如果本端的协议对端不识别,对端就无法从请求中获取到有用信息,就会出现鸡同鸭讲的情况,无法实现上层的业务需求。

1.png

一个简单的协议需要定义数据交换格式,协议格式和请求方式。

数据交换格式在 RPC 中也叫做序列化格式。常用的序列化有 JSON / Protobuf / Hessian 等,评价序列化优劣一般从三个维度:

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

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

协议格式是和 RPC 框架紧密相关的,按照功能划分有两种:

  • 一种是紧凑型协议,只提供用于调用的简单元数据和数据内容;
  • 另外一种是复合型协议,会携带框架层的元数据用来提供功能上的增强,这类协议的一个代表就是 RSocket。

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

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

2.png

Dubbo3 的一个核心内容就是定义下一代 RPC 协议。除了基础的通信功能,新协议还应该具有以下特性:

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

这里我们对比一些常用的协议,来探索新协议的形态。

HTTP/1.1

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

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

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

3.png

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 社区

欢迎 Star 和共建:https://github.com/apache/dubbo

总结

本文介绍了 RPC 协议的基础概念,比较了常用的一些协议,并在这些协议的优劣对比后提出了 Dubbo3.0 协议。Dubbo3.0 协议将在易用性、跨平台、跨语言、高性能等方面取得更大的领先。预计在 2021 年 3 月,Dubbo3.0 协议将完整支持,请大家拭目以待。

阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践,做最懂云原生开发者的公众号。”

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
阿里云服务器怎么设置密码?怎么停机?怎么重启服务器?
如果在创建实例时没有设置密码,或者密码丢失,您可以在控制台上重新设置实例的登录密码。本文仅描述如何在 ECS 管理控制台上修改实例登录密码。
9493 0
Grpc-Gateway - Grpc兼容HTTP协议文档自动生成网关
因为之前的测试结果让笔者对PHP使用GRPC很失望,如果使用HTTP的方式Guzzle还可以提供并发能力来降低接口消耗,Grpc只能阻塞,但是如果使用HTTP的话对于调用限制和GO调用GO来说不太友好,有没有一个两全其美的方式可以使用Grpc的前提下又兼容HTTP调用,让客户端可以更具自身情况自由选择,服务端工作只需要做一份呢?还别说真还有一个准备好的轮子那就是今天的主角《grpc-gateway》。
501 0
五种开源协议的比较(BSD,Apache,GPL,LGPL,MIT) – 整理
来源:http://www.awflasher.com/blog/archives/939 当Adobe、Microsoft、Sun等一系列巨头开始表现出对”开源”的青睐时,”开源”的时代即将到来! 最初来自:sinoprise.com/read.php?tid-662-page-e-fpage-1.html(遗憾的是这个链接已经打不开了),我基本未改动,只是进行了一些排版和整理。
709 0
Dubbo 3.0 前瞻之:常用协议对比及 RPC 协议新形态探索
协议是 RPC 的基础。数据在连接上以什么格式传输,服务端如何确定收到请求的大小,同一个连接上能不能同时存在多个请求,请求如果出错了应该怎么响应……这些都是需要协议解决的问题。
15048 0
怎么设置阿里云服务器安全组?阿里云安全组规则详细解说
阿里云服务器安全组设置规则分享,阿里云服务器安全组如何放行端口设置教程
8409 0
阿里云服务器端口号设置
阿里云服务器初级使用者可能面临的问题之一. 使用tomcat或者其他服务器软件设置端口号后,比如 一些不是默认的, mysql的 3306, mssql的1433,有时候打不开网页, 原因是没有在ecs安全组去设置这个端口号. 解决: 点击ecs下网络和安全下的安全组 在弹出的安全组中,如果没有就新建安全组,然后点击配置规则 最后如上图点击添加...或快速创建.   have fun!  将编程看作是一门艺术,而不单单是个技术。
10843 0
阿里云服务器如何登录?阿里云服务器的三种登录方法
购买阿里云ECS云服务器后如何登录?场景不同,阿里云优惠总结大概有三种登录方式: 登录到ECS云服务器控制台 在ECS云服务器控制台用户可以更改密码、更换系.
13176 0
Java编程架构深入解析-RPC 消息协议设计
本节我们开始讲解 RPC 的消息协议设计背后的基本原理,了解 RPC 的协议开发背后有哪些需要考虑的基本点。在通晓原理之后,我们就可以自己设计一套协议来开发属于自己的 RPC 系统。
1285 0
Dubbo 在跨语言和协议穿透性方向上的探索:支持 HTTP/2 gRPC 和 Protobuf
本文整理自刘军在 Dubbo 成都 meetup 上分享的《Dubbo 在多语言和协议穿透性方向上的探索》。 本文总体上可分为基础产品简介、Dubbo 对 gRPC (HTTP/2) 和 Protobuf 的支持及示例演示三部分,在简介部分介绍了 Dubbo、HTTP/2、gRPC、Protobuf 的基本概念和特点;第二部分介绍了 Dubbo 为何要支持 gRPC (HTTP/2) 和 P
675 0
1314
文章
0
问答
来源圈子
更多
阿里云 云原生应用平台 肩负阿里巴巴集团基础设施云化以及核心技术互联网化的重要职责,致力于打造稳定、标准、先进的云原生产品,成为云原生时代的引领者,推动行业全面想云原生的技术升级,成为阿里云新增长引擎。商业化产品包括容器、云原生中间件、函数计算等。
+ 订阅
文章排行榜
最热
最新
相关电子书
更多
《2021云上架构与运维峰会演讲合集》
立即下载
《零基础CSS入门教程》
立即下载
《零基础HTML入门教程》
立即下载