亿级用户IM系统之接入网关负载均衡架构（一、网络结构与DPVS部署）

今天看到一个年薪百万的工作，某通信公司招亿级用户的IM系统的总负责人，其中一项工作是对接入网关进行负载均衡优化。今天我把AI给出的方案总结一下，一起讨论一下亿级IM的构架。

首先我们肯定会想到入口用DPVS做负载均衡，但是这样一个量级的系统，在网络拓扑上就要求很高。

一、多地区接入 + 本地多运营商接入架构

针对亿级用户IM核心痛点：跨运营商延迟高、单机房故障雪崩、区域用户接入卡顿，采用异地多活机房 + 单机房三运营商多线接入架构。

1. 多地区接入（全局容灾与响应速度）

部署多地域核心机房（北上广深等），实现用户就近接入，规避单城市机房断电、光缆中断、区域故障导致全平台IM瘫痪；
全局流量由DNS-GTM做跨机房调度，单机房故障自动切流，保障亿级用户接入连续性。
一般至少选华北，华中，华南，三个地区做机房。

2. 单机房多运营商接入（无公网BGP单IP方案，企业通用落地版）

一般为了保险，同时为了不同网系用户的效率，我们需要三大运营商都接入机房，但是如果使用同一个虚拟IP在三个网上提供服务，还是有点难度的：

想要同一个公网 VIP 同时向电信、联通、移动三家广播 BGP 路由，需要两样东西：

自己的 AS 号（自治系统号）
属于你 AS 名下的公网 IP 段（IPv4，至少 / 24）
和至少两家运营商建立 eBGP 邻居（多宿主 Multi‑homing）

这里为了具有普遍的可操作性，按另一种方式来：

无自有AS自治域、无公有BGP广播权限，不做高成本BGP单IP多线；
机房同时接入电信、联通、移动三条独立物理专线，三家运营商分配独立公网IP段；
最终形成3个独立公网VIP（电信VIP/联通VIP/移动VIP），单套DPVS集群同时承载三线VIP，无需三套硬件集群，资源复用最大化；
彻底规避跨运营商访问延迟、丢包、限速问题，保障IM长连接稳定。

这里先上一张总体的拓扑图，如下：

二、DNS调度方案（全局流量管理）

多运营商多IP架构无法依赖普通DNS ，必须使用云端智能DNS-GTM（阿里云/腾讯云/火山引擎商用服务，大厂主流），这样的DNS才具有如下能力：

运营商精准视图解析：针对用户使用网络来判断返回入口的VIP具体是哪个：电信用户返回电信VIP、联通返回联通VIP、移动返回移动VIP，精准匹配用户网络，保证响应速度；
故障自动切换：实时探测三条运营商专线/VIP可用性，某运营商线路中断、VIP不可达时，自动将该运营商用户调度至剩余正常线路；
跨机房容灾调度：配合多地域机房，实现用户就近接入、机房故障全局切流；
缓存优化TTL设置5-30秒，兼顾切换时效性与解析性能，适配IM业务快速容灾需求；
架构分工：DNS负责全局流量调度，机房网络负责流量承载，解耦容灾能力。

三、路由器 + 核心交换机冗余方案（全程无单点）

通常情况下，我们考虑都是带宽，尤其在云上购买服务器时候，更不需要操作物理设备，而自建机房则需要考虑网络设备的单点故障问题，这里一般需要一个网络工程师来管理和维护（CCNP水平）。

核心要求：网络设备零单点、故障秒级收敛、无人工介入容灾，全程采用独立双设备冗余，禁止IRF/VSS堆叠（规避堆叠分裂风暴风险）。

1. 出口路由器层冗余

部署两台独立出口路由器ROUTER_A/ROUTER_B; 因为这里DPVS不使用VRRP主备模式（切换有时间差，二次开发工作量大，双机热备浪费资源等等问题），这里多个DPVS服务之间依靠BGP路由收敛实现容灾与动态负载均衡；
三条运营商专线全部双光口上联，每条专线分别接入两台出口路由器，单条线路/单台路由器故障不影响整体；
路由器与核心交换机建立iBGP+BFD，实现百毫秒级故障切换。

出口路由器ROUTER_A/ROUTER_B（机房出口，对接电信 / 联通 / 移动三条运营商专线）

亿级机房出口，不能用 AR 系列企业路由器（AR6xxx 性能、路由表规格不足），要用NetEngine 8000 M 系列运营商级盒式路由器。

推荐型号：NE8000‑M8（盒式，双主控，可插业务板卡）

配置两块 10GE 光口板卡，提供多组 10GE WAN，对接三家运营商物理专线；同时 10GE 内网口对接 Core‑A、Core‑B；
能力：完整 BGP、BFD，大路由表，运营商级转发；双主控、双电源冗余。
单台裸机（主机 + 双主控 + 基础板卡）参考：6‑8 万 / 台，两台合计 12‑16 万。

规模缩小版，如果单机房带宽小于 30G，流量压力中等：NE8000‑M4 ，单台 4‑6 万。 ❌AR6280、AR6300 属于企业分支路由器，不适合 IDC 机房公网出口跑运营商 BGP，转发和路由表规格扛不住亿级用户公网路由。

2. 核心交换机层冗余（架构核心）

部署两台独立三层核心交换机CoreA/CoreB，禁止堆叠，规避二层风暴、IP冲突风险；
所有关键设备（出口路由器、DPVS集群、Nginx七层网关）全部双物理光口分别上联两台核心，杜绝单链路、单核心单点；
后端上百台业务服务器（如果每台服务器支持100万TCP，那么1亿个长连接就是100台IM网关，事实上应该没有那么多），通过二层接入交换机入网，接入层双上联核心，仅做二层转发、不跑BGP，故障域隔离，不影响核心接入网关；
核心层开启ECMP、BFD、路由策略，支撑全网负载均衡与快速收敛。

核心交换机 Core‑A、Core‑B（本方案的两台三层核心）

推荐型号：CE6857‑48S6CQ‑EI（CloudEngine 6857）

端口：48×10GE SFP + 光口，6×100GE QSFP28（兼容 40GE）
关键能力：硬件 BFD 最小 3.3ms，BGP、ECMP，IPv4 路由表 6M，32MB 大缓存，1+1 电源冗余，完全满足 DPVS FRR iBGP+BFD ECMP 多活场景。
用途：
1. DPVS 集群、Nginx 七层网关直连 10GE到两台核心；
2. 出口路由器 10GE 上联核心；
3. 接入交换机双上联核心；
参考单台裸机价格：18000‑22000 元，两台合计≈3.6‑4.4 万。

光模块另算：10GE 多模、10GE 单模、100GE 模块单独采购。
升级备选（业务流量很大，未来上 25GE 服务器）：CE6865E‑48S8CQ‑EI（48×25GE，8×100GE），单台价格 4‑5 万。
❌不要用 S57、S67 系列园区交换机：路由表规格、硬件 BFD 性能不够，不适合 IDC 数据中心核心跑 BGP‑ECMP。

四、DPVS接入拓扑核心规则

机房内部多台 DPVS 组成集群，通过 FRR软件（或者BIRD也可以）外挂 BGP 协议向双核心交换机动态上报相同的公网 VIP 路由，所有 DPVS 节点同时拥有相同 VIP、同时在线、同时承接流量 。核心交换机通过 ECMP 等价路由机制 ，自动将用户流量按五元组哈希 均匀分发到所有 DPVS 节点，实现真正多活负载均衡。

该架构彻底抛弃传统 Keepalived+VRRP 双机热备模式，原因如下：

双机热备存在闲置备机，同一时间只有一台干活，资源浪费，无法横向扩容；而 BGP-ECMP 所有节点全活，性能随机器数量线性叠加，适配亿级 IM 并发。
VRRP 是主备单点，主机故障需要秒级切换，存在切换抖动、丢包、脑裂风险，集群规模越大越不稳定。
VRRP 无法做精细流量均分，只能整机切换，不支持弹性负载分担。
BGP-ECMP 天然支持水平扩展，随时增减 DPVS 节点，无需改配置、无业务中断，适合大规模长连接网关。
故障粒度更细：单台 DPVS 异常自动撤销路由，被 ECMP 平滑剔除，其余机器无缝承接，远比 "整机主备切换" 更稳定、更精细。

总结一句话：VRRP 是老旧双机替补架构，BGP-ECMP 是互联网大厂亿级网关的标准多活架构。

那么，

这里需要严格区分核心设备与普通业务设备组网逻辑，这是IM网关架构的核心问题：

DPVS集群、Nginx七层网关直连核心交换机 ，严禁经过"接入层交换机"**，避免二层抖动、STP震荡、多跳链路导致BFD/BGP邻居抖动，保障长连接网关极致稳定；
上百台后端IM/API业务服务器，通过二层接入交换机接入核心，实现端口扩容、故障隔离；
全网架构分层：公网DNS调度→运营商专线→双出口路由→双核心交换→DPVS四层负载→Nginx七层网关→业务集群；
单套DPVS集群统一承载电信/联通/移动三线VIP，硬件资源复用，简化运维。

备注：这里解释为啥需要多一层nginx做7层转发，而不是直接接入IM网关。如果业务简单（只是纯 TCP 透传），可以不要七层；但你的业务涉及文本、文件、未来 HTTP 服务分流，七层 Nginx 是架构的"大脑"，它让流量管理变得极其灵活可控，是支撑亿级用户复杂业务的"必选项"。这套"四层扛量 + 七层路由"的分层架构，也正是微信、钉钉等大型 IM 系统普遍采用的核心设计思路。

五、DPDK版本选择与核心补丁（生产必改）

DPVS基于DPDK转发，版本与补丁直接决定BGP集群能否正常运行，是极易踩坑的生产关键点：

固定生产版本：DPDK 20.11 LTS（工业界DPVS最稳定版本，适配所有长连接场景）；
必打核心补丁 ：DPDK原生KNI网卡存在组播报文丢失BUG，BGP/BFD依赖组播通信，不打补丁邻居无法建立；
补丁作用：修复KNI网卡无法同步内核组播订阅问题，让BGP、BFD组播报文正常送达内核FRR/BIRD进程；
配套可选补丁：UOA校验和修复，适配UDP IM消息场景；
高版本DPDK（23.11+）已废弃KNI，架构变更，不建议亿级存量业务升级。

这里之所以要打补丁，主要是因为：

原生 DPDK KNI 的 bug（老版本 DPDK 17.11 /20.11）

KNI 是 DPDK 提供的虚拟网卡，作用：把少量控制报文（BGP/BFD）递交给 Linux 内核栈，交给 FRR 处理。

原生 KNI 有一个缺陷：

Linux 内核给 KNI 网卡加入组播组的时候（FRR 启动 BGP 会自动做这个操作），内核发出 netlink 通知，但是原生 DPDK‑KNI 驱动没有处理这个通知 。结果：物理网卡上收到的组播报文（BGP、BFD）不会转发到 KNI 内核网卡。

现象就是：

KNI 单播 ping、ssh 访问完全正常；
FRR/Bird 进程启动，BGP 邻居怎么都起不来；
tcpdump 抓 KNI 网卡，看不到 BGP 的组播报文；
单播 BGP 邻居可以通，iBGP 默认组播邻居直接失败。

补丁0001‑kni‑use‑netlink‑event‑for‑multicast‑driver‑part.patch，就是修复这个：监听内核 netlink 组播事件，内核加入哪个组播组，DPDK 侧同步接收对应的组播报文，递交给 KNI 内核网卡GitHub。

简单大白话：

FRR 要跑 BGP，需要监听组播地址；原生 KNI "看不见" 组播包，BGP 握手报文到不了 FRR 进程，邻居建立失败。打上补丁，KNI 才会把组播包交给 Linux 的 FRR。

第二个补丁 0002

用于 UOA 模块（UDP 真实源 IP 获取），修复报文 checksum 计算问题，如果你业务有 UDP 才需要，纯 TCP 业务可以不用。

重要版本提醒

DPDK 23.11 版本之后，官方已经彻底移除 KNI 模块，DPVS 改用 virtio‑user 替代 KNI，就不再需要这套 KNI 补丁了GitHub。
现在工业界 DPVS 还大量在用 DPDK‑20.11 LTS，这个版本 KNI 依然存在这个组播缺陷，生产必须打补丁。
补丁只影响控制平面（BGP/BFD），业务数据流（DPDK 转发用户流量）不受补丁影响。

容易踩坑

❌不要误以为："我改成单播 BGP 邻居就可以绕开补丁"。BFD 协议也会用组播，就算 BGP 改成单播，BFD 依旧异常。
❌KNI 补丁不修改 DPVS 四层转发逻辑，只是修复 DPDK 和 Linux 内核交互。
补丁只针对老的 rte_kni.ko 内核模块；新版本 virtio‑user 模式没有这个问题。

极简总结

原生老 DPDK KNI：无法同步内核的组播订阅，BGP/BFD 组播报文送不到 FRR 进程。
打补丁：让 DPDK 监听内核 netlink，同步组播地址，组播报文正常上送到 KNI，FRR 才能正常建立 BGP+BFD 邻居。
业务流量完全不受影响；只修复控制面。
DPDK 新版本已经废弃 KNI，改用 virtio‑user，就不需要这套补丁。

我们整套 BGP‑ECMP 架构，完全依赖 BGP+BFD，所以这个补丁绕不开。

六、控制面组件：FRR/BIRD 外挂路由协议栈

核心知识点：DPVS/DPDK只有数据面（转发），无协议控制面，必须外挂路由组件实现ECMP多活。

选型：生产优先FRR（命令行兼容华为/思科，网工友好、稳定性强），备选BIRD；
组网模式：机房内部使用私有AS 64512（免费、无需官方申请，仅内网iBGP使用）；
邻居建立：每台DPVS通过内核KNI独立内网IP，同时与CoreA/CoreB建立iBGP邻居，绑定BFD快速故障检测；
路由宣告：每台DPVS统一向核心宣告三线VIP/32路由，核心交换机形成ECMP多下一跳 ，实现所有DPVS节点全活负载分担，无主备、无冷机；
核心容灾逻辑：自研外部健康检测Agent，探测DPVS转发异常时，主动调用FRR撤销路由，将故障节点踢出ECMP集群，避免转发卡死但BGP存活的假性存活故障。

解释3个概念：

FRR（FRRouting）

Quagga的继任开源分支，DPVS生产环境首选。

命令行 vtysh，语法风格模仿华为、思科网络设备，网络工程师上手成本低。
多daemon架构：bgpd处理BGP、bfdd处理BFD、zebra负责和Linux内核交互路由表。
在我们架构里：DPVS机器依靠KNI网卡的内核协议栈 ，FRR跑iBGP+BFD，向Core‑A/Core‑B宣告 /32 的VIP路由；故障时撤销路由。
优点：协议完整、社区活跃，云厂商MetalLB底层就是FRR；BFD、EVPN、VRF支持完善，IDC数据中心广泛落地。
缺点：配置文件零散，路由策略要用route‑map、prefix‑list组合，写复杂过滤比较啰嗦。

BIRD（BIRD Internet Routing Daemon）

另一套成熟开源BGP路由栈，单进程架构，内存占用更低，路由过滤语法非常强大。

有自己一套独立配置语法，不是交换机CLI风格，网工需要重新学习。
强项：复杂BGP策略、大规模路由表；大量用于IXP互联网交换中心、CDN节点。
本场景可以用，但不是首选。
对比FRR：
- FRR：贴近硬件交换机命令，运维友好，DPVS方案优先选FRR。
- BIRD：策略语言强大，内存开销小；适合做路由反射器、复杂路由过滤。

两者在我们DPVS场景做的事情完全一样：建立iBGP+BFD，发布/撤销VIP的32位主机路由。

为什么还需要额外外挂Agent（自研程序）

⚠️关键点：FRR/BIRD只能检测BGP邻居、网络连通性；感知不到DPVS数据面转发是否已经卡死 。极端故障现象： DPVS进程内部异常、DPDK转发卡死、长连接处理异常，但是Linux内核、KNI网卡、FRR进程完全正常，BGP+BFD邻居UP，路由还在向外宣告。交换机ECMP继续把流量打过来，这台DPVS已经无法转发数据包，产生黑洞，但是网络层面看不出故障。 👉 FRR/BIRD无法感知DPDK用户态转发面故障，必须外置Agent。

外挂Agent必备核心功能（IM亿级网关）

探测DPVS数据面真实可用性
- 调用DPVS本地 dpip 工具，查看DPVS进程存活、LIP池耗尽、RealServer状态；
- 本地模拟TCP探测本机VIP+IM接入端口，走DPVS转发路径，验证真实转发通路是否通，不能只探测内核端口。
采集DPVS运行指标 连接数、CPU占用(lcore)、丢包统计、LIP地址池剩余量、内存、DPDK驱动状态。当资源临近阈值，主动把节点慢慢踢出集群。
控制FRR/BIRD，动态发布/撤销VIP路由
- 健康：通知FRR，向Core‑A/Core‑B宣告VIP/32路由；
- 异常：调用FRR vtysh命令，撤销VIP路由，上游ECMP自动把本台DPVS剔除流量；
- 恢复后，重新注入路由，流量重新分担过来。
本地保护逻辑（防抖动） 失败不能立刻删路由，连续N次探测失败才执行撤销；恢复也需要稳定几次再发布；防止抖动反复上下路由。
告警、日志上报 路由撤销、DPVS异常、资源水位打满，上报监控告警。
可选：DPVS配置管理 修改real‑server、调整权重，对接运维平台API。

注意：Agent不去接管BGP协议本身，只是作为决策者，下发指令给FRR/BIRD执行路由增删。

简单一句话总结

FRR/BIRD：网络控制面，负责和交换机BGP会话、发布/撤销VIP路由，处理BFD；看不到DPDK转发面死活。
外挂Agent：业务健康大脑，真正检测DPVS转发能不能干活，出问题指挥FRR把路由撤掉，避免流量黑洞。

七、DPVS运行模式与核心生产配置

DPVS有多种工作模式：FNAT、DR、Tunnel、NAT、SNAT；

生产唯一选型：Full-NAT模式（放弃DR模式），完美适配BGP-ECMP多活架构，是IM长连接网关标准方案。

1. 模式选型原因

DR模式需要Nginx/RS配置VIP回环地址，多节点部署会触发ARP冲突，完全不适用多活ECMP集群；
Full-NAT模式VIP仅存在于DPVS的DPDK用户态，后端所有服务器无需配置VIP，零ARP冲突，适配大规模集群。

2. 核心配置关键点

开启Full-NAT，配置充足内网LIP地址池，用于亿级长连接SNAT转换；
后端RealServer指向Nginx七层网关集群，DPVS内置RS健康检查，自动摘除异常节点；
部署TOA内核模块：Nginx服务器加载toa.ko，解析TCP自定义选项，获取真实客户端IP（Full-NAT模式必备）；
架构固有特性：ECMP扩缩容会导致五元组哈希漂移，存量TCP长连接断开，IM业务必须实现客户端自动重连，网络层无法规避；
彻底废弃传统Keepalived+VRRP主备模式，高可用完全依赖BGP-ECMP+自研健康Agent。

到此，我们大概清楚了单个机房如何设计拓扑，如何使用DPVS做多活的负载均衡；但是当用户的连接真正打到IM网关上后，每个连接上的负载也不一样，进而造成IM网关的负载不均衡，我们下文再说！

（未完待续）

亿级用户IM系统 之 接入网关负载均衡架构（一、网络结构与DPVS部署）