长连接网关技术专题 (十一)：揭秘腾讯公网 TGW 网关系统的技术架构演进

作者：JackJiang

2024-04-18
江苏
本文字数：9098 字
阅读完需：约 30 分钟

本文由腾讯技术团队 peter 分享，原题“腾讯网关 TGW 架构演进之路”，下文进行了排版和内容优化等。

1、引言

TGW 全称 Tencent Gateway，是一套实现多网统一接入，支持自动负载均衡的系统，是公司有 10+年历史的网关，因此 TGW 也被称为公司公网的桥头堡。

本文从腾讯公网 TGW 网关系统的应用场景、背景需求讲起，重点解析了从山海 1.0 架构到山海 2.0 架构需要解决的问题和架构规划与设计实现，以及对于未来 TGW 山海网关的发展和演进方向。

技术交流：

- 移动端 IM 开发入门文章：《新手入门一篇就够：从零开发移动端IM》

- 开源 IM 框架源码：https://github.com/JackJiang2011/MobileIMSDK（备用地址点此）

（本文已同步发布于：http://www.52im.net/thread-4641-1-1.html）

2、专题目录

本文是专题系列文章的第 11 篇，总目录如下：

3、TGW 网关系统的重要性

TGW 全称 Tencent Gateway，是一套实现多网统一接入、支持自动负载均衡的系统，是公司有 10+年历史的网关，因此 TGW 也被称为公司公网的桥头堡。它对外连接了各大运营商并支撑公有云上 EIP、CLB 等产品功能，对内提供了公网网络的接入功能，如为游戏、微信等业务提供公网接入服务。

TGW 主要有两大产品：

1）弹性 EIP（比如购买一台虚拟机 CVM 或是一个 NAT 实例后，通过 EIP 连通外网）；
2）四层 CLB。

四层 CLB 一般分为内网 CLB 和外网 CLB：

1）内网 CLB 是在 vpc 内创建一个 CLB 实例，把多个 CVM 服务挂在了内网 CLB 上，为后端 RS 提供负载均衡的能力；
2）外网 CLB 面对的是公网侧负载均衡的需求。

当在内部部署 CLB 集群时，可分为 IPV4 或者 IPV6 两大类，根据物理网络类型又细分为 BGP 和三网两类。三网指这些 IP 地址是静态的，不像 BGP 一样能够在多个运营商之间同时进行广播。

以上就是四层 TGW 产品及功能，山海网关在原有产品基础上做了网络架构方面的演进。

4、Region EIP 的引入

具体介绍下 EIP 和 CLB 两个产品。

过去 CLB 和 EIP 使用不同的 IP 地址池，导致资源池上的隔离问题。使得我们无法把 EIP 地址绑定到公有云 CLB 实例上。

例如：一个创业公司最初只购买一台虚拟机并挂载一个公网 EIP 来提供服务。随着用户量的增长，如果想将这个 EIP 地址迁移到一个公网 CLB 实例上，在原有架构下是无法实现这种迁移的。

此外：EIP 和 CLB 部署在每个机房，因此在每个机房都需要建立 EIP 出口。但是各个机房的公网出口之间缺无法相互容灾。

所以这种情形下，我们确定了产品的目标：

1）希望将所有公网出口整合到一到两个机房之内，以避免重复建设，节省成本；
2）通过将出口集中，我们可以将对应的网关服务器也进行集中，进而提高设备的利用率；
3）通过这样的布局可实现跨机房的容灾方案。

因此：最早的 Region EIP（REIP）计划应运而生。

以北京这类大型 region 为例的：我们将 EIP 专区建设到位于两个城市的超核机房。这两个机房通常会放置物理网络的交换设备，并为各自设立了一个 REIP 专区。在 REIP 专区内部署 Region EIP 集群。为了实现跨 AZ 容灾，两个机房的集群之间借助大小网段实现互相备份容灾的能力。一旦其中一个机房的集群发生故障或出现网络问题，另一个机房的集群可以立即承担起容灾任务。

同时：因为新的 Region EIP 的网络架构跟原来的网络架构不一样，通过网络架构升级以及机型升级，我们能够把单台 Region EIP 的性能做到原有单台 EIP 性能的 5 倍。这样我们通过容量的提升进一步提升了设备利用率，在完成全量 Region EIP 后，设备数量会从 3000+台缩减至 700+台。同时原有的 CLB 集群还保留在各个机房不变，这些 CLB 集群的外网接入能力由 Region EIP 承担。

5、公网 CLB 的演进

5.1 概述

公网 CLB 最早是有公网接入能力的。引入到 Region EIP 之后，当初设想是公网 CLB 不再演进，尽量让存量用户迁移到另外一种形式，上层是 Region EIP，下层是内网 CLB。用户先买一个内网 CLB，如果需要对公网提供服务就再买一个弹性 EIP，把 EIP 跟内网 CLB 绑定在一起，提供 CLB 公网的能力，替代原有的公网 CLB，这是最早公网 CLB 的替代方案。

两个方案的区别是：原有公网 CLB，用户仅看到一个 CLB 实例。新的模式下，用户看到的是两个实例：一个 EIP+一个内网 CLB，两个实例都可以独立运营管理。这就是我们最早的两层架构设想，想把公网 CLB 跟外网解耦。

但是，真正去跟用户或产品交流时，这个想法遇到了比较大的挑战：

1）用户体验的改变：以前公网 CLB 用户看到是一个实例，但是现在用户看到两个实例，必然会给用户带来一些适配工作。比如用户进行创建、管理实例时，API 不一样了。以前使用通过自动化脚本创建公网 CLB 实例的，现在脚本还要改变去适配新的 API。

2）用户习惯改变：以前用户习惯在一个实例下，点击页面，就能够查看流量、链接数等监控信息。现在 EIP 流量需要到 REIP 查看，而链接数还需在 CLB 产品上看。

3）存量客户无法迁移：原来客户买的公网 CLB 实例，是无法直接无感知迁移到内网 CLB+REIP 这种新形式的。

在这些挑战下，这个替代方案没能真正落地。结合用户的要求，我们最终跟产品定下的策略是：公网 CLB 保持不变。原有的公网 CLB 继续保留，同时如果用户新增的公网 CLB 需求，也要继续支持。

5.2 公网 CLB 模型

那么，公网 CLB 到底怎么演变？

我们的初衷并不是把公网 CLB 这个产品摒弃掉，而是要收敛公网入口。所以我们针对这个初始需求，提出了上面这个两级架构模型。

首先：用 REIP 将公网流量先引进来，再将这个流量通过隧道报文的形式转发给原有的公网 CLB 集群，这样公网 CLB 不需要原有外网接入的能力，不需要再跟外网打交道，可以演变成只在机房内部的集群；同时因为公网 CLB 的流量都会经过 REIP，REIP 自然也就是公网 CLB 的流量入口。从而达到我们最初收敛公网入口的目的。这样的架构升级，可实现用户无感知。架构升级切换过程中，用户在访问公网 CLB，不会出现卡顿或者重连的现象。

这个架构模型也有一定的局限性的。公网 CLB 实例只能承载公网的流量，无法像上文提到的两层 RERP+CLB 那样，内外网随时进行转化。REIP+CLB 实例中的 CLB 既承载内网侧 CLB 的流量，又承载公网侧 CLB 的流量。

6、山海架构 1.0

借助这个两级架构模型，我们能够把公网 CLB 保留下来，并且通过 REIP 把公网入口收敛。

进一步思考并完善，我们提出了下面的想法：跟产品进行解耦。

以前我们一个地区上线公网 CLB 产品，底层就要搭建有一个公网 CLB 的集群去支持。用户需要内网 CLB 服务，就要对应搭建个内网 CLB 的集群。底层集群类型跟产品是强耦合，有 IPv4/IPv6，公网/内网、BGP/三网组合出的多个产品形态。

这种模式在小地域部署，因为产品业务的流量小，集群利用率低，就会造成很大的成本压力。

为了应对这种小带宽低成本的诉求，我们将 CLB+REIP 的模型进一步抽象，引入山海架构：我们只建设 CLB 和 REIP 两类集群。通过这两类集群上的不同实例组合，满足多个产品形态的要求。从而实现产品形态和底层物理网络集群类型解耦。

解耦合的方式是：CLB 和 REIP 通过不同的实例类型，组合出不同的产品形态。

山海架构在 TGW 内部做闭环，不涉及到产品侧和用户侧的改动。整个过程升级，对产品侧不做任何接口上的更新。因为产品侧的 API 接口保持不变，对用户侧就可以做到完全无感知。在产品侧保持不变，就需要我们在内部管控，识别接入用户实例是哪种形态的产品，拆分成不同形式的 CLB 和 REIP 的实例。其他的相关功能的比如流量统计、限速等模块也都要适配不同的产品形态，通过模块的适配，做到山海架构对上层产品侧应用的透明。

山海架构 1.0 归纳起来有两个重点：收敛公网入口和集群类型归一。

1）REIP：部署在城核机房，同时承载的是 CLB 和 REIP 两类产品的公网流量。之前 EIP，在物理网络上有 BGP+三网、v4/v6 等多种集群类型。REIP 借助 vlan 的隔离支持，把所有的网络类型都集中到一种 REIP 集群上来，我们称之为全通集群。在物理网络层面实现网络类型的归一，然后再通过软件层的适配，实现 REIP 支持多通类型的网络接入能力。

2）CLB：在山海两级架构下，REIP 集群处理公网侧的各种场景组合，CLB 集群通过隧道与 REIP 处理公网流量。之前一个机房如果要把所有的产品能力支持起来，大概有 7 种集群类型。现在 CLB 集群可以用一种集群类型来支持所有的产品的公网 CLB 产品，以及内网 CLB 产品的能力。我们把三网+BGP 以及内外网还有 V4V6 等集群类型都用一种类型来支持，山海架构完全落地后，开区的最小服务器数量可以降低到 8 台服务器，来承载所有的 EIP 和 CLB 产品需求。

归纳起来一句话：对于用户来说，产品形态没有改变，用户使用习惯也没有改变。而在底层，我们把集群类型收敛到一个 CLB 集群和一个 REIP 集群上。

7、山海架构 1.0 限速技术

在山海架构演进中，有许多技术点，本文选取限速技术进行分享。

首先 Region EIP 支持三网。以前 BGP 跟三网分开独立支持，山海网关统一用 Region EIP 支持。Region EIP 本身的网络架构分成两个机房，每个机房放 4 台 TGW 设备，每个 EIP 只会走左边或者右边。一个 EIP 进来的流量经过上面这层交换机时，经过了 ECMP 分流，然后分到了 4 台设备上。这样对每个 EIP 其实是采用了分布式限速。

限速有两个要求：

1）精确性，限速上下浮动要小，要限得准；
2）要有容灾能力。

限速最极端的精准就是把它放到单点上去做限速，但是单点限速就会面临单点故障和容灾的问题。在 X86 服务器上，使用的是分布式限速，一个 EIP 均分到 4 台服务器上，每五秒钟做一次流量的的汇总统计，通过流量比例计算将这个 EIP 的带宽配额，重新分配并分发到 4 台设备上，以此来实现集群上的限速。在单台设备上，也是没隔一段时间，就重新计算配额并分配到每个 CPU 核上，我们目前用的是 300 毫秒周期。

需要说明的是：在限速的实现上，业务有多重实现方式，我们了解到有的实现的是静态分配，比如 120 兆的带宽，4 台设备，我们每台设备分 40M(三分之一)的带宽。1/3 而不是 1/4 的带宽，目的是防止某一台设备断了之后，用户总带宽不达标，影响用户体验。在单台设备上限速，也有另外一种实现方式，大小桶。比如限速 1M 的带宽，那么每个核第一次取回 100K 或者 200K 配额。后续报文处理时候，先消耗上次取回的配额，如果带宽配额消耗光了，再重新取。周期调整跟大小桶这两种实现方式各有优缺点。从资源消耗来说，300 毫秒周期的资源消耗相对会更少一些，两者大概有 10%左右的性能偏差。

限速上另一诉求：小带宽的限速的精准限速。

大带宽比如 100 兆，分到每个核上相对富裕。小带宽如一 M 带宽，一秒钟 100k 字节等，分到四台机器再分到几十个核上，每个核都可能不到一个大报，这时候再去做精准限速就会非常困难，因为既然要提前分配资源，资源那么少，分配到单核上，可能一个包都过不去，但凡有一个报文过去了，又可能超了。所以在小带宽限速时，我们把它退化成类似于单点限速的模式。由于入方向带宽最小也是 100 兆，因此保持原有的分布式限速不变。只对出方向小带宽，使用单点限速。方案是这样的：

每台 REIP 有自己一个独享的内网地址，只有这台服务器故障时候，这个地址的流量才被分发到其他三台服务器。

入方向流量被分到四台 REIP 服务器后，REIP 处理完通过 tunnel 转发给母机。隧道的外层源地址，只使用其中一台 REIP 服务器的独享的 IP 地址。每个外网 IP 地址在挂载到集群下管理时候，就确定下来了。

母机在接受到网关发过去的流量，解析外层报文地址，并记录在本地会话表里，我们称之为母机的自学习能力。当母机侧转发出方向报文时，就只会使用本地学习并记录的外层地址去封装隧道。这样出方向的流量，就回到单台 TGW 设备上，实现了单点限速。

独享的内网地址本身是有容灾能力：

1）当其服务器故障了，流量就被分散到集群其他服务器，放弃单点限速；
2）当服务器被修复上线后，又可以重新变成精准的单点限速。

这样保证小带宽精准限速的同时，又避免了单点故障。

在限速过程中，还有一个问题，因为 CLB 集群原来的限速是在 CLB 集群上自己做的，引入山海之后，REIP 上有限速能力，那么公网 CLB 的限速要不要挪到 REIP 上？

我们经过多次讨论，最终还是维持**这个限速在公网 CLB 上不变。

这里有几种场景考量：

1）内外网攻击：如果我们把它放到 REIP 上，这里可以扛住外网的攻击，但同时内网的攻击我们是防不住的，因为公网 CLB 上没有限速后，流量内网的攻击就会先把 CLB 上压过载，导致丢包，影响业务的稳定性。

2）有效流量的准确统计：原有架构下，从公网流量首先到达 CLB，我们需要检查公网 CLB 上与 port 对应的服务是否已配置规则并启用。如果没有启用，则将报文直接丢弃且不记录为公网 CLB 的带宽使用量。山海架构下，如果先经过 Region EIP 限速，这类无服务访问流量（如恶意攻击和垃圾流量）也将占用限速资源。尽管这部分限速流量会送达至 CLB 集群，但由于缺乏相应服务支持，它们最终还是将被丢弃。结果导致用户带宽不及预期。比如用户购买 10M 带宽，实际有效运行的仅有 8M 流量，而其余 2M 被无服务流量占用了。

3）多重限速的影响：还有一个这个场景中，当 Region EIP 实施带宽限速后，这些流量最终可能进入公网 CLB。然而，由于 CLB 的规格限制，例如新建连接数或并发连接数已达到上限，部分数据包可能会被丢弃。这些丢失的数据包已经消耗了购买的公网带宽，从而导致用户观察到的公网 CLB 流量带宽未达到预期。因此，我们保留公网 CLB 限速功能不变，仅进行引流调整。

8、山海架构 1.0 的优势

CLB 产品及 REIP 产品，在使用山海 1.0 之后的几点优势。

1）CLB 产品本身支持热迁移，扩容到山海热迁移，不会引起用户的断流，有助于运维做用户产品升级迭代。这方面有个典型案例，比如某台设备坏了或者发现某台设备上有问题，需要把流量迁走的时候，我们可以不用中断用户的流量的。我们了解到，以前有的竞品，因为热迁移做的不是特别完善，在设备出现问题或者是需要升级版本的时候，常选择低峰期做升级。

2）EIP 在做限速的时候，在出方向时是小带宽，可以做到比较精准的限速。好处是用户做压测或测试的时，带宽不会抖动影响自己的业务的稳定性。

3）高低优先级限速。用户买一些比较小的比如 10M 带宽或者 5M 带宽，用来服务本身业务，同时也会 ssh 或者远程桌面登录 EIP；因为一起我们是做无差别的限速丢包的话，这样会造成它本身的控制流量，如远程桌面的流量也会被丢包，造成登录的卡顿。用户需要在不超限速的前提下，优先保证远程桌面不卡，然后再提供其他的下载服务。我们把流量根据端口进行区分，比如 22 端口或者是远程桌面的 3389 端口的流量，标记为高优先级。在做限速时，只要高优先流量不超限速，就全部放行。当高优先级流量再叠加上低优先级的流量超限速时，把低优先级的流量丢掉，这样 ssh 访问服务器的时候能够非常顺畅。

4）山海架构上线后，基于 vip 粒度的调度，可以让调度更加灵活。比如原来一个集群为了节省路由条目，我们按照一个网段发路由，不是每个 VIP 都发路由的。山海两级架构之后，没有了这个限制，就可以按照 VIP，把 CLB 实例调度到不同 CLB 集群。这样如果用户需要一个特别大规格的 VIP 的时候，我们可用一个集群的能力去扛用户一个 VIP，从而满足超大规格实例的诉求。当然真实使用产品时，很少有客户把上百 G 的流量用一个 VIP 来承载。用户出于容灾考虑，通常不会把所有的鸡蛋放到一个篮子里。

9、山海架构 2.0

9.1 概述

如前所述：山海 1.0 主要目标是整合公共网络并将所有公网出口集中在城市核心机房内。至于剩余的 CLB 群集，我们会继续将其保存在原有各机房的专区里。这是因为网关设备有其与服务器不同的网络诉求，例如普通服务器不能提供发布动态路由，并通过动态路由引流处理业务流量。

再比如：网关专区的收敛比 1:1，而服务器虽然带宽也是 100G，但其收敛比率往往小于 1：1。

在这种情况下，我们不能简单地将 CLB 网关群集群平移放置到服务器区。因此，CLB 网关群集通常在构建每个机房时，预先规划并预留相应的网关专区。机房建设起来后，如业务量小，又会因预留资源空置造成浪费。目前专区闲置机位也是一笔较大的费用。

同时，还有一种临时扩容的需求场景，例如 VIP 大客户，临时会有大流量的转发需求，这时常态运营水位没法满足需要，需要调配设备做集群扩容。如果本机房的设备不够还需要跨机房搬迁，搬迁周期比较长，对我们运营压力会很大。

所以，我们希望通过山海 2.0 能把专区建设的空置率降下来，同时提升弹性，能够低成本的快速扩缩容。

9.2 引流交换机

在山海 2.0 里，我们采用了“引流交换机”。在每个机房的建设时，我们可以放置两组共四台引流交换机。

考虑到单个交换机的容量可以达到 1 T 以上，有四台交换机工作，一个机房能够承受大约 4T~ 6T 的流量峰值。这意味着后续无需再额外扩容，一次性的建设和布局就可以满足长期的需求。相比于 CLB 群集占用的机位空间，四台交换机所需的机位显著减少。

我们把原来 CLB 集群对外声明路由的能力放到了引流交换机上，把 CLB 服务器用用通用服务器区的设备来代替。考虑收敛比和容灾，不会把一个集群放到一两个机架上，会相对分散些，更不会把整个机架全部再用成 CLB 集群。这样 CLB 集群不再单独建设网关专区，引流交换机把路由声明发出去，通过隧道跟 CLB 设备转发流量。

9.3 山海 2.0 的变化

我们以内网 CLB 为例，原来一台虚拟机访问 CLB 集群，CLB 集群把它的流量转到对应的 RS。

引入交换机之后，其进出两个方向都会有变化：入方向（访问 LB 方向），虚拟机的流量先被引流到了引流交换机，交换机把报文做一次封装，然后发送给对应的服务器，进行负载均衡转换。最后处理后的结果，被转发给真正的 RS。原来的两跳访问变成了现在的三跳。同样反方向流量返回时，RS 的流量先回到引流交换机，然后被分发到对应的 LD 设备上。LD 处理完之后，再把报文直接转到 client 虚拟机上。借助引流交换机的中转，我们就能够让负载均衡的专区设备的放到普通的服务器区里。

另外：这里的 CLB 服务器，可以跟其他的网关包括母机复用一些相同机型的服务器，当需要扩容时，就可以使用通用服务器。而不像以前 CLB 既有自己独立的机型，又对服务器的物理位置有要求。有了引流交换机跟 LD 之间是做隧道传输，LD 具体的物理位置就没有像原来一样有硬性的要求。这样 CLB 可以通过通用服务器区域，调配服务器。

最后一项是：原有跟 REIP 类似的，CLB 设备做路由通告时，也是按照网段通告，有引流交换机之后，我们可以在引流交换机上去做细粒度的调度，一个 VIP 或是几个 vip 放到一个集群。还可以在引流交换机上做更细粒度的调度，如 IP+port 这样的五元组的粒度的调度。

10、未来展望

目前网关设备最重要也是最大的一个方向就是做高性能、硬件卸载。依赖硬件来实现高性能的转发。

网关设备分为有状态和无状态两种：

1）无状态设备就像 IP 转换一样，只要依据规则，任何时刻来了报文，转换出来的形式都是固定的；
2）有状态设备是需要记录 TCP、 UDP 状态，记录转发到后端设备，当不同的时间转发即使相同的类型的流量，它转发的目的地也不一样，转换的格式也可能不一样。

硬件卸载在有状态和无状态时，基本上用到的设备都是 DPU 和交换机，用到的介质几乎都是 FPGA。

FPGA 和 ASIC 本质上是一个东西，无论友商还是我们自己内部研发，更多的是 FPGA 上做功能，并小规模的灰度上线验证，一旦稳定下来，就转化成批量的 ASIC，以此来降低成本。

DPU 和交换机在无状态设备上，交换机相对更有优势，因为无状态设备对容量的要求相对小些，像 EIP 网关以及内部无状态的网关大多用交换机形态实现。DPU 目前更多的用在母机侧，做有状态类的网络处理。当然，采用 DPU 不仅仅局限网络诉求，还有存储安全等其他需求。去年英特尔宣布已不再进行交换机 tf 芯片的演进迭代，大家对交换机的质疑会增大。

所以，也衍化了另一种方案：在一台额外的服务器中插入 DPU 网卡以实现卸载功能。

但不同方案有不同的优缺点：

1）使用交换机的最大优势在于其强大的交换性能（可达 1T 或几个 T 及更高），可支持很大的接入容量。但是，交换机仅能是一个底座，若要扩展容量仍需依赖 FPGA 技术。

2） DPU 的优点则包括成熟的产业链、庞大的产量以及稳定的供应保障；此外，由于 DPU 在母机侧已被广泛验证和采用，许多功能的实现都相对固定。

这是两种方案各自的优缺点。

在两个产品运用负载均衡状态的交换上，业内不同的厂家也有不同的玩法，有的是交换机，有的是 DPU。当前，无论是交换机还是 DPU，都依赖 FPGA(ASIC)来做大容量的会话管理，同时越来越多的设备或多或少的支持 P4。在 X86 上进行编程时，通常选择 DPDK。

相较之下：使用 P4 进行编程的门槛较低。P4 编写一般功能需求的代码非常简单快捷，只需一两周时间即可完成，甚至对于熟练者来说，可以在几个小时就开发出一个小功能。虽然充分发挥硬件的性能，P4 类芯片还需要进行很深入细节的研究，但 P4 还是大大降低了数据面编程的门槛，特别是在高性能转发的需求方面。

另一个特点是：小型化。大家过去比较关注数据中心和海量数据的优化问题，随着业务发展，逐步转向降低运营成本和提高效率的场景，开设小型站点。这类小型站点，是典型的“麻雀虽小，五脏俱全”，希望用尽量少的设备成本来满足各种功能需求。所以我们将设备设计为具有较小规格的产品系列，并在易用性上进行改进，通过集群合并、虚拟机等承担更多的任务负载。这样在业务规模和流量不大，也能以较少的资源应对较高的功能性需求。一旦业务规模扩大，我们可将这些小型站点升级为传统的数据中心级物理设备。

以上未来网关两个主要的方向。