基于?Dubbo，如何利用APISIX?构建跨网 RPC
作者｜王晓彬
为解决数据跨网问题，政采云搭建了一条基于?Dubbo?的“高速公路”，同时采用了?APISIX?作为中心网关，为网络路由、公共特性提供支持。本文将重点介绍政采云“高速公路”工程建设中如何采用节流策略来应对挑战。我们将讨论链路协议的优化实践以及对网络传输效率的思考。
政采云平台是一个政府采购专属平台，为各级政府部门和国有企业提供支持。从网络架构的角度来看，政采云平台是一个集合了公有云、私有云和政务云的混合云网络。所以对于业务来说，跨网数据传输是一个常见的需求场景。
为了满足这种需求，政采云“高速公路”工程于?2022?年底启动，旨在整合现有的网络传输方案，提供一致、便捷和高速的跨网业务体验。随着跨网方案整合的推进，公司的跨网流量越来越多地流向了新型基础设施——政采云“高速公路”工程。
挑战
“高速公路”方案得到了公司的支持，在?2023?年上半年通过新业务的试点后，下半年开始陆续迁移历史跨网方案的业务。从监控中，我们感受到了来自流量的压力。具体表现为：
- 心跳应用告警频繁发生。
- 监控指标如响应时间（RT）和吞吐量下降。
为了确保业务的稳定性并提高用户体验，我们采取了各种优化措施。总体而言，我们主要探索了两种思路：
- 资源优化：这种优化思路相对较简单，主要涉及资源的重新调配。具体措施包括对单点的中心网关和?Dubbo?网关进行资源隔离，以最小化故障对系统的影响。此外，通过直接增加 pod 等方式，也能有效缓解压力。这样可以确保在资源方面有足够的储备，以满足系统在高负载情况下的需求。
- 性能优化：这一思路需要在架构层面进行深入优化，以尽可能填补木桶模型的短板。这是非常重要的，因为只有通过性能的最大化利用，才能实现系统的水平扩展。
综合考虑这两种思路，可以在资源充足的同时，通过性能优化来确保系统的稳定性和高可用性。这种综合策略通常是解决高压力环境下的系统性能问题的有效方法。
问题与目标
跨网?RPC（“高速公路”）的主要流程
- 客户端发起请求，包括生成代理、方法调用、参数返回的序列化，发起网络请求；
- 基于?Dubbo?协议的本地网络传输；
- 出口网关（基于?Dubbo?的?Java?应用）转发，涉及获取请求、反序列化参数、HttpClient?转发；
- 基于?HTTP?协议的公网网络传输；
- APISIX?中心网关转发；
- 基于?HTTP?协议的公网网络传输；
- 入口网关转发，涉及获取请求、HTTP?包拆解、参数序列化、Dubbo?泛化转发；
- 基于?Dubbo?协议的本地网络传输；
- 服务端接收请求，获取数据、反序列化参数、方法调用、序列化结果，返回数据；
- 原路返回，同请求流程。
整个流程对性能影响比较大的环节有：Sdk?行为?[1,9]，网络传输?[2,4,6,8]?和网关行为?[3,5,7]。其中，Sdk?行为涉及到?RPC?框架选型，在当前公司已经广泛使用?Dubbo?的背景下，可以先不考虑。需要重点考虑的，则是网络传输中协议的选择以及网关对性能的影响。
传输协议问题
鉴于现有背景，用户通常希望使用本地 Dubbo 一样直接跨网。所以。“高速公路”工程的设计是围绕?Dubbo?框架的特性进行的。
与业务对接中，经常会被问到，我们使用了?Dubbo?的某个特性，你们能否支持？出于对场景支持的考虑，在设计“高速公路”架构时，我们重点考虑了接近原生体验的特性。为此，我们设计了隧道机制。现在，基于这一特性，我们可以轻松地对业务说：“是的，可以支持！”
隧道机制方案的中间层使用了?HTTP?协议作为隧道协议，它可以穿透层层网络设备和网关，是比较稳健的一种方式。但是在流量压力下，整体的性能/吞吐量，逐渐成为当前方案的主要矛盾。
首先，在协议层面，我们先要了解下?HTTP/1.1?协议存在的性能问题。
- HTTP?头部巨大且重复，由于?HTTP?协议是无状态的，每一个请求都得携带?HTTP?头部，特别是对于有携带?Cookie?的头部，而?Cookie?的大小通常很大；
- 队头阻塞问题，同一连接只能在完成一个?HTTP?事务（请求和响应）后，才能处理下一个事务；
为此，我们需要寻找一个更加高效的传输层协议来代替?HTTP/1.1。
网关问题
另外一个比较明显的瓶颈，是本地集群内的?Dubbo?网关。
Dubbo?网关负责接收来自本地客户端的?Dubbo?协议数据，反序列后通过?HTTP?转发至公网中心网关。因为市面上没有?Dubbo?转?HTTP?的网关，第一个版本我们选择了自研。在转发效率上，显然有天然的不足。主要有以下几个原因：
- 对网关本身性能的担忧。比如下图中，Spring?Cloud?Gateway?对比其他网关的性能表现不足。同样是基于?Netty?的?Java?网关，我们也没有信心能比?Spring?Cloud?Gateway?更优秀。
图片来源见参考资料
- 额外的参数序列化程序。由于需要转换协议，网关需要额外的一次序列化和反序列化。同时由于 Dubbo?网关不存在业务参数对象，我们需要一个通用的?JavaBean?描述对象作为过渡，这又增加了一次转换。
- HttpClient?串行阻塞式的通信方式，将大大的降低并发效率。
为了解决上述问题，我们需要一个类似于?NGINX?的高性能、非阻塞的网关来实现高效的反向代理，并使用更精简的通信协议来提高吞吐量。
优化方案
协议方面
协议方面，我们尝试使用了?Dubbo?协议作为隧道协议。这能带来哪些收益呢？简而言之包括两个方面。
- 减少包的大小，提高网络吞吐量
Dubbo?协议更加精简，承载的头部信息更少。协议设计上很紧凑，能用?1?个?bit?表示的，不会用一个?byte?来表示，比如?boolean?类型的标识。Http 为了更好的兼容性，请求头部携带了很多上下文和元数据。对于内部通信来说，服务端和客户端相对固定，很多信息是没有必要的。以下是 Dubbo 官方性能测试，Tps（每秒处理事务量）Dubbo 协议比 Http 高 30%-50%左右（最常见的高并发小数据量场景）。
另外，Dubbo?使用长连接，可以重复使用已经建立的?TCP?连接，减少了连接建立的开销。
- 传输协议开销
由于整条链路使用了相同协议，可以避免不同协议间的装包和解包。
网关方面
网关方面，我们使用了?APISIX?代替?Dubbo?网关。
APISIX?是基于高性能的?OpenResty?开发的，从架构和设计角度对性能追求极致，因此可以满足我们对网关性能的基本要求。同时，它具有出色的扩展性，能够满足我们的自定义需求。简而言之，我们既希望享有类似?NGINX?的高性能，又希望可以根据需要扩展功能。
APISIX?实现了?xRPC?四层协议扩展框架，允许开发人员自定义特定于应用程序的协议。基于 xRPC 框架，APISIX?可以提供几种主要应用协议的代理实现，用户还可以基于该框架支持自己私有的基于?TCP?的应用协议，使其具有类似于?HTTP?协议代理的精确粒度和更高级别的?7?层控制。通过使用?APISIX?的?xRPC?扩展，我们成功地增加了对?Dubbo?协议的直接转发功能，从而实现了全链路?Dubbo?协议传输。
这一举措解决了之前提到的两个问题：显著提升了网关性能，同时减少了协议转换的成本。此外，我们也不再需要维护额外的应用网关，实现了中间件层面的收敛。
我们已经通过?PR?（https://github.com/apache/apisix/pull/9660）的方式将上述特性提交给?APISIX?社区，因此下一个版本中我们将能够直接使用开源版本。
注：APISIX?的?Dubbo?插件支持?HTTP?转?Dubbo，目前没有 Dubbo?直接转?Dubbo?的方式。虽然?Dubbo?协议是私有协议，但是?Dubbo?框架的应用非常广泛，这一特性可能会有很多意想不到的用法。
本轮改造不足
2022 年下半年，我们对各跨岛方案，进行了整合升级，也就是现在的“高速公路”方案，保障跨岛标准化同时，解决了之前方案实践过程中面临的很多业务痛点。通过替换隧道协议，我们希望优化网络?IO?模型，提高链路转发效率。经初步测试，单次?2k?包请求?RT?可以降低?1/3?左右。
但是，在实践业务场景中，该架构下一些痛点也开始逐渐显现。
支持场景不足
对云岛业务结构的公司来说，云平台属于公司内部、完全可控的局域网，而岛端则是有自己安全网络策略的独立内部网络。我们的跨网?RPC?需要穿透混合云网络中的各种设备和网关，到达云岛的另一头服务。Dubbo?协议作为私有协议，在大部分的跨岛场景中并不适用。
目前，这种模式只能在内部的一些网络使用，比如独立搭建的 AI 集群和平台业务集群的通信。
当然，基于“高速公路”架构的良好扩展性，我们可以做到不同场景自动切换协议，在获得?Dubbo?协议优势的前提下，也能退化?HTTP?协议兜底。
对网络吞吐量的优化不足
接口需要发送大量数据时，这些数据无法被放在一个?RPC?的请求或响应中，需要分批发送。
Dubbo 协议下，这种情况只能串行发送。Dubbo 协议在单次请求下性能较好，但是整体吞吐量的提升仍然不够。
在我们的跨网第一个版本上线前，曾经做过性能压力测试。测试场景如下：
云端调岛，上行数据，30M?带宽，发送?2KB?数据，逐步增大并发量。
30M?入口带宽，发送?2KB?数据，TPS?大于?500/s，入口带宽将成为瓶颈。当发送数据增加到?80KB，TPS?下降约?16?倍，RT?上升约?1.5?倍。
从监控上看，tps?到达一定量后，带宽即达到上限。
可以看到，当前“高速公路”的实际业务场景下，吞吐量是“高速公路”第一个版本最大的一个瓶颈。此次网关和协议的升级，显著降低了?RT?指标，一定程度提升了整体吞吐量。
后续规划
经过对?APISIX?的协议扩展，我们使用?APISIX?代替了?Dubbo?自研网关，基本实现了对通信效率的预期优化。但是，我们也有支持场景和通信效率两个明显的痛点需要解决。
为此，我们重点调研了?Dubbo3?主力通信协议——Triple?协议。
Triple?协议是?Dubbo3?设计的基于?HTTP?的?RPC?通信协议规范，它完全兼容?gRPC?协议，支持?Request-Response、Streaming?流式等通信模型，可同时运行在?HTTP/1?和?HTTP/2?之上。对于我们项目来说，Triple?协议的几个特性刚好是我们欠缺的。
- 完全兼容基于?HTTP/2?的?gRPC?协议
Triple?协议听起来是个私有协议，实际上则是标准的公有协议，兼容?HTTP/1?和?HTTP/2。这意味着穿透性强，痛点之一的场景支持就不再是问题了。
对比?HTTP/1，二进制分帧带来的并行效率提升，首部压缩减少大量包体，在网络吞吐量上，HTTP/2 在性能上有了极大提升。
- 作为?Dubbo?主力协议，仍然保留着避免协议转换的优势，与“高速公路”架构契合
经过?Dubbo2?协议的实践与总结，我们将着力推动?Triple?协议的升级，完美解决性能问题。
未来，我们将按以下几步进行：
- 助力开源项目?APISIX?扩展?Triple?协议
APISIX?本身有着非常优秀的扩展性，同时有?Dubbo2?协议的经验，相信这一步会比较顺利。
- 推动公司?Triple?协议的升级
今年政采云整体升级完?Dubbo3，后面升级协议也将是一个可选项。
- 性能压测验证
对于当前架构，之前做了完整的压力测试，也明白瓶颈所在。后续我们将持续测试，深挖这一基础设施的性能潜力。
参考资料：
https://www.jianshu.com/p/7182b8751e75
https://www.infoq.cn/article/qfcz1fj9wvFvGidjpcho
https://zhuanlan.zhihu.com/p/432512918
https://cn.dubbo.apache.org/zh-cn/docsv2.7/user/perf-test/
作者介绍：
王晓彬，Apache?Dubbo?Commiter、政采云资深开发工程师，负责基础服务相关工作。
- 发表于:
- 本文为 InfoQ 中文站特供稿件
- 首发地址：https://www.infoq.cn/article/9jJUiWSlyYueK14artaj
- 如有侵权，请联系 cloudcommunity@tencent.com 删除。
相关快讯
扫码
添加站长 进交流群
领取专属 10元无门槛券
私享最新 技术干货
腾讯云开发者
