多数据中心流量调度：DNS、路由切换与七层负载均衡的协同之道

注：本文在大模型辅助下完成。

1. 需求场景

目前互联网的服务普遍部署在数据中心（Data Center）内。数据中心是一个复杂的系统，涉及供电、制冷、网络、供水等一系列环节。由于设备故障、供电中断、网络割接甚至自然灾害等因素，数据中心随时可能出现故障。

从服务高可用的角度，一般需要将服务部署在多个数据中心内，以便在单个数据中心故障时，仍然保证服务的持续提供。

在多数据中心场景下，核心问题是如何将用户流量在多个数据中心之间进行调度。如下图所示，有2个数据中心，每个数据中心内都部署了相同的服务（服务集群1和服务集群2），各有一个网络接入点。我们需要解决的是：用户流量应该通过什么机制，在这多个数据中心之间做调度？

图1多数据中心场景下的流量调度

2. 三种调度手段：概述与适用场景

在多数据中心流量调度中，业界通常有三种手段可供选择：DNS调度、路由切换和基于七层负载均衡的调度。这三种手段作用于网络的不同层次，各有其适用场景和局限性。

核心原则：没有一种手段是万能的，多数据中心流量调度需要分层协同，各司其职。

3. 基于DNS的调度方案：兜底手段

3.1 方案说明

DNS调度是目前最普遍的跨数据中心流量调度方案。每个数据中心的接入点分配不同的VIP（如1.1.1.1和2.2.2.2）。客户端通过智能DNS将域名解析为IP地址，智能DNS根据客户端IP地址和预设策略返回对应的接入点IP。

图2基于智能DNS的调度方案

智能DNS根据源IP地址确定解析的结果

当某个数据中心发生故障（接入点故障，或服务集群故障）时，可以通过修改DNS解析策略，将流量切换到其他数据中心。

图3基于智能DNS实现故障切换

智能DNS将流量从数据中心1切换到数据中心2

3.2 方案的问题

DNS方案存在两个明显缺陷：

(1) 生效速度慢DNS采用缓存机制，客户端和Local DNS都会缓存解析结果。即使TTL设置为5分钟，最终生效延迟往往达到8-10分钟。部分Local DNS不遵循TTL，甚至长期不更新，导致部分用户长时间无法完成切换。

(2) 调度精度低权威DNS无法判断每个Local DNS所代表的用户规模，难以实现精确的流量比例控制。

图4权威DNS难以判断Local DNS代表的用户规模

3.3 重新定位：DNS是兜底手段

鉴于上述问题，DNS更适合作为兜底手段，而非日常精细调度的首选工具。在以下场景下，DNS可以发挥最后防线的作用：

• 七层负载均衡系统本身故障

  当BFE等七层负载均衡集群整体不可用时，通过DNS将流量切到其他数据中心。

• 单机房整体故障且路由切换失效

  在路由层面无法完成切换的极端情况下，DNS提供最后的容灾能力。

• 跨地域调度

  对于地理跨度较大的数据中心（如北京与上海），在没有充足内网互联时，DNS仍是必要的流量引导手段。

4. 基于路由切换的调度方案：机房级故障的首选

4.1 方案说明

路由切换是在网络层实现的流量调度，常见方式包括BGP Anycast和静态路由切换。

以BGP Anycast为例：同一个IP地址（如1.1.1.1）同时在多个数据中心的接入点宣告。正常情况下，用户流量根据BGP路由策略进入最近的数据中心。当某个数据中心发生故障时，停止该节点的BGP宣告，流量会自动通过路由收敛切换到其他存活节点。

图5基于路由切换的调度方案

静态路由切换则是通过在网络设备上调整路由优先级或下一跳，将流量引导至其他数据中心。

4.2 为什么路由切换更适合单机房故障？

在单机房故障场景下，如果需要对大量域名进行流量调度，高频修改DNS记录会带来严重问题：

• DNS服务器压力剧增

  每个域名的解析策略变更都需要在权威DNS上修改，域名数量越大，操作复杂度和服务器负载越高。

• 缓存不一致风险

  大量域名同时变更，不同Local DNS的缓存刷新节奏不一致，可能导致流量调度出现混乱。

• 生效时间不可控

  部分用户可能长时间停留在旧解析结果上，故障恢复时间难以保证。

相比之下，路由切换一次操作即可影响所有经过该IP（或IP地址段）的流量，与域名数量无关，生效速度取决于BGP收敛时间（通常在秒级到分钟级），更适合大规模、机房级的故障切换。

4.3 适用场景与局限

适用场景：

• 单机房整体故障（如供电中断、网络接入层故障）

• 接入点故障（VIP不可达）

• 需要快速、批量切换大量业务的场景

局限性：

• 调度粒度较粗，只能做到IP/前缀级别

• 无法感知应用层状态（如服务是否真正可用）

• 需要网络层支持（如BGP宣告权限、运营商配合）

5. 基于七层负载均衡的调度方案：服务级精细调度

5.1 方案说明

在数据中心内部署七层负载均衡系统（如BFE），可以实现跨数据中心的精细流量调度。

图6引入七层负载均衡系统后的调度方案

各数据中心内部署BFE集群，BFE按照指定权重（W11, W12, W21, W22），将流量转发至多个后端集群（包括其他数据中心的服务）。这要求多个数据中心之间有较好的内网互联，在同城数据中心之间，网络延迟通常可控制在1-2ms内，对整体转发延迟影响不大。

5.2 为什么七层负载均衡更适合服务级调度？

与DNS和路由切换相比，七层负载均衡在以下场景具有不可替代的优势：

(1) 服务级故障的快速响应当某个数据中心内的部分服务出现故障（而非整个机房），通过调整BFE的分流权重，可以仅将故障服务的流量调度到其他数据中心，而不影响该数据中心内其他正常服务。DNS和路由切换都无法做到这一点——它们只能将整个域名或IP的流量全部切走。

(2) 服务级的多机房流量均衡七层负载均衡可以精确控制每个服务在多机房之间的流量分配比例。例如：

• 服务A按 70% : 30% 分配在数据中心1和2

• 服务B按 50% : 50% 分配在数据中心1和2

这种服务级的差异化调度，DNS和路由切换均无法实现。

(3) 生效速度快、控制精度高BFE的权重配置加载后立即生效（秒级），且流量分配严格按给定权重执行，为容量管理和过载保护提供了精确手段。

5.3 适用场景

• 服务级故障

  单个服务异常，需要快速止损

• 外网流量突增

  流量突增，单机房容量不足

• 灰度发布与容量调配

  精细控制多机房流量比例

• 外网故障后的负载再平衡

  DNS或路由切换导致某机房流量突增，通过BFE反向调度

6. 分层协同：多数据中心调度的最佳实践

在实际生产环境中，三种手段应当分层协同，互为补充，而非相互替代：

协同工作示例

场景：数据中心1发生单机房故障

• 路由切换优先

  停止数据中心1的BGP宣告，用户流量在分钟级内收敛到数据中心2。

• 七层负载均衡跟进

  BFE自动或手动调整权重，确保数据中心2内的服务能够承载新增流量，必要时将部分流量回切到数据中心1的健康服务（如果部分服务仍可用）。

• DNS兜底

  如果路由切换未能完全生效，或需要长期引导流量，通过DNS将域名解析到数据中心2的接入点。

场景：数据中心1内服务A故障，其他服务正常

• 七层负载均衡处理

  BFE将服务A的流量调度到数据中心2，数据中心1内的其他服务不受影响。

• 无需动用DNS和路由切换

  避免"一刀切"导致不必要的跨机房流量。

7. 应用场景详解

场景1：服务故障（服务级）

数据中心1内的服务集群1因灰度发布出现问题，容量下降。通过调整BFE的分流权重，将数据中心1的流量调度到数据中心2的服务集群2，实现精准止损。

图7服务故障场景下的处理（七层负载均衡）

服务集群1（故障）→ BFE集群1将流量调度至 → 服务集群2

场景2：外网流量突增（服务级）

某地区用户流量突增，导致单个数据中心压力超过容量。通过BFE将部分流量调度到其他数据中心，实现负载分担。

图8外网流量突增场景下的处理（七层负载均衡）

流量突增→ 服务集群1（过载）→ BFE集群1将部分流量调度至 → 服务集群2

场景3：单机房整体故障（机房级）

数据中心1因供电故障整体不可用。通过路由切换（BGP Anycast）快速将流量收敛到数据中心2，无需逐条修改DNS记录。

场景4：外网故障后的再平衡（协同）

外网故障，DNS或路由切换将流量从数据中心1调度到数据中心 2，数据中心2压力突增。此时通过BFE将部分流量反向调度到数据中心1的服务，实现跨机房负载再平衡。

图9外网故障场景下的处理（七层负载均衡与DNS/路由协同）

外网故障→ 数据中心1接入点（不可用）→ 流量经DNS/路由切换至数据中心2

服务集群2（压力突增）→ BFE集群2将部分流量回切至 → 服务集群1

8. 总结

多数据中心流量调度不是"二选一"的问题，而是"什么时候用哪种手段"的问题。

• 七层负载均衡（BFE）

  是日常调度的核心工具，适合服务级故障、精细流量均衡和灰度发布，生效快、控制准。

• 路由切换

  是应对机房级故障的利器，特别适合域名数量大、需要批量快速切换的场景，避免了高频DNS调度的压力。

• DNS

  则作为兜底手段，在七层负载和路由切换均无法生效时提供最后的容灾保障，也是跨地域无内网互联场景的必要选择。

三种手段分层协同，才能构建真正高可用、易运维的多数据中心流量调度体系。

作者简介

章淼，博士，1994年进入清华大学计算机科学与技术系学习，2004年获得博士学位，2004年至2006年在清华大学留校任教，在清华期间曾参与中国第一代核心路由器的研制工作。2012年起在百度工作超过十年，聚焦云网络基础架构的研发工作，是BFE开源项目的发起人。在百度期间积极推动软件工程能力提升，曾担任百度代码规范委员会主席，2021年10月被授予百度代码规范委员会荣誉主席。2022年出版《代码的艺术：用工程思维驱动软件开发》。2023年4月起担任瑛菲网络CEO，聚焦研发面向云和大模型场景的现代化流量管理平台。