Dubbo3 triple协议

smalltalkhyb

于 2024-09-22 00:09:16 发布

阅读量1.1k

点赞数 19

文章标签： dubbo rpc java

本文链接：https://blog.csdn.net/smalltalkhyb/article/details/142426815

版权

Triple协议背景

在 Dubbo 的早期应用中，虽然其在数据中心内部的服务互通中展现了卓越的性能，但随着技术演进和应用场景的扩展，原有架构逐渐暴露出了一些瓶颈。这些瓶颈在跨区域、跨云的环境中尤为明显，尤其是在 Web 框架与 RPC 框架之间的频繁切换中，开发复杂性和系统性能都受到了影响。

传统架构的痛点主要体现在：

局限于数据中心内的应用场景：在跨地域或跨云应用中，Dubbo 的传统架构缺乏对广域环境的原生支持，导致开发者需要在多种协议和框架中切换，增加了复杂性。
南北向与东西向流量的双重挑战：在现代微服务架构下，传统的 RPC 框架往往更侧重南北向流量优化，而服务间（东西向）通信的性能要求日益增加，对传统 Dubbo 架构提出了新的挑战。
云原生与跨语言互操作性要求：随着云原生技术的普及，系统需要对 HTTP 协议有更深层次的支持，并具备跨语言的通信能力，然而传统 Dubbo 在这一点上并未原生优化。

Triple X 的变革和突破： Triple X 的诞生，直接回应了这些痛点，它不仅延续了 Dubbo 一贯的高性能通信能力，还实现了与 gRPC 协议的全面兼容，通过支持 HTTP/1、HTTP/2、HTTP/3 等协议，为跨云、跨区域的广泛应用场景提供了更具灵活性和高效性的解决方案。

全面支持南北向与东西向流量：Triple X 无缝支持从客户端到服务器的南北向流量及服务间通信的东西向流量，并确保灵活转换，提升通信链路的整体效率。
遵循 gRPC 协议标准：Triple X 遵循了 gRPC 协议标准，支持通过 Protobuf 进行通信，与 gRPC 服务无缝交互，扩展了 Dubbo 的跨语言、跨平台通信能力。
基于 HTTP 协议，原生支持云原生架构：Triple X 构建于 HTTP/1、HTTP/2 和 HTTP/3 协议栈之上，全面优化了网络通信性能，并与现代云原生基础设施无缝集成，支持各种网关和服务网格。
高性能优化：Triple X 提供了极致的性能提升，尤其在高并发和弱网环境下表现卓越，极大提高了系统吞吐量与响应速度。
平滑迁移与框架兼容：支持从现有的 Spring Web 项目无缝迁移，开发者无需更改现有代码即可切换至 Triple X，提升性能，并保留对 Spring MVC 等框架的支持。
高扩展性：Triple X 新引入 20+ SPI 扩展点，支持自定义核心行为，包括路由映射、参数解析、序列化及异常处理等。显著提升框架的灵活性和可定制性，使开发者能够根据特定业务需求和场景自定义行为，提高开发效率并降低定制化成本。

对比接口级服务发现，单机常驻内存下降50%,地址变更期GC消耗下降一个数量级（百次->十次）

对比应用级服务发现，单机常驻内存下降75% ，GC次数趋势为零

Triple协议在网关、Stream吞吐量方面更具优势， Triple协议对比Dubbo协议，直接调用场景，性能并无优势，但在网关、Stream调用场景更占优势

压测数据	提供者 500运行实例✖️8interface✖️5protocol，即每个提供者向注册中心注册40个URL，总计20000个URL，每个URL字符长度约1k。注册中心 2个独立zookeeper注册中心，服务提供者消费者采用并行配置。消费者配置1c2g，xmx=768，开启GC，从2个注册中心订阅，每5秒调用一次服务。运行20小时。
压测环境	Java version “1.8.0” Java(TM) SE Runtime Enviroment (build pxa6480sr3fp12-20160919_01(SR3 FP12)) IBM J9 VM (Build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20160915_318796, JIT enabled, AOT enabled)

Dubbo3 的 _Dubbo协议 _实现与 Dubbo2 版本在性能上基本持平。
由于 Triple协议本身是基于 HTTP/2 构建，因此在单条链路上的 RPC 调用并未比基于 TCP 的 Dubbo2 有提升，反而在某些调用场景出现一定下降。但 _Triple协议 _更大的优势在于网关穿透性、通用性，以及 Stream 通信模型带来的总体吞吐量提升。
Triple 预期在网关代理场景下一定会有更好的性能表现。

	描述
机器	4C8G Linux JDK 1.8（Provider）4C8G Linux JDK 1.8 （Consumer）
压测用例	RPC 方法类型包括：无参无返回值、普通pojo返回值、pojo列表返回值 2.7 版本 Dubbo 协议（Hessian2 序列化） 3.0 版本 Dubbo 协议（Hessian2 序列化） 3.0 版本 Dubbo 协议（Protobuf 序列化） 3.0 版本 Triple 协议（Protobuf 序列化） 3.0 版本 Triple 协议（Protobuf 套 Hessian2 序列化）
压测方法	单链接场景下，消费端起 32 并发线程（当前机器配置 qps rt 较均衡的并发数），持续压后采集压测数据压测数据通过 GitHub - apache/dubbo-benchmark 得出

	Dubbo + Hessian2 2.7	Dubbo + Hessian2 3.0	Dubbo + Protobuf 3.0	Triple + Protobuf 3.0	Triple + Protobuf(Hessian) 3.0
无参方法	30333 ops/s 2.5ms P99	30414 ops/s 2.4ms P99	24123 ops/s 3.2ms P99	7016 ops/s 8.7ms P99	6635 ops/s 9.1ms P99
pojo返回值	8984 ops/s 6.1 ms P99	12279 ops/s 5.7 ms P99	21479 ops/s 3.0 ms P99	6255 ops/s 8.9 ms P99	6491 ops/s 10 ms P99
pojo列表返回值	1916 ops/s 34 ms P99	2037 ops/s 34 ms P99	12722 ops/s 7.7 ms P99	6920 ops/s 9.6 ms P99	2833 ops/s 27 ms P99

Dubbo协议在不同版本的实现对比

Triple vs Dubbo

单纯看 Consumer <-> Provider 的点对点调用，可以看出 Triple 协议本身并不占优势，同样使用 Protobuf 序列化方式，Dubbo RPC 协议总体性能还是要优于 Triple。
Triple 实现在 3.0 版本中将会得到持续优化，但不能完全改变在某些场景下“基于 HTTP/2 的 RPC 协议”对比“基于 TCP 的 RPC 协议”处于劣势的局面

参考：