HyperRouter: 从四层负载均衡设计与开发，看确定性运维实践

一、确定性运维与 HyperRouter 的定位

在华为云的运维实践中，SRE（站点可靠性工程）团队以云服务全生命周期为核心，构建了贯穿始终的质量看护机制，最终实现现网服务高可用的可预期性。这种经过实践验证的运维理念与系统化的质量管理体系，被定义为 “确定性运维”。

区别于传统运维"依赖经验、事后补救"的模式，确定性运维通过覆盖全流程的质量管理体系，将抽象的可靠性目标转化为可量化、可保障的具体指标——在现网环境中，确定性运维精准实现确定性故障率、确定性恢复时长与确定性影响范围，为云服务的稳定运行提供坚实且明确的保障。

华为云全局负载均衡服务是确定性运维的重要组成部分，华为云通过全局负载均衡实现高效跨局点容灾、服务无损升级、爆炸半径可控等关键确定性运维能力。华为云全局负载均衡由多个服务组成，包括基于 DNS 的全局负载均衡、四层负载均衡、七层负载均衡、Service mesh 以及全局负载均衡管控面。

本文旨在分享华为云全局负载均衡的重要组成部分 HyperRouter 在设计、开发、运维过程中的确定性运维实践。

二、HyperRouter 设计与开发的六大核心实践

(一) Lesson 1: 通过跨服务的协同设计可以简化系统复杂性，提升整体系统可靠性

1. 四层与七层负载均衡协同设计

四层与七层负载均衡常以组合形式部署，七层负载均衡单独工作的场景较少。核心原因在于：应用层（七层）的有状态特性使其对单节点故障容错能力弱，如 ECMP 的简单哈希机制易导致大量 TCP 连接中断。因此，四层负载均衡的关键作用之一，便是在节点故障、扩缩容等场景下，提升七层负载均衡的可靠性。

设计四层负载均衡前，需先明确其在全局负载均衡平台中的定位，以及如何与上下游高效协同，从而简化四层架构；同时，需推动四层负载均衡尽快实现无状态化，以获得最优横向扩展能力。基于此，HyperRouter 在设计上主要实现了 Google Maglev 一致性负载均衡算法，并仅支持 Direct Server Return（DSR）模式。

Maglev 一致性负载均衡算法相比其他负载均衡算法的最大优势是最小化后端节点故障导致的 TCP 流中断；其次是让 HyperRouter 的每个数据面节点在无需任何状态同步的前提下，均能将同一 TCP 流的报文转发至同一个后端七层节点。为了进一步提升 TCP 流可靠性，HyperRouter 通过 Connection Tracking Table (CTT) 机制实现同一个 TCP 流的报文总是转发到同一个后端健康节点，但 CTT 并非强依赖的有状态模块。

Direct Server Return（DSR）模式的价值，在于让四层负载均衡仅专注于入向（ingress）流量转发，无需处理出向（egress）流量——这不仅能进一步提升四层负载均衡的横向扩展能力，还能显著降低资源开销。以简单的 HTTP GET 请求为例：一个 GET / HTTP/1.1 请求通常仅几十字节，单个 TCP 报文即可承载；但其响应数据量差异极大，小到几十字节，大到 KB、MB 甚至 GB 级。若四层负载均衡处理这类响应，会无谓消耗 CPU 与内存资源。通过 DSR 模式，七层负载均衡可直接将响应返回客户端，从而最大程度减少四层负载均衡的性能损耗（Overhead）。

四层和七层负载均衡协同设计的实践可以应用于其他相关的服务，即通过跨服务的协同设计可以简化系统复杂性，提升整体系统可靠性。

2. HyperRouter 设计目标

明确 HyperRouter 在全局负载均衡中的定位后，我们来聚焦其设计目标。和多数分布式系统一致，四层负载均衡服务的设计需围绕四个"简约却不简单"的核心目标展开：高性能、高可扩展、高可靠、可演进。

1. 高性能：对四层负载均衡而言，高性能不仅要求以最少资源实现接近线路速率（line-rate）的处理能力，还需极致发挥 CPU、网卡等硬件资源潜力——例如单 CPU 核需支撑千万级每秒数据包（PPS）处理量；同时，为避免对上层业务时延产生影响，每个报文的处理速度必须达到纳秒级。
2. 高可扩展：随着华为云服务数量与业务规模高速增长（如并发 TCP 连接从千万级攀升至十亿级），四层负载均衡服务必须具备极强的横向扩展能力，以适配业务体量的快速变化。
3. 高可靠：无论是内部还是外部客户，均期望负载均衡提供近乎零中断的服务。因此，四层负载均衡需在各类场景下保障高可用与高可靠，包括日常软件升级、配置变更，以及硬件故障、网络故障等异常情况。
4. 可演进：新场景、新需求、新硬件、新协议的出现，要求负载均衡系统能以最低成本、最高效率实现无断代的持续迭代，确保长期适配业务发展。

3. 四层负载均架构设计

HyperRouter 主要由两部分组成：数据面和管理面。

HyperRouter 的架构可明确划分为数据面与管控面：

• 数据面功能相对简洁，核心聚焦网络报文的接收、处理与转发，但对性能（如转发速率）和可靠性的要求极高
• 管控面则承担更复杂的管理职能，涵盖数据面集群调度、配置下发、BGP 路由发布、全链路可观测、健康探测及自愈能力建设，对性能要求相对较低

（本次分享重点并非 HyperRouter 的架构细节，因此不对各模块展开深入探讨）

(二) Lesson 2: 用户态内核旁路提供了最大灵活性和性能，但会牺牲硬件复用与能效；工程实践中的选择取决于性能与资源利用之间的权衡

用户态高性能数据面

Linux 内核网络栈功能完备，但在⾼性能场景下表现出局限性。其上下文切换、内存拷贝等通⽤机制导致延迟增加，在千万级 PPS 规模下成为性能瓶颈。

为突破性能瓶颈，需尽可能绕开 Linux 协议栈，Linux 原生的"kernel-bypass"技术 XDP（eXpress Data Path）是可行方案之一。它通过在 Linux 网络入口处运行 eBPF 程序处理原始报文，能实现高性能、低 CPU 开销的报文处理与转发。

但 XDP 存在明显局限：

1. eBPF 程序的编程模型有约束，无法像通用程序那样灵活实现各类逻辑
2. XDP 要求每个网卡运行一个实例，而华为云数据面需至少支持双网卡，以适配双 ToR 交换机的流量处理需求，这与 XDP 的特性存在适配矛盾
   

另⼀个方案就是 DPDK（Data Plane Development Kit）。DPDK 提供了在用户态直接接管网卡的能力，实现接近线速的转发性能，但代价是需要专用 CPU 与 NIC，并且其关键的 Poll model 让 CPU 利⽤率始终保持 100%。

通常数据面的技术选型是一个"单向门决策"（One-way door decision）——一旦确定，切换方案的成本极高，因此需要尤为慎重。对我们而言，灵活性、可演进性与高性能等高优先级目标是我们最终选择 DPDK 的主要原因。

(三) Lesson 3: 自愈及隔离能力应该是系统设计的基本设计原则之⼀而不是作为次要特性，以充分利用系统特征实现高效、可靠的自愈及隔离机制

自愈及隔离作为基本设计原则

在分布式系统中，节点失效、硬件故障和⽹络分区等是必然事件。为此，HyperRouter 从设计阶段就将⾃愈与隔离作为"⼀等公民"（First-class principle）。

首先是数据面节点的自我健康检查机制：Controller 会持续拉取节点的核心数据（包括数据面状态与指标、BGP speaker 状态、后端健康检查结果等），综合判断节点健康度。一旦检测到异常，会立即触发恢复或隔离动作，例如进程重启、配置动态调整，或直接将节点隔离。

以"转发错误（forwarding error）过高"场景为例：HyperRouter 不会采用撤销 BGP 路由的方式转移流量，而是通过调整 BGP AS Path（如追加或减少同一 ASN）来改变路由权重，快速将流量导向健康节点，避免故障影响扩散。选择这一方案的核心考量是：自我探测可能因各类干扰出现误判（false positive），若直接撤销路由，可能导致报文无法正常转发，反而引发新问题。

尽管这套自愈与隔离机制并非适用于所有类型的应用，但"将自愈及隔离能力纳入设计"应作为系统设计的核心原则之一，而非事后补充的补丁方案。唯有在设计阶段就充分结合系统自身特征进行规划，才能构建出更高效、更可靠的自愈与隔离机制。

(四) Lesson 4: 点对点存储通信架构非常适于需要极高 A、P（CAP 理论中的 Availability 及 Partition Tolerance）及最小化外部依赖的系统

1. 基于点对点架构实现系统依赖最小化

根据 CAP 理论，我们最多能三选⼆，对于 HyperRouter 的管控⾯，我们更关注其可⽤性和⽹络分区容错性。其次我们需要尽可能减少对外部服务的依赖和⽽外组件，以减少故障点。

因此，HyperRouter 采用了点对点去中心化架构：各节点可独立完成状态发现与同步，即便部分区域发生网络分区，整个系统仍能维持核心功能正常运行。为此，我们从零构建了一套专为全局负载均衡设计的点对点框架，该框架由存储层、KV 语义层、通信层及应用层组成。这种架构的核心价值在于，即便出现网络分区，各"孤岛"节点仍能最大限度自主做出正确决策，从根本上避免了因依赖中心化组件而可能引发的级联故障。

2. 形式化验证

为确保点对点系统的正确性，我们联合爱尔兰云可靠性实验室的形式化方法团队，采用 P 语言与 TLA+ 工具对管控面协议进行了严格验证。

借助形式化验证，我们成功定位了一处隐藏的潜在问题：在特定边界条件下，节点可能陷入无限重试循环，导致状态同步始终无法完成。这类深层问题在传统测试中极难被发现，而形式化验证让我们得以在系统上线前就将其识别并彻底修复。

(五) Lesson 5: Cell 架构和 Shuffle sharding 可以有效降低⼤规模多租系统的爆炸半径

确定性爆炸半径

在多租户系统中，单个租户的异常若未加管控，可能扩散至整个系统并引发严重故障。为解决这一问题，HyperRouter 借鉴了 Cell 架构与 Shuffle Sharding 技术。关于这两种技术的细节，我们曾在去年的 SRECon 会议上，结合华为云爆炸半径控制的方法与实践做过深入分享，本文仅聚焦其在四层负载均衡服务中的具体实现展开介绍。

作为负载均衡服务，HyperRouter 无法依赖"Cell Router"实现 Cell 化，因此需由管控面直接负责 Cell 与虚拟分区的分配和管理。具体而言，通过将租户划分为多个 Cell 与虚拟分片，可将故障严格限制在较小范围内；而 Shuffle Sharding 的分片重叠设计，能进一步降低租户间的耦合概率，从而显著缩小故障爆炸半径。

举例：假设共有 10 个 Cell（N=10），若采用静态分区且每个分区包含 2 个 Cell，其爆炸半径为 1/5；但通过 Shuffle Sharding 机制，为每个逻辑负载均衡（LB）分配独立虚拟分区，即便该虚拟分区对应的 Cell 完全故障，其爆炸半径也仅为 1/C(10,2) = 1/45（其中 C 代表组合数），故障影响范围大幅缩减。这种设计可有效提升了多租⼾环境下的隔离能力，是确保确定性运维的关键环节。

(六) Lesson 6: CUJ 是⼀个行之有效的以用户为中心的可观测框架和实践

CUJ: 以用户为中心的可观测

在 SRE 的方法与实践中，可观测性是保障系统稳定的关键环节。但面对复杂系统中动辄成千上万的指标、日志与事件，如何精准切入、聚焦核心信号，进而设计合理的 SLO（服务等级目标）与告警策略，成为亟待解决的问题。

传统可观测性方案多从系统自身维度（如 CPU 使用率、网络丢包率）出发，难以全面反映用户实际体验。为此，HyperRouter 引入了"关键用户旅程（Critical User Journeys, CUJ）"方法论，以用户为核心重构可观测性体系。

CUJ 由 Google 率先提出，目前已在业界广泛应用（例如 Netflix 便将其用于游戏服务的可观测性设计）。以 HyperRouter 管控面"配置下发"的 CUJ 为例，我们可清晰看到其应用逻辑：用户"新建一个负载均衡（LB）"的操作，会涉及 API 调用、管控面处理、BGP 路由下发、数据面接入四个核心环节。通过对这一全链路的追踪与度量，我们不仅能直观评估用户感知的性能（如新建 LB 的耗时），还能发现传统监控未覆盖的盲区——例如 DPDK 内部交互延迟这类直接影响用户体验却易被忽略的问题。

CUJ 提供了⼀种⾯向⽤⼾的可观测⽅法，使指标、SLO、监控等设计更贴近⽤⼾的实际体验。

三、HyperRouter 实践核心经验总结

HyperRouter 作为华为云全局负载均衡的关键组件，其设计、开发与运维过程，为云原生领域分布式系统的"确定性运维"落地沉淀了可复用的核心经验，具体可归纳为六大维度：

1. 跨服务协同是简化复杂度的核心能力

四层与七层负载均衡的组合部署是常见场景，通过明确 HyperRouter 的定位（聚焦入向流量转发），结合 Google Maglev 一致性算法（实现无状态精准转发）与 DSR 模式（剥离出向流量处理），可实现跨服务无状态联动——既解决七层有状态服务的容错短板与 ECMP 重哈希断连问题，又降低四层负载均衡的资源开销，为系统整体可靠性奠定基础。

2. 技术选型需理性权衡"单向门决策"

数据面框架的选择直接决定性能上限，Linux 内核网络栈存在高性能瓶颈，XDP 虽低耗但灵活性与双网卡适配性不足；而 DPDK 虽需专用 CPU/NIC 且 CPU 利用率高，却能满足"单核千万级 PPS、纳秒级报文处理"的高性能需求，且适配可演进目标。这种"性能 - 资源 - 灵活性"的权衡逻辑，可迁移至其他对性能与可扩展性有高要求的组件选型场景。

3. 自愈与隔离必须前置为设计"一等公民"

分布式系统中故障不可避免，需从设计阶段将自愈与隔离能力纳入核心逻辑：通过 Controller 持续拉取节点状态（数据面指标、BGP 状态等）实现健康度动态判断，用"BGP AS Path 调整"替代"路由撤销"处理故障（避免误判导致的转发中断），既能快速转移流量，又能降低故障扩散风险。这种"主动探测 - 精准决策 - 最小化影响"的机制，比事后补丁式方案更高效可靠。

4. 点对点架构适配高可用与分区容错需求

基于 CAP 理论，HyperRouter 管控面优先保障可用性（A）与分区容错性（P），采用点对点去中心化架构（含存储层、KV 语义层、通信层），使节点可独立完成状态发现与同步——即便出现网络分区，"孤岛"节点仍能自主决策，避免中心化组件依赖引发的级联故障；搭配 P 语言与 TLA+ 形式化验证，可提前规避状态同步无限重试等深层隐性问题。

5. Cell+Shuffle Sharding 实现确定性爆炸半径

多租户系统需严格控制故障影响范围，HyperRouter 通过管控面直接分配 Cell 与虚拟分片，结合 Shuffle Sharding 的动态分片设计，将故障爆炸半径从静态分区的 1/5（10 个 Cell、单分区 2 个 Cell）压缩至 1/45（组合数计算），有效隔离单租户异常，为多租场景下的"确定性影响范围"提供技术支撑。

6. CUJ 重构可观测性以对齐用户体验

传统系统维度监控（如 CPU、丢包率）无法精准反映用户感知，通过 CUJ 方法论（如"新建负载均衡"全链路：API 调用→管控面处理→BGP 下发→数据面接入），可将监控指标与用户核心操作绑定，既能直观度量用户体验（如新建 LB 耗时），又能发现 DPDK 内部交互延迟等传统监控盲区，让可观测性真正服务于用户体验保障。

四、总结

本文以 HyperRouter 为实践载体，阐述了"确定性运维"理念从抽象目标到具象落地的全流程。这一实践充分证明，系统可靠性的核心并非单纯依赖冗余配置或防御性设计，而是源于结构清晰的架构规划、理性严谨的技术权衡，以及可度量的闭环反馈机制。

展望未来，随着云基础设施向更高带宽、更新协议、更智能硬件演进，HyperRouter 将持续优化性能、适配新场景，进一步拓展确定性运维的应用边界，为云服务全生命周期的稳定运行提供更坚实的技术支撑，也为行业可靠性实践提供更多可参考的落地范式。