Anycast IP看似简单，真正落地时却很容易踩坑。当你在云上申请一个 Anycast 公网 IP，并把它挂在多地域的服务器（或者 Nginx、四层代理）上时，全球用户访问这个 IP，会被 BGP 自动导向离自己最近的那个节点——这就是 Anycast 最基本的能力。而 GSLB（全局负载均衡）在此基础上，进一步根据节点负载、健康状态甚至业务策略，动态调整 DNS 解析或 IP 路由，实现更精细的流量分配。
理想很丰满，现实却很骨感。BGP 路由天然会随着网络拓扑、链路质量、策略变化而“抖动”。一次路由抖动可能让几百毫秒内大批连接中断，对 GSLB 来说，这等于调度决策被频繁推翻，业务体验直线下降。本文就从小白的视角，拆解“路由防抖”到底在防什么，以及如何调优。
Anycast IP：一、从单点到 Anycast：GSLB 的进化逻辑
先看关键判断
传统的负载均衡是在一个数据中心内部做分发，用户访问一个公网 IP，流量先到 LB，再到后端。但业务一旦全球化，单点故障和跨洲延迟就成了难题。GSLB 的思路是把多个数据中心（或云区域）同时暴露给用户，通过 DNS 返回不同 IP，或者用 Anycast 让路由协议来做就近接入。
Anycast 的核心是“同一个 IP 在不同地点宣告”，BGP 根据 AS_PATH 长度、MED、Local Preference 等属性选择最优路径。用户不需要知道背后有多少个节点，路由器会自动选路。GSLB 可以叠加在 Anycast 之上：比如用 BGP 的团体属性或 AS_PATH prepend 来影响不同节点的优先度，从而实现权重分配或故障切换。
但 BGP 的环境是动态的。ISP 的链路故障、BGP session 震荡、路由策略误配置，都会导致路由表发生变化。一次变化就会引发节点 A 的路由被撤回，节点 B 的路由成为最优，用户连接被重新定向。这就是抖动——而且是全局性的。
二、路由抖动的真面目：BGP 为什么会“打嗝”
故障定位思路
路由抖动（Route Flapping）指 BGP 路由在短时间内频繁被宣告和撤回。原因通常有三类：
- 物理或链路层不稳定：光纤被挖断、光模块故障、交换机端口 flapping。这类问题会让 BGP 邻居不断 Up/Down，进而导致路由表变动。
- BGP 协议参数不当：比如 Hold Time 设置过小、Keeplive 间隔过短、或者没有开启 BFD（双向转发检测），导致网络微突发就误判为邻居失效。
- 路由策略冲突：两个节点同时宣告相同前缀，且各自的 AS_PATH 或 MED 值非常接近，导致路由器在它们之间来回切换——这叫“路由振荡”。
对 GSLB 来说，振荡的危害远大于单次故障：每换一次路径，现有 TCP 连接都会被拆掉（因为源目 IP 不变但出接口变了，五元组可能不匹配），用户就会看到瞬间断连、重连、甚至请求失败。如果抖动频率高，相当于每几秒就让全球用户断一次，体验堪比灾难。
延伸阅读：此处可内链到“Anycast IP配置案例”相关文章。
三、防抖三板斧：ECMP、BGP 属性调优、健康检查
1. 开启 ECMP，让流量有退路
ECMP（等价多路径）让路由器对同一个前缀保留多条等价路由，当其中一条失效时，流量自动切换到另一条，不需要重新收敛。虽然 Anycast 默认是选最优路径，但你可以通过调整 BGP 权重，让某个节点在某些链路上变成等价。比如在 AWS 或阿里云上，可以在 VPC 内添加多条从不同物理链路上来的对等连接，配合 ECMP 提高鲁棒性。
2. 调整 BGP 属性，制造“惰性”路由
BGP 的路由决策是有优先级的：Local Preference > AS_PATH > MED > 下一跳。为了让路由稳定，可以故意让备选节点的 AS_PATH 更长（增加 AS prepend），或者降低 Local Preference，这样路由器不会轻易在主备之间跳变。比如主节点设置 Local Preference 200，备节点 100，除非主节点完全不可达，否则不会切到备节点。这本质上是做“路由延迟切换”，给 BGP 更长的容忍时间。
3. 健康检查与 BFD 联动
GSLB 自身必须做健康检查，但不能完全依赖它来抑制抖动，因为健康检查的探测频率（比如 5 秒一次）远慢于 BGP 收敛速度（毫秒级）。更好的做法是 BFD（双向转发检测）与 BGP 联动，BFD 能在 10-50ms 内感知链路故障并通知 BGP，而不是等 Hold Time 超时。同时，在 GSLB 应用层做“防抖窗口”：设定一个健康状态切换的最小间隔（例如 30 秒内只允许切换一次），防止短暂的网络抖动导致大量 DNS 记录被刷新。
关联教程：此处可内链到“Anycast IP部署与验证”内容。
四、实战调优步骤（云上操作参考）
容易忽略的细节
- 确认 Anycast 的公网 IP 所属的云产品：例如阿里云的 Anycast EIP、AWS 的 Global Accelerator、华为云的 EIP with Anycast。不同云对 BGP 属性暴露程度不同，大部分只允许调整权重（Weight），不能直接操作 Local Preference。如果是自建 BGP，请直接修改 Quagga / FRR 配置。
- 配置主备权重：在云控制台为每个节点设置不同的权重值（例如 100 和 50），权重越高优先级越高。注意权重只在同区域内有意义，跨区域的 Anycast 由 BGP 自动选路，权重无法跨运营商生效。
- 开启 BFD：在云路由器的 BGP 配置中勾选“启用 BFD”，并设置探测间隔 100ms，连续丢包 3 次判定故障。这能将故障检测时间从 3 秒降到 300ms。
- GSLB 端设置健康检查灵敏度：将探测失败阈值提高到 3 次，成功阈值 2 次，并把切换冷却时间设为 60 秒。避免误告警触发大规模 DNS 更新。
- 开启路由 dampening（抑制）：如果云平台支持（如自建路由器），配置 BGP dampening，对频繁 flapping 的路由施加惩罚，使其在一段时间内不被采用，减少全局振荡。
补充参考：此处可内链到“Anycast IP故障排查实例”。
相关阅读：此处可内链到“Anycast IP常见问题”专题。
想继续深入：此处可内链到“Anycast IP优化清单”文章。
五、验证与持续调优与Anycast IP
我的处理经验
调整后如何确认防抖生效？最简单的方法是模拟手动 flapping：在其中一个节点上临时断开 BGP 会话（或 shutdown 端口），观察另一节点的流量切换速度以及有无丢包。使用 mtr 或 traceroute 对比切换前后的路径；同时监控 GSLB 的 DNS 解析结果变化次数。如果过去每分钟有 10 次解析变化，调整后降为 0，那就算成功了。
另外，千万要开启 BGP 日志，定期检查是否有大量 UPDATE 消息。如果发现某个前缀在半小时内 UPDATE 次数超过 20 次，说明抖动仍然严重，需要进一步分析对端 ISP 的配置。
最后，不要试图让路由“完全不抖动”，这不现实。目标是把抖动的影响从秒级降到百毫秒级，并且让 GSLB 不因微小的路由波动做出误切换。用好 ECMP、BGP 属性调优和健康检查窗口，你的全局负载均衡就能在波澜不惊中稳定运行。按这个顺序复查，Anycast IP遇到异常时也更容易定位。
延伸阅读