过去我们团队一直在香港部署API网关和静态CDN节点，目标是为中国大陆用户提供高速、稳定的访问通道。然而随着用户规模扩大、业务部署多云化，单一 ISP 和静态就近路由策略越来越难以满足低延迟、高可用和链路智能分流的需求。
为了解决跨境网络的“不可预期性”和“动态拥塞”问题，我决定引入 BGP Anycast 结合 多云调度系统，通过在多个香港节点上部署统一 IP 地址，并根据实时网络质量引导用户流量，从而提升整个链路的访问体验。以下是我落地这一方案的完整技术路径和实操过程。
一、部署背景与挑战分析
我们面临的典型问题：
- 同一 IP 在大陆不同地区访问延迟差异极大，尤其南北运营商之间的链路不可控；
- 香港单线出口易拥塞，电信用户走国际路由时 RTT 经常 250ms+；
- 业务已多云部署（AWS、阿里云、腾讯云、A5 香港机房），但未能智能分流，反而增加了不确定性；
- DNS 轮询调度不稳定，TTL 不统一、缓存污染严重，实测并不能按地区优化访问。
因此我们决定：
采用 Anycast+BGP智能路由 替代传统 DNS 调度，并配合 多云健康检查系统与跨运营商策略引导，真正做到“用户就近接入、网络拥堵可避、故障节点可剔”。
二、整体架构设计：Anycast IP + 多节点 BGP 公告 + 多云探测调度
核心技术栈：
| 组件 | 功能 |
|---|---|
| Anycast IP | 统一对外服务地址，多个边缘节点通过 BGP 广播 |
| BGP 会话 | 每个边缘节点对接至少两家 ISP，动态广播前缀 |
| Bird / FRR | 路由器级协议控制，结合 RPKI、BGP Blackhole 等策略 |
| Prometheus + Blackbox Exporter | 实时监控各入口的链路质量 |
| 多云调度控制器 | 自动探测各云厂商节点质量（RTT、丢包、抖动），进行优选发布 |
| Keepalived / ECMP / LVS | 本地节点上的高可用与内部流量分发 |
实际部署拓扑图（简化）：
+----------------+
| 用户请求（大陆）|
+--------+-------+
|
[运营商链路随机性]
|
+---------+----------+
| Anycast 公共 IP 段 |
+---------+----------+
|
+------------+-------------+
| 香港节点 A（阿里云） |
| 香港节点 B（A5IDC机房） |
| 香港节点 C（腾讯云） |
+--------------------------+
| |
多云健康探测 多路由BGP广播
| |
本地LVS+NAT FRR+Bird+ISP
三、实战部署步骤详解
步骤 1：统一 Anycast IP 并在各节点配置 BGP 广播
我使用了一个 /24 段落在 Cloudflare 上的 BGP ASN，并在香港多个节点通过 Bird + FRR 向接入的 ISP（NTT、CMI、HKBN、PCCW）广播这个 IP 段。
# Bird 配置片段
protocol bgp isp1 {
local as 65001;
neighbor 203.160.X.X as 4809; # CMI
multihop;
import all;
export where net = 203.160.100.0/24;
}
同时在服务器上绑定该 IP，结合 Keepalived 实现 VIP 接管：
ip addr add 203.160.100.1/32 dev eth0
步骤 2：Prometheus + Blackbox 构建链路实时监控
我自建了一套探测系统，在全国多个地区（北京电信、深圳联通、成都移动）部署探针，定时 ping 各香港节点 Anycast IP。
- module: icmp_anycast_probe
prober: icmp
timeout: 5s
targets:
- 203.160.100.1
通过实时分析 RTT、丢包率，我们可以直观看出哪个节点对哪些运营商表现最优。
步骤 3：编写调度控制器，动态启停 BGP 公告
我用 Python 写了一个简单控制器，定期抓取 Prometheus 指标：
if rtt["beijing_cmcc"] > 200 or loss > 3%:
withdraw_bgp("node-a")
else:
announce_bgp("node-a")
实测下来，移动用户晚上高峰期自动从 A5 节点切换到 AWS 香港，显著改善了访问稳定性。
步骤 4：本地 LVS / ECMP 配合内部流量多路径转发
由于每个节点上都有多个后端服务实例（如 API 网关、Nginx CDN），我用 LVS 结合 ECMP 实现本地高可用和负载均衡。
ip route add default nexthop via 10.0.0.2 nexthop via 10.0.0.3
四、优化效果实测与对比
实测数据（以广州用户为例）：
| 方案 | 平均 RTT | 丢包率 | 峰值跳变 |
|---|---|---|---|
| 传统 DNS 轮询 | 210ms | 5.1% | 高 |
| 单一香港节点 | 195ms | 3.8% | 中 |
| Anycast+BGP 智能调度 | 112ms | <1.0% | 低 |
甚至在广东移动用户中，访问性能一度优于深圳本地服务器（由于深圳出口拥堵）。
五、常见问题与排查技巧
大陆走国际出口概率无法控制？
可尝试优选接入 CMI、ChinaCache 等与大陆直连的网络，或与本地 CDN 厂商合作托管 Anycast。
BGP 广播误操作可能导致全网瘫痪？
- 强烈建议使用 RPKI 验证 + 前缀列表限制，避免误广播全网段。
多云节点 IP 重复有风险？
- 记得只对外广播 VIP，不要内网互 ping，否则可能触发连接异常。
六、从“被动访问”到“主动调度”的转变
在多云、多运营商环境日益复杂的今天，仅靠静态网络配置已无法保障大陆用户的访问体验。通过 BGP Anycast 结合链路监控和多云智能调度，我们实现了真正的“就近、最优、可控”访问路径。
这套方案在我们团队上线不到一周，就减少了 80% 的跨境投诉工单，也为下一步大陆边缘节点扩展（如深圳 BGP 中转）打下了基础。
