【Dubbo3技术专题】「服务架构体系」第一章之Dubbo3新特性要点之RPC协议分析介绍

简介: 【Dubbo3技术专题】「服务架构体系」第一章之Dubbo3新特性要点之RPC协议分析介绍

RPC 通信协议

Dubbo3提供了Triple(Dubbo3)、Dubbo2协议,这是Dubbo框架的原生协议。除此之外,Dubbo3也对众多第三方协议进行了集成,并将它们纳入Dubbo的编程与服务治理体系, 包括:gRPC、Thrift、JsonRPC、Hessian2、REST等。以下重点介绍 Triple 与 Dubbo2 协议。

Triple 协议

Triple协议是Dubbo3 推出的主力协议。Triple意为第三代,通过Dubbo1.0/Dubbo2.0两代协议的演进,以及云原生带来的技术标准化浪潮,Dubbo3新协议Triple应运而生。

RPC协议的选择

  • 通信协议是RPC的核心,它规范了数据在网络中的传输内容和格式。
  • 除必须的请求、响应数据外,通常还会包含额外控制数据,如:单次请求的序列化方式、超时时间、压缩方式和鉴权信息等。

协议的内容包含三部分

  • 数据交换格式: 定义RPC的请求和响应对象在网络传输中的字节流内容,也叫作序列化方式。
  • 协议结构: 定义包含字段列表和各字段语义以及不同字段的排列方式。
  • 协议通过定义规则、格式和语义来约定数据如何在网络间传输。

一次成功的RPC需要通信的两端都能够按照协议约定进行网络字节流的读写和对象转换。如果两端对使用的协议不能达成一致,就会出现鸡同鸭讲,无法满足远程通信的需求。

RPC协议的设计需要考虑以下内容:

  • 通用性: 统一的二进制格式,跨语言、跨平台、多传输层协议支持
  • 扩展性: 协议增加字段、升级、支持用户扩展和附加业务元数据
  • 穿透性:能够被各种中端设备识别和转发:网关、代理服务器等 通用性和高性能通常无法同时达到,需要协议设计者进行一定的取舍。
  • 性能:As fast as it can be
HTTP/1.1

直接构建于TCP传输层的私有RPC协议,构建于HTTP之上的远程调用解决方案会有更好的通用性,如:WebService或REST架构,使用HTTP + JSON 可以说是一个事实标准的解决方案。

选择构建在 HTTP 之上,有两个最大的优势:
  • HTTP的语义和可扩展性能很好的满足RPC调用需求。
  • HTTP协议几乎被网络上的所有设备所支持,具有很好的协议穿透性。
选择构建在 HTTP 之上,但也存在比较明显的问题:
  • 典型的Request – Response 模型,一个链路上一次只能有一个等待的 Request 请求。会产生 HOL。
  • Human Readable Headers,使用更通用、更易于人类理解的头部传输格式,但性能相当差
  • 无直接 Server Push 支持,需要使用 Polling Long-Polling 等变通模式
gRPC

HTTP及TCP协议之上构建 RPC 协议各自的优缺点,相比于 Dubbo 构建于 TCP 传输层之上,Google 选择将 gRPC 直接定义在 HTTP/2 协议之上。 gRPC 的优势由HTTP2 和 Protobuf 继承而来。

  • 基于 HTTP2 的协议足够简单,用户学习成本低,天然有 server push/ 多路复用 / 流量控制能力
  • 基于 Protobuf 的多语言跨平台二进制兼容能力,提供强大的统一跨语言能力
  • 基于协议本身的生态比较丰富,k8s/etcd 等组件的天然支持协议,云原生的事实协议标准,但是也存在部分问题
  • 服务治理的支持比较基础,更偏向于基础的RPC功能,协议层缺少必要的统一定义,对于用户而言直接用起来并不容易。
  • 强绑定protobuf的序列化方式,需要较高的学习成本和改造成本,对于现有的偏单语言的用户而言,迁移成本不可忽视

最终的选择Triple

兼容gRPC ,以HTTP2作为传输层构建新的协议,也就是Triple。

容器化应用程序和微服务的兴起促进了针对负载内容优化技术的发展。 客户端中使用的传统通信协议( RESTFUL或其他基于 HTTP 的自定义协议)难以满足应用在性能、可维护性、扩展性、安全性等方便的需求。

GRPC协议的兴起

一个跨语言、模块化的协议会逐渐成为新的应用开发协议标准。自从 2017 年 gRPC 协议成为 CNCF 的项目后,包括 k8s、etcd 等越来越多的基础设施和业务都开始使用 gRPC 的生态,作为云原生的微服务化框架, Dubbo 的新协议也完美兼容了 gRPC。并且,对于 gRPC 协议中一些不完善的部分, Triple 也将进行增强和补充。

Triple协议是否解决问题

  • 性能上: Triple 协议采取了 metadata 和 payload 分离的策略,这样就可以避免中间设备,如网关进行 payload 的解析和反序列化,从而降低响应时间。
  • 路由支持上,由于 metadata 支持用户添加自定义 header ,用户可以根据 header 更方便的划分集群或者进行路由,这样发布的时候切流灰度或容灾都有了更高的灵活性。
  • 安全性上,支持双向TLS认证(mTLS)等加密传输能力。
  • 易用性上,Triple 除了支持原生 gRPC 所推荐的 Protobuf 序列化外,使用通用的方式支持了 Hessian / JSON 等其他序列化,能让用户更方便的升级到 Triple 协议。对原有的 Dubbo 服务而言,修改或增加 Triple 协议 只需要在声明服务的代码块添加一行协议配置即可,改造成本几乎为 0。

Triple协议

Triple 协议通信方式

现状

  1. 完整兼容grpc、客户端/服务端可以与原生grpc客户端打通
  2. 目前已经经过大规模生产实践验证,达到生产级别

特点与优势

  1. 具备跨语言互通的能力,传统的多语言多 SDK 模式和 Mesh 化跨语言模式都需要一种更通用易扩展的数据传输格式。
  2. 提供更完善的请求模型,除了 Request/Response 模型,还应该支持 Streaming 和 Bidirectional。
  3. 易扩展、穿透性高,包括但不限于 Tracing / Monitoring 等支持,也应该能被各层设备识别,网关设施等可以识别数据报文,对 Service Mesh 部署友好,降低用户理解难度。
  4. 多种序列化方式支持、平滑升级
  5. 支持 Java 用户无感知升级,不需要定义繁琐的 IDL 文件,仅需要简单的修改协议名便可以轻松升级到 Triple 协议

Triple 协议内容介绍

基于 grpc 协议进行进一步扩展

sql

复制代码

Service-Version → “tri-service-version” {Dubbo service version}
Service-Group → “tri-service-group” {Dubbo service group}
Tracing-ID → “tri-trace-traceid” {tracing id}
Tracing-RPC-ID → “tri-trace-rpcid” {_span id _}
Cluster-Info → “tri-unit-info” {cluster infomation}

其中 Service-Version 跟 Service-Group 分别标识了 Dubbo 服务的 version 跟 group 信息,因为grpc的 path 申明了 service name 跟 method name,相比于 Dubbo 协议,缺少了version 跟 group 信息;Tracing-ID、Tracing-RPC-ID 用于全链路追踪能力,分别表示 tracing id 跟 span id 信息;Cluster-Info 表示集群信息,可以使用其构建一些如集群划分等路由相关的灵活的服务治理能力。

Triple Streaming

Triple协议相比传统的unary方式,多了目前提供的Streaming RPC的能力

Streaming 用于什么场景呢? 在一些大文件传输、直播等应用场景中, consumer或provider需要跟对端进行大量数据的传输,由于这些情况下的数据量是非常大的,因此是没有办法可以在一个RPC的数据包中进行传输,因此对于这些数据包我们需要对数据包进行分片之后,通过多次RPC调用进行传输,如果我们对这些已经拆分了的RPC数据包进行并行传输,那么到对端后相关的数据包是无序的,需要对接收到的数据进行排序拼接,相关的逻辑会非常复杂。但如果我们对拆分了的RPC数据包进行串行传输,那么对应的网络传输RTT与数据处理的时延会是非常大的。

为了解决以上的问题,并且为了大量数据的传输以流水线方式在consumer与provider之间传输,因此Streaming RPC的模型应运而生。

通过Triple协议的Streaming RPC方式,会在consumer跟provider之间建立多条用户态的长连接,Stream。同一个TCP连接之上能同时存在多个Stream,其中每条Stream都有StreamId进行标识,对于一条Stream上的数据包会以顺序方式读写。

总结

在API领域,最重要的趋势是标准化技术的崛起。Triple 协议是 Dubbo3 推出的主力协议。它采用分层设计,其数据交换格式基于Protobuf (Protocol Buffers) 协议开发,具备优秀的序列化/反序列化效率,当然还支持多种序列化方式,也支持众多开发语言。在传输层协议,Triple 选择了 HTTP/2,相较于 HTTP/1.1,其传输效率有了很大提升。此外HTTP/2作为一个成熟的开放标准,具备丰富的安全、流控等能力,同时拥有良好的互操作性。Triple 不仅可以用于Server端服务调用,也可以支持浏览器、移动App和IoT设备与后端服务的交互,同时 Triple协议无缝支持 Dubbo3 的全部服务治理能力。

在Cloud Native的潮流下,跨平台、跨厂商、跨环境的系统间互操作性的需求必然会催生基于开放标准的RPC技术,而gRPC顺应了历史趋势,得到了越来越广泛地应用。在微服务领域,Triple协议的提出与落地,是 Dubbo3 迈向云原生微服务的一大步。


相关文章
|
20天前
|
消息中间件 传感器 Cloud Native
事件驱动作为分布式异步服务架构
【6月更文挑战第25天】本文介绍事件驱动架构(EDA)是异步分布式设计的关键模式,适用于高扩展性需求。EDA提升服务韧性,支持CQRS、数据通知、开放式接口和事件流处理。然而,其脆弱性包括组件控制、数据交换、逻辑关系复杂性、潜在死循环和高并发挑战。EDA在云原生环境,如Serverless,中尤其适用。
42 2
事件驱动作为分布式异步服务架构
|
4天前
|
消息中间件 API 开发者
探索微服务架构中的服务通信模式
【7月更文挑战第11天】在微服务架构的世界中,服务的通信是构建高效、可维护系统的关键。本文将深入探讨微服务架构中常见的服务通信模式,包括同步通信与异步通信机制,并比较它们在不同场景下的适用性及优缺点。文章旨在为后端开发者提供一份实用的指南,帮助他们在选择适合自己项目需求的通信模式时做出明智的决策。
|
7天前
|
运维 监控 负载均衡
云原生架构的演进:从微服务到服务的网格
【7月更文挑战第8天】云原生技术正以惊人的速度不断进化,其核心理念是构建可扩展、灵活且高度可靠的应用程序。本文将深入探讨云原生架构的关键组成部分,特别是微服务和服务网格,以及它们如何共同推动现代软件的发展。我们将通过一个具体的案例分析,揭示这些技术如何在现实世界中被应用来提升业务敏捷性和操作效率。
|
28天前
|
存储 前端开发 关系型数据库
在服务的数据驱动中使用三层架构
【6月更文挑战第17天】 三层架构是软件设计中的一种经典模式,将应用分为表示层(UI)、应用层(BLL)和数据层(DAL)。相比于双层架构,三层架构提供了更好的模块化和安全性。多层架构虽少见,但三层架构在现代云原生技术中依然重要,常与微服务结合使用。
31 2
在服务的数据驱动中使用三层架构
|
1月前
|
存储 数据处理 数据库
理解在服务架构中的事件驱动
【6月更文挑战第14天】网络架构和软件设计常基于ISO七层模型和三层应用架构,强调数据处理的重要性。事件驱动架构(EDA)以事件为中心,改变传统设计方式,解决系统问题。事件是触发通知或状态变化的操作,如用户下单。EDA适用于微服务通信、工作流程自动化、SaaS集成和基础设施自动化等场景,提高系统敏捷性和可扩展性。然而,EDA并非万能,需根据需求选择合适的设计方案。
75 1
理解在服务架构中的事件驱动
|
15天前
|
消息中间件 存储 运维
微服务架构中的服务通信与数据一致性策略
【6月更文挑战第29天】本文深入探讨了微服务架构下的服务间通信和数据一致性问题,提出了一系列解决方案。文章首先分析了微服务环境下面临的主要挑战,随后详细介绍了同步和异步通信模式,并对比了它们在不同场景下的适用性。接着,文章讨论了实现数据一致性的几种策略,包括两阶段提交、补偿事务以及最终一致性,每种策略都配以实际案例分析。最后,结合当前技术趋势,展望了微服务通信和数据一致性处理的未来发展方向。
|
21天前
|
监控 API 数据安全/隐私保护
构建高效后端服务:微服务架构的实践与挑战
【6月更文挑战第23天】在现代软件开发中,微服务架构已成为设计高性能、可扩展后端系统的首选模式。本文将深入探讨微服务的设计原则、实践方法及其面临的技术挑战,旨在为开发者提供一个全面的微服务实施指南。
29 3
|
3天前
|
运维 Kubernetes 监控
微服务架构中服务的编排
微服务架构中服务的编排
|
3天前
|
消息中间件 运维 数据处理
探索微服务架构中的服务通信模式
【7月更文挑战第12天】在微服务架构的海洋中,服务之间的通信犹如连接岛屿的桥梁,至关重要。本文将深入探讨微服务架构下的服务通信模式,从同步请求/响应到异步消息传递,再到事件驱动架构,我们将一探究竟,了解它们如何影响系统设计、性能和可维护性。通过比较不同模式的优劣,我们旨在为开发者提供一盏明灯,指引他们在构建高效、可靠且易于扩展的微服务系统时做出明智的选择。
|
7天前
|
消息中间件 安全 NoSQL
「架构」SOA(面向服务的架构)
**SOA**是构建灵活企业IT系统的架构模式,基于服务组件进行设计。它强调服务的自包含、模块化,通过服务识别、抽象、组合和交互实现业务流程。特点包括松耦合、重用性、互操作性和标准化。优点是灵活性、可维护性、可扩展性和成本效益,但也有复杂性、性能和治理问题。设计策略涉及业务能力识别、服务契约定义和服务目录建立。技术栈涵盖Java EE、.NET、SOAP、REST、服务治理工具和各种数据库、消息队列及安全标准。SOA旨在适应变化,但也需妥善管理和规划。
17 0