4. 网络层规划：专线互联、DNS智能解析（GeoDNS）、Anycast与BGP路由策略
网络层是多活架构的血管。数据能不能流到该去的地方，用户能不能连到最近的节点，全靠这一层。我参与过的几个多活项目，网络层面出问题往往最要命——专线断了、DNS解析不准、BGP路由黑洞，任何一个都会把整个系统拽倒。
这一节，咱们就把这三块核心内容掰开揉碎。专线互联是骨架，GeoDNS是入口调度，Anycast+BGP是最后一公里的路由保障。三者配合好了，用户才能无感切换。
4.1 专线互联：数据中心的“高速公路”
多活数据中心之间必须通过专线连接。为什么不用公网？公网延迟高、抖动大、带宽不可控，而且经过多家运营商容易出问题。我在一个金融项目中就遇到过：A中心到B中心用公网传输binlog，高峰期延迟飙升到200ms，导致同步严重滞后，最终被迫改成了专线。
4.1.1 专线类型选择
| 类型 | 带宽范围 | 延迟（同城） | 适用场景 |
|---|---|---|---|
| 物理裸光纤（L0/L1） | 100Gbps+ | <0.5ms | 同城双活，对延迟极度敏感 |
| OTN/WDM波分 | 10G~400G | <1ms | 同城/异地数据中心互联 |
| MSTP/MPLS VPN | 100M~10G | 1~5ms | 异地多活，成本敏感 |
| SD-WAN over 运营商 | 动态调整 | 5~20ms | 广域网备份链路，弹性伸缩 |
我个人习惯的做法是：主专线用波分或裸光纤，保障带宽和延迟；再拉一条SD-WAN或MPLS VPN做备份。千万别只靠一条线，我见过专线被施工挖断，整个业务全挂的案例。
4.1.2 二层互联还是三层互联
多活场景下，两台数据中心之间要不要做二层互联？我建议能不做就不做。二层广播域太大，ARP风暴、MAC表震荡、环路风险都很高。我早年一个项目非要做大二层，结果一次交换机升级触发广播风暴，整个数据中心宕了20分钟。
现在的主流做法是三层互联：每个数据中心作为一个独立自治域（AS），通过专线运行OSPF或BGP。同城延迟很低的情况下可以跑OSPF，异地最好用BGP，方便控制路由策略。
4.2 DNS智能解析（GeoDNS）：让用户找到最近的入口
用户访问你的域名，DNS返回哪个数据中心的IP？GeoDNS就是干这个的。它根据用户的源IP归属地（LDNS地址），返回离他最近的数据中心VIP。
实现方式主要有两种：
- 自建DNS：用BIND+GeoIP模块，或者PowerDNS配合Lua脚本。灵活，但需要自己维护权威DNS和容灾。
- 云服务商专用解析：比如阿里云DNS、Cloudflare，配置简单，自带高可用。一般推荐用这个，省事。
- 每个数据中心分配独立的地理区域（华北、华东、华南等）。
- TTL不要设太长，30~60秒即可。太长会导致故障切换后用户端缓存迟迟不更新。
- 设置兜底策略：如果用户IP无法识别归属，返回所有数据中心IP，让客户端随机选一个。
嗯，这里要特别提一下TTL。我曾经踩过一个坑：某项目把GeoDNS的TTL设成了600秒。一次华南机房故障，我们立刻修改解析切到华东，结果整整10分钟大部分用户还在访问故障IP。后来我把所有多活域名的TTL统一改成了30秒，切换时效性大大提高。
GeoDNS还有一个坑：很多企业把LDNS（运营商的递归DNS）的IP当作用户真实IP。但实际上LDNS可能离用户很远。比如一个上海用户用了北京的DNS服务器，GeoDNS可能把他调度到北京机房。要解决这个问题，可以用EDNS Client Subnet（ECS）扩展，让递归DNS把用户真实IP传给权威DNS。现在的云DNS厂商基本都支持。
4.3 Anycast与BGP路由策略：最后一公里的引流
GeoDNS把用户引导到一个数据中心，但用户到该数据中心的网络路径怎么走？Anycast+BGP就是答案。
4.3.1 Anycast原理
简单说：多个数据中心公布同一个IP地址（VIP），通过BGP向互联网宣告。用户发往这个IP的包，会根据BGP路由表自动走到“最近”的那个数据中心。注意，这个“最近”不是物理距离，是AS路径最短。
Anycast典型应用场景：
- DNS解析服务（根服务器、公共DNS）
- CDN边缘节点
- API网关入口（多活架构的流量入口层）
4.3.2 BGP路由策略调优
单纯依靠BGP的最短AS路径选路，往往不够精准。你可能需要：
- AS Path Prepending：在某个数据中心对外宣告时，人为增加AS路径长度，让流量尽量少走这个入口。比如北京数据中心承载能力是上海的2倍，可以给上海的路由加长AS路径，强制流量优先流向北京。
- MED（Multi-Exit Discriminator）：向同一个上游宣告多条路径时，用MED告诉上游“哪条更优”。MED值越小越优。
- Local Preference：与运营商协商，设置本地优先级。一般用在运营商内部，我们作为用户控制不了，但可以跟运营商提需求。
我记得有一个案例：某公司两个数据中心分别在上海和广州，用户集中在华南。默认BGP选路下，上海机房也走了大量流量，导致跨专线回源。后来我们在上海端做了AS Path Prepending，加了三次AS号码，流量立刻平衡了。效果立竿见影。
4.3.3 多活架构下的网络层整合
下面这张图展示了我比较推荐的多活网络层架构：
这张图里，GeoDNS负责地域调度，Anycast负责就近路由，专线负责数据中心内部同步。三者配合，任何一层出问题都有兜底策略。
4.4 综合策略与避坑清单
最后列几个我亲身踩过的坑，供大家参考：
- 专线不要在公网跑关键业务流量，必须走物理隔离链路。
- GeoDNS的TTL建议不高于60秒，宁可增加解析压力也要保证切换速度。
- Anycast的BGP宣告要配置route-map，限制只向指定运营商宣告，避免路由泄漏。
- 每个数据中心至少配置两个不同的BGP上游运营商，防止单运营商故障。
- 定期做“断网演习”：拔掉专线、关掉某数据中心的BGP宣告，验证切换是否平滑。
网络层的规划是个细致活。粗看就是几条专线、一个DNS、一堆BGP配置，但里面的坑多到你数不过来。我建议多读几遍BGP选路规则，多看看运营商的路由拓扑。记住一句话：网络层规划的好坏，直接决定了多活架构的天花板。