跨地域流量调度实战：多活、就近访问、故障自动切换

去年一个客户，业务出海，用户遍布欧美东南亚。他们在北京和弗吉尼亚各部署了一套环境。弗吉尼亚的用户访问弗吉尼亚，很快；欧洲用户访问弗吉尼亚，跨大西洋，延迟150ms；东南亚用户访问北京，也远。用户投诉“太慢”。

他们想了个方案：DNS智能解析，欧洲用户解析到弗吉尼亚，东南亚解析到北京，北美解析到弗吉尼亚。听起来合理，但欧洲用户访问弗吉尼亚，延迟还是高。

我问：“欧洲为什么不在欧洲部署一套？”

“数据同步太麻烦，而且用户不多，再部署一套不划算。”

“那至少在欧洲加个CDN吧？”

“加了，动态接口还是慢。”

这是跨地域流量调度最常见的困境：用户分散，想就近访问，但数据同步、成本、架构复杂度都是拦路虎。

今天聊聊跨地域流量调度。不是那种“智能DNS很重要”的入门课，而是帮你理清楚：多活、主备、就近访问怎么设计？数据怎么同步？用户跨地域访问怎么加速？

01 三种跨地域架构模式

模式一：主备模式

主地域承担全部流量，备地域只部署实例不接流量，或只接小部分。主地域故障时，DNS或GTM切流量到备地域。

• 优点：架构简单，数据同步要求低

• 缺点：备地域资源利用率低；切换有延迟（DNS缓存、数据同步滞后）

模式二：双活模式

两个地域都接流量，各承担一部分。数据双向同步或主从同步。

• 优点：资源利用率高，切换速度快

• 缺点：数据同步复杂，冲突处理难；跨地域调用延迟增加

模式三：多活模式

三个及以上地域同时服务。数据分片或最终一致性。

• 优点：扩展性好，单地域故障影响面小

• 缺点：架构复杂度极高，数据一致性挑战大

那家客户从主备开始，北京主，弗吉尼亚备。欧洲用户访问弗吉尼亚，延迟高；东南亚用户访问北京，也高。后来改成双活：北美、欧洲用户访问弗吉尼亚；亚太用户访问北京。但数据双向同步，经常冲突。

02 就近访问：不只是DNS智能解析

很多人以为就近访问就是DNS智能解析——用户来自哪里，就解析到哪个地域的IP。但这只能解决入口问题，不能解决后端数据同步延迟。

真正的就近访问需要考虑：

• 静态内容：CDN缓存，边缘节点就近返回。简单。

• 动态请求：需要回源计算，数据在哪，请求就得去哪。如果用户在北京，数据主库在弗吉尼亚，请求还是得跨地域。

解决方案：

• 数据分片：按用户ID分地域。中国用户数据在北京，欧美用户数据在弗吉尼亚。用户访问时，DNS解析到数据所在地域。

• 全局数据库：使用Aurora Global Database、Spanner等支持跨地域读的数据库。写主库，读本地副本。

那家客户最终采用了数据分片：中国及亚太用户数据在北京，欧美用户数据在弗吉尼亚。DNS智能解析结合分片规则，用户请求落到自己数据所在区域。跨地域读写大幅减少。

03 故障自动切换：DNS还是GTM？

跨地域故障时，要把流量从故障地域切到健康地域。

DNS切换：改DNS记录，指向健康地域IP。缺点：DNS缓存生效慢（TTL通常60-300秒），切换期间部分用户仍访问故障地域。

GTM切换：全局流量管理（如AWS Global Accelerator、Azure Traffic Manager、阿里云GTM）。实时健康检查，自动切流，客户端无感知。

那家客户用DNS切流，TTL设60秒。故障时，最快也要1分钟才切完。后来改用GTM，健康检查间隔30秒，3次失败即切，总切换时间<2分钟，且客户端无感知。

04 数据同步：跨地域架构的命门

跨地域流量调度，最难的不是流量，是数据。

同步方案对比：

那家客户的数据分片方案，避免了双向同步的冲突问题。写操作都在数据归属地域，其他地域只读本地副本或通过API跨地域读（低频场景）。

05 跨地域调用的坑

即使做了数据分片，仍然有跨地域调用的场景：比如中国用户访问了某个欧美用户的公开资料。

问题：跨地域调用延迟高（北京到弗吉尼亚约150-200ms），用户体验差。

解法一：异步化。不要求实时返回的，走消息队列异步处理。

解法二：缓存。非敏感数据，在各地域缓存副本，定时同步。

解法三：接受延迟。低频场景，200ms延迟用户可接受。

那家客户把“查看他人公开资料”做了缓存，24小时过期。绝大多数请求不跨地域，只有首次查询或缓存失效时才跨地域。

06 一个真实案例：从全球慢到分片加速

一个SaaS客户，全球用户。最初主库在美国，各地用户直接读写，欧洲用户延迟150ms，澳洲200ms。

改造方案：

• 数据分片：按用户注册地域归属。美国用户数据在美国，欧洲在欧洲，澳洲在澳洲。

• DNS智能解析：用户就近访问归属地域入口。

• 全局读副本：各地域部署从库，跨地域读走本地副本。

• 跨地域写：低频场景，应用层接受延迟。

改造后，P99延迟从150ms降到50ms以内。运维负责人说：“以前用户投诉慢，我们只能加带宽。现在慢不是因为带宽，是因为数据太远。”

写在最后

跨地域流量调度，核心不是流量，是数据。数据在哪，流量就得去哪。

那家客户的架构师后来总结了一句口诀：“静态内容CDN扛，动态流量分片管；双活慎用防冲突，主备简单先上路；数据同步是命门，GTM切流比DNS快。”

用户在哪，数据就在哪。数据在哪，服务器就在哪。这套逻辑想通，跨地域架构就通了一半。