作者 | 王晓彬
为解决数据跨网问题，政采云搭建了一条基于 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 的网关，第一个版本我们选择了自研。在转发效率上，显然有天然的不足。主要有以下几个原因：
1. 对网关本身性能的担忧。比如下图中，Spring Cloud Gateway 对比其他网关的性能表现不足。同样是基于 Netty 的 Java 网关，我们也没有信心能比 Spring Cloud Gateway 更优秀。
图片来源见参考资料
2. 额外的参数序列化程序。由于需要转换协议，网关需要额外的一次序列化和反序列化。同时由于 Dubbo 网关不存在业务参数对象，我们需要一个通用的 JavaBean 描述对象作为过渡，这又增加了一次转换。
3. 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，后面升级协议也将是一个可选项。
- 性能压测验证 对于当前架构，之前做了完整的压力测试，也明白瓶颈所在。后续我们将持续测试，深挖这一基础设施的性能潜力。
作者介绍：
王晓彬，Apache Dubbo Commiter、政采云资深开发工程师，负责基础服务相关工作。
参考资料：
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/
