目录

本文是对 TGW: Operating an Efficient and Resilient Cloud Gateway at Scale 的阅读笔记，围绕“生产问题—核心机制—故障边界”整理自己的理解。

• 论文及演讲页面：USENIX ATC ‘25
• 论文 PDF
• 腾讯云团队的技术介绍

文中的 TGW 指 Tencent Gateway。LD（Load Distributor）是转发节点；RS 指后端服务器；VIP 是对外提供服务的虚拟 IP。

一、论文阅读

1. 时间点：这项技术是什么时候提出的？

论文发表于 2025 年 USENIX ATC，实际投入生产时间是2017年，。

2. 生产环境遇到了什么问题？

网络游戏和直播场景对低时延、低抖动、低丢包有严格要求，服务器入口处的网关首先就要满足这些要求。

与此同时，网关面临流量增长、单核热点、海量连接状态、在线扩缩容和设备故障等问题。

3. TGW 如何解决这些问题？

高效报文处理：基于 DPDK 实现高性能转发。

• RTC（Run-to-Completion）：无状态的 TGW-EIP 采用 RTC 模型处理报文。
• Pipeline：有状态的 TGW-CLB 采用 RTC + Pipeline 模型，将报文分发和处理分开。

可扩展的状态管理：通过在线状态迁移应对流量突发、大象流和集群调整，尽量保持服务连续性。

快速故障恢复：通过会话同步与冗余部署提高故障韧性，维持服务可用性。

4. 整体架构

TGW采用层次化模块设计，将网关系统分为以下3个部分：

• 转发平面：分为无状态的TGW-EIP（弹性公网接入）和有状态的TGW-CLB（云负载均衡）。
• 控制平面：包括全局管理平面（Orchestrator）、集群本地控制平面（Operator）和分布式数据平面（Load Distributor, LD）。
• 辅助组件：路由发布（BGP+ECMP路由）、探针（故障检测）和代理（日志聚合）。

在部署模式，针对不同的云网络功能，TGW的集群部署在云网络的不同位置中：

TGW-EIP部署在区域（Region）入口，TGW-CLB部署在可用区（AZ）内。

4.1 端到端流程（Life of a Request）

工作流程（以入向流量为例）：

1. TGW-EIP：流量通过 BGP 路由引流，经汇聚路由器、接入路由器通过 ECMP 进入 TGW-EIP 集群的各转发节点，由转发节点进行 NAT 和隧道封装。TGW-EIP 集群的后端服务器，可能为弹性的虚拟机，也可以是由 TGW-CLB 集群承载的内网 CLB 实例。
2. TGW-CLB：TGW-CLB 基于服务标识符（如 IP 对或 QUIC 连接 ID）分发流量到后端服务器，执行有状态的路由转发。发往后端的报文同样采用 GRE 隧道封装。为了确保同一连接或同一 VIP 的流量与转发节点的亲和性，上游路由器中配置了奇偶路由的策略。

5. 关键机制

5.1 状态迁移

一个典型场景是：将流量从较小的集群迁移到较大的集群，以应对流量突发或大象流，或者单纯业务增长。

1. 在线迁移：在重定向流量之前，先将旧集群中保存的连接信息转移到新集群。
2. 大部分状态迁移完成后切流：迁移约 90% 的状态后，新集群就可以通过 BGP 宣告 VIP 路由。
3. 处理迁移期间的新连接：旧集群仍可能建立新状态；新 LD 遇到未命中的连接时，将报文交给旧集群处理。
4. 快速收敛：旧 LD 进行代理转发时，保留来自新 LD 的隧道封装信息，使回程能够经过新 LD。
5. 状态聚合：以 VIP 为粒度管理迁移状态。

90% 并不是“剩余状态可以直接丢弃”的意思。迁移期间仍需要旧集群代理，维持原来的后端选择。

5.2 故障韧性

1. 集群内：状态同步采用选择性、批量的方式：

• 优先同步存活超过 3 秒的连接；3 秒是工作负载下的经验选择。
• 使用 UDP 批量发送，减少同步报文数量；批次达到 MTU 或达到超时条件时发送，并非一直等到攒满 MTU。
• 避免为大量短连接承担额外同步开销，同时接受未备份连接的恢复风险。

2. 多级容错模型：

分散式迁移用于缩小异常流量引发的故障范围。例如，某个 VIP 的异常报文触发 LD 崩溃时，可以将受影响集群的 VIP 集合分成多组，分散到其他集群，降低单个故障 VIP 对其他业务的影响。这里的分组对象是 VIP 集合，不能简单理解成把同一个 VIP 的所有流量随机分成十份。

5.3 故障检测与定位

基于污点的遥测通过 TP（Trace Point）记录经过的位置，通过 DP（Drop Point）记录丢包原因。

• 观测点：多个拥有公网 IP 地址的探测服务器。
• 日志分析：在线与离线分析相结合。
• 定位方法：通过 TP 识别报文经过的 LD，通过 DP 查找明确的丢弃环节和原因。

探测报文与日志的关系可以分开理解：

1
2
3
4
5
6
7
8
9
10
11
12
13

Prober TX
   │ SYN：携带探测标记
   ▼
LD RX
   │ 记录 TP，并写入唯一 LD ID
   │
   ├── 正常：LD TX → Backend
   │                     │
   │                     │ 将污点复制到 SYN/ACK
   │                     ▼
   │              SYN/ACK → LD → Prober
   │
   └── 异常：记录 DP 和丢包原因 → 日志分析

DP 是丢包定位证据；不能把记录 DP 理解为丢弃的报文仍会沿正常响应路径返回。

5.4 运维经验

可用性建设的两个关键词是 故障域隔离 和 冗余。

• 解耦：在 Region、AZ、Cluster 等层次划分模块，同一层的模块也尽量彼此解耦。
• 冗余：包括 AZ、机架、机器，以及网卡和光纤链路等多个层次。

6. 代入一个系统设计场景

设计一个Load Balancer

6.1 解决什么 workload？

长连接状态较多，需要避免长连接断开，防止抖动。

6.2 提供什么 consistency？

• 正常运行时，同一条连接持续映射到同一个后端。
• 故障/计划上下线期间，即使报文改走新 LD，也应保持原来的后端选择。

6.3 故障如何恢复？

6.4 规模上限在哪里？

• 单核处理上限：单条大流或一个亲和组可能压满一个核。
• 单机 PPS、网卡带宽、内存访问和状态表容量。
• 状态迁移带宽，以及代理旧集群产生的流量放大。
• 故障后剩余节点的处理能力。
• 备用集群和跨 AZ 链路容量。

7. 后续演进方向与取舍

我的理解是，应先判断主要瓶颈在哪里：

• 当瓶颈主要来自通用 CPU 的转发成本时，可以考虑硬件卸载。
• 当瓶颈主要来自状态迁移与同步时，可以考虑减少需要复制的状态，或者改变状态放置位置。

不同瓶颈对应不同的演进方向。

二、网关知识与思考题

1. 什么是“状态”？

讨论状态迁移之前，需要先区分状态属于哪一层。

2. Pipeline 的必要性

某业务希望同一客户端的 TCP 和 UDP 流由同一个处理核负责。仅依赖五元组 RSS 会遇到什么问题？增加 dispatcher 后又引入哪些成本？

可以沿着 ECMP → RSS → dispatcher → worker 路径，分别思考机器选择、队列选择和处理核选择，而不是把它们看成同一次负载均衡。

3. 90% 切流的安全性

连接 F 的状态只在旧 LD1 上，新集群已经开始接收 F 的后续报文。报文如何抵达原后端？为什么旧集群的其他 LD 不会重复转发？

新 LD 在迁移期间遇到状态未命中，将报文复制给旧集群的各个 LD；只有状态标记的原始创建者继续转发，从而保持原来的后端选择，并避免重复转发。

4. 快速收敛的关键字段

如果旧 LD 把 GRE 外层源 IP 改成自己的地址，回程学习会发生什么变化？如果后端长时间不回包，快速收敛机制会受到什么影响？

如果旧 LD 改成自己的外层源 IP，vSwitch 就会学到旧 LD，回程无法按这个机制切到新 LD。后端长时间不回包时，也需要考虑依赖回程学习的收敛条件是否仍然满足。

5. 选择性同步的代价

一条建立了 1 秒的连接遇到 LD 崩溃，另一条已经持续 10 分钟、备份成功的连接也遇到同样故障。能否给予它们相同的恢复保证？为什么？

在作者观察到的工作负载下，备份大量短连接的成本较高，而其中很多连接在备份完成前就结束了。因此，系统选择优先备份持续活跃的连接，并接受未备份连接的恢复风险。

6. 分散式迁移的失效条件

一个集群服务 100 个 VIP，其中 VIP37 的报文会触发崩溃。如何分成十组？如果触发条件同时存在于 30 个 VIP 中，“影响缩小到十分之一”的判断还成立吗？

1
2
3
4
5

VIP 1–10   → 备用集合 A
VIP 11–20  → 备用集合 B
VIP 21–30  → 备用集合 C
VIP 31–40  → 备用集合 D  ← VIP37 在这里
……

这个例子提醒我，故障隔离效果取决于触发条件在各个 VIP 分组中的分布，不能脱离故障分布直接套用“十分之一”。

7. 定位证据是否充分？

Prober 发出了 SYN，没有收到 SYN/ACK，也没有看到 DP 日志。能否直接判断 LD 崩溃？下一步需要从哪些位置获取证据？

根据 TP 查找经过的路径，根据 DP 查找丢弃证据。没有响应且没有 DP 日志，并不足以直接证明 LD 崩溃，还要检查探测路径和日志链路是否完整。

8. 网关恢复与业务恢复

LD 故障后，新 LD 已恢复原来的五元组到后端的映射，但后端游戏进程同时重启了。为什么玩家仍可能掉线？需要在哪一层补充能力？

这里需要分别考虑 传输连接恢复、应用会话恢复、业务状态恢复。恢复网关映射，不等于恢复 TCP 端点状态，更不等于恢复游戏进程中的业务状态。

9. 奇偶路由是什么意思？

数据包先通过核心路由器再通过接入路由器，TGW前面有多个接入路由器，对于分片的数据包，如果都按IP对做ECMP，也不天然保证选择结果相同。为了让所有分片都进入同一个接入路由器，需要使用奇偶路由。（这里其实有疑问，交代的不清楚，即便是奇偶路由，如何在奇数路由器中进行选择也是问题，奇数路由器可能包含多个）

10. 从运维经验可以学到什么

1. 故障域隔离：不要让局域故障扩散；
   • region\az\集群分层解耦，控制与调度按地域划分；
   • 将业务分散到不同集群、限制单次故障影响到vip范围；
   • 对会触发网关崩溃的一场流量，分散迁移；
2. 冗余：不仅有备用，还要能接得住；
   • 多层冗余：az、机架、机器、网卡/光纤多层冗余；
   • 集群节点跨机架部署，az之间互为备份；
   • 剩余资源必须能够承载故障后的全部流量；
3. 集群管理：安全上线、在线调整、可控退出；

• 新集群先进行无流量配置检查，再引入地址并持续探测。
• 流量增长时，通过迁移流量扩容。
• 缩容或维护时，先隔离路由，再释放资源。
• 避免频繁切换 CPU C-State 带来处理延迟和抖动。

4. 协议优化：降低复杂度，保证报文落点一致

• 状态同步改为单播；
• 奇偶路由；（有疑问，思路可以借鉴）