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

本文涉及的产品
容器镜像服务 ACR,镜像仓库100个 不限时长
云原生网关 MSE Higress,422元/月
应用实时监控服务-用户体验监控,每月100OCU免费额度
简介: 协议是 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 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践,做最懂云原生开发者的公众号。”

相关文章
|
7月前
|
Dubbo Java 应用服务中间件
微服务学习 | Springboot整合Dubbo+Nacos实现RPC调用
微服务学习 | Springboot整合Dubbo+Nacos实现RPC调用
|
7月前
|
Dubbo Cloud Native 网络协议
【Dubbo3技术专题】「服务架构体系」第一章之Dubbo3新特性要点之RPC协议分析介绍
【Dubbo3技术专题】「服务架构体系」第一章之Dubbo3新特性要点之RPC协议分析介绍
97 1
|
16天前
|
Dubbo 安全 应用服务中间件
Apache Dubbo 正式发布 HTTP/3 版本 RPC 协议,弱网效率提升 6 倍
在 Apache Dubbo 3.3.0 版本之后,官方推出了全新升级的 Triple X 协议,全面支持 HTTP/1、HTTP/2 和 HTTP/3 协议。本文将围绕 Triple 协议对 HTTP/3 的支持进行详细阐述,包括其设计目标、实际应用案例、性能测试结果以及源码架构分析等内容。
|
7月前
|
Java Android开发
java利用xml-rpc协议操作wordpress博客
java利用xml-rpc协议操作wordpress博客
87 1
|
3月前
|
XML 负载均衡 监控
分布式-dubbo-简易版的RPC框架
分布式-dubbo-简易版的RPC框架
|
4月前
|
JSON Dubbo Java
【Dubbo协议指南】揭秘高性能服务通信,选择最佳协议的终极攻略!
【8月更文挑战第24天】在分布式服务架构中,Apache Dubbo作为一款高性能的Java RPC框架,支持多种通信协议,包括Dubbo协议、HTTP协议及Hessian协议等。Dubbo协议是默认选择,采用NIO异步通讯,适用于高要求的内部服务通信。HTTP协议通用性强,利于跨语言调用;Hessian协议则在数据传输效率上有优势。选择合适协议需综合考虑性能需求、序列化方式、网络环境及安全性等因素。通过合理配置,可实现服务性能最优化及系统可靠性提升。
62 3
|
4月前
|
API 开发者 微服务
RPC和 HTTP协议
【8月更文挑战第8天】RPC(远程过程调用)使程序能像本地调用般请求远程服务,简化网络通信细节。其优点包括高效的数据传输及严格的类型定义,适合微服务间的高效通信。HTTP(超文本传输协议)则是用于万维网数据传输的通用协议,以文本为基础,易于理解和调试,并被广泛支持。两者各有侧重,RPC偏高速服务通信,HTTP则更适用于多样化的网络场景。选择时需根据具体需求决定。
|
4月前
|
C# 开发者 Windows
勇敢迈出第一步:手把手教你如何在WPF开源项目中贡献你的第一行代码,从选择项目到提交PR的全过程解析与实战技巧分享
【8月更文挑战第31天】本文指导您如何在Windows Presentation Foundation(WPF)相关的开源项目中贡献代码。无论您是初学者还是有经验的开发者,参与这类项目都能加深对WPF框架的理解并拓展职业履历。文章推荐了一些适合入门的项目如MvvmLight和MahApps.Metro,并详细介绍了从选择项目、设置开发环境到提交代码的全过程。通过具体示例,如添加按钮点击事件处理程序,帮助您迈出第一步。此外,还强调了提交Pull Request时保持专业沟通的重要性。参与开源不仅能提升技能,还能促进社区交流。
48 0
|
6月前
|
分布式计算 资源调度 网络协议
分布式系统详解--框架(Hadoop--RPC协议)
分布式系统详解--框架(Hadoop--RPC协议)
48 0
|
7月前
|
Dubbo Java 应用服务中间件
Spring Boot整合Dubbo+Zookeeper实现RPC调用
Spring Boot整合Dubbo+Zookeeper实现RPC调用 技术栈说明 Dubbo:Dubbo作为RPC框架,能在多个服务之间实现远程服务的调用。比如有两个独立的微服务A和B,A服务想要调用B服务时,因为两者不在同个内存空间中,不能直接调用,所以可以通过Dubbo实现这点。 功能和Spring Cloud的Feign相同,两者都是应用于微服务架构的远程调用框架 Zookeeper:作为注册中心去管理Dubbo服务,这点和Eureka、Nacos相同。 概述 通过一个示例说明Dubbo+Zookeeper在Spring Boot中的应用。 现有两个服务provider和con
187 4