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

今天看到一个年薪百万的工作某通信公司招亿级用户的IM系统的总负责人其中一项工作是对接入网关进行负载均衡优化。今天我把AI给出的方案总结一下一起讨论一下亿级IM的构架。首先我们肯定会想到入口用DPVS做负载均衡但是这样一个量级的系统在网络拓扑上就要求很高。目录一、多地区接入 本地多运营商接入架构1. 多地区接入全局容灾与响应速度2. 单机房多运营商接入无公网BGP单IP方案企业通用落地版二、DNS调度方案全局流量管理三、路由器 核心交换机冗余方案全程无单点1. 出口路由器层冗余出口路由器ROUTER_A/ROUTER_B机房出口对接电信 / 联通 / 移动三条运营商专线推荐型号NE8000‑M8盒式双主控可插业务板卡2. 核心交换机层冗余架构核心核心交换机 Core‑A、Core‑B本方案的两台三层核心推荐型号CE6857‑48S6CQ‑EICloudEngine 6857四、DPVS接入拓扑核心规则五、DPDK版本选择与核心补丁生产必改原生 DPDK KNI 的 bug老版本 DPDK 17.11 /20.11第二个补丁 0002重要版本提醒容易踩坑极简总结六、控制面组件FRR/BIRD 外挂路由协议栈FRRFRRoutingBIRDBIRD Internet Routing Daemon为什么还需要额外外挂Agent自研程序外挂Agent必备核心功能IM亿级网关简单一句话总结七、DPVS运行模式与核心生产配置1. 模式选型原因2. 核心配置关键点一、多地区接入 本地多运营商接入架构针对亿级用户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路由收敛实现容灾与动态负载均衡三条运营商专线全部双光口上联每条专线分别接入两台出口路由器单条线路/单台路由器故障不影响整体路由器与核心交换机建立iBGPBFD实现百毫秒级故障切换。出口路由器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‑EICloudEngine 6857端口48×10GE SFP 光口6×100GE QSFP28兼容 40GE关键能力硬件 BFD 最小 3.3msBGP、ECMPIPv4 路由表 6M32MB 大缓存11 电源冗余完全满足 DPVS FRR iBGPBFD ECMP 多活场景。用途DPVS 集群、Nginx 七层网关直连 10GE到两台核心出口路由器 10GE 上联核心接入交换机双上联核心参考单台裸机价格18000‑22000 元两台合计≈3.6‑4.4 万。光模块另算10GE 多模、10GE 单模、100GE 模块单独采购。升级备选业务流量很大未来上 25GE 服务器CE6865E‑48S8CQ‑EI48×25GE8×100GE单台价格 4‑5 万。❌不要用 S57、S67 系列园区交换机路由表规格、硬件 BFD 性能不够不适合 IDC 数据中心核心跑 BGP‑ECMP。四、DPVS接入拓扑核心规则机房内部多台 DPVS 组成集群通过 FRR软件或者BIRD也可以 外挂 BGP 协议向双核心交换机动态上报相同的公网 VIP 路由所有 DPVS 节点同时拥有相同 VIP、同时在线、同时承接流量。核心交换机通过ECMP 等价路由机制自动将用户流量按五元组哈希均匀分发到所有 DPVS 节点实现真正多活负载均衡。该架构彻底抛弃传统 KeepalivedVRRP 双机热备模式原因如下双机热备存在闲置备机同一时间只有一台干活资源浪费无法横向扩容而 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网卡存在组播报文丢失BUGBGP/BFD依赖组播通信不打补丁邻居无法建立补丁作用修复KNI网卡无法同步内核组播订阅问题让BGP、BFD组播报文正常送达内核FRR/BIRD进程配套可选补丁UOA校验和修复适配UDP IM消息场景高版本DPDK23.11已废弃KNI架构变更不建议亿级存量业务升级。这里之所以要打补丁主要是因为原生 DPDK KNI 的 bug老版本 DPDK 17.11 /20.11KNI 是 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 业务可以不用。重要版本提醒DPDK23.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同步组播地址组播报文正常上送到 KNIFRR 才能正常建立 BGPBFD 邻居。业务流量完全不受影响只修复控制面。DPDK 新版本已经废弃 KNI改用 virtio‑user就不需要这套补丁。我们整套 BGP‑ECMP 架构完全依赖 BGPBFD所以这个补丁绕不开。六、控制面组件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个概念FRRFRRoutingQuagga的继任开源分支DPVS生产环境首选。命令行vtysh语法风格模仿华为、思科网络设备网络工程师上手成本低。多daemon架构bgpd处理BGP、bfdd处理BFD、zebra负责和Linux内核交互路由表。在我们架构里DPVS机器依靠KNI网卡的内核协议栈FRR跑iBGPBFD向Core‑A/Core‑B宣告/32的VIP路由故障时撤销路由。优点协议完整、社区活跃云厂商MetalLB底层就是FRRBFD、EVPN、VRF支持完善IDC数据中心广泛落地。缺点配置文件零散路由策略要用route‑map、prefix‑list组合写复杂过滤比较啰嗦。BIRDBIRD Internet Routing Daemon另一套成熟开源BGP路由栈单进程架构内存占用更低路由过滤语法非常强大。有自己一套独立配置语法不是交换机CLI风格网工需要重新学习。强项复杂BGP策略、大规模路由表大量用于IXP互联网交换中心、CDN节点。本场景可以用但不是首选。对比FRRFRR贴近硬件交换机命令运维友好DPVS方案优先选FRR。BIRD策略语言强大内存开销小适合做路由反射器、复杂路由过滤。两者在我们DPVS场景做的事情完全一样建立iBGPBFD发布/撤销VIP的32位主机路由。为什么还需要额外外挂Agent自研程序⚠️关键点FRR/BIRD只能检测BGP邻居、网络连通性感知不到DPVS数据面转发是否已经卡死。 极端故障现象 DPVS进程内部异常、DPDK转发卡死、长连接处理异常但是Linux内核、KNI网卡、FRR进程完全正常BGPBFD邻居UP路由还在向外宣告。 交换机ECMP继续把流量打过来这台DPVS已经无法转发数据包产生黑洞但是网络层面看不出故障。 FRR/BIRD无法感知DPDK用户态转发面故障必须外置Agent。外挂Agent必备核心功能IM亿级网关探测DPVS数据面真实可用性调用DPVS本地dpip工具查看DPVS进程存活、LIP池耗尽、RealServer状态本地模拟TCP探测本机VIPIM接入端口走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自定义选项获取真实客户端IPFull-NAT模式必备架构固有特性ECMP扩缩容会导致五元组哈希漂移存量TCP长连接断开IM业务必须实现客户端自动重连网络层无法规避彻底废弃传统KeepalivedVRRP主备模式高可用完全依赖BGP-ECMP自研健康Agent。到此我们大概清楚了单个机房如何设计拓扑如何使用DPVS做多活的负载均衡但是当用户的连接真正打到IM网关上后每个连接上的负载也不一样进而造成IM网关的负载不均衡我们下文再说未完待续