一、项目背景

某客户的推理实例分散在多个区域，调用方本该就近访问最快，可默认路由不认区域，华南的请求经常绕到华北，延迟翻倍不说，跨区域带宽还贵。我们进场时，跨区流量占比高得离谱，账单里带宽费比算力费还扎眼，用户体验也因为绕路时好时坏。更糟的是故障放大，一旦华北实例抖动，华南的请求跨区涌过去把华北压得更死，一次小故障演变成区域级雪崩，运维那段时间天天被带宽和延迟的双重报警轰炸。

二、落地场景

我们在网关做了调用方区域亲和，识别调用来源区域后优先路由到同区域实例，同区满了或挂了才跨区兜底。跨区故障切换走健康检查，主区异常秒切备用，用户几乎无感。另配了区域流量调度看板，跨区占比、各区域延迟、带宽成本一目了然，运维能主动调。我们还按区域做了容量规划，高峰前把算力预扩到对应区域，避免临时跨区救火。业务侧最直观的反馈是南方用户打开快了，投诉里"时快时慢"的描述基本消失。

我们把区域容量和实时负载也接进看板，哪个区域快满了一目了然，运维可以提前把流量引导到有余量的区域，而不是等跨区告警才动。区域间还做了预热同步，冷区域偶尔来一波请求不至于被当异常，避免不必要的跨区切换，稳定性又上了一个台阶。容量规划也从月度拍脑袋改成看板驱动，哪里要扩、扩多少都有数据支撑，资源浪费明显少。

区域亲和这个项目让我们重新理解了就近两个字。最早我们只做同区优先，结果低延迟实例被一窝蜂打爆，延迟没降反升，后来加了区内负载权重才平稳。再往后我们发现，光靠路由还不够，容量前置才是治本，高峰前把算力铺到对应区域，比临时跨区救火体面太多。跨区兜底那一段我们当初图省事没测透，一次切换没续上请求留了短报错，之后把切换和续传翻来覆去压测才放心。路由省带宽是看得见的收益，但兜底稳不稳才是能不能睡安稳觉的关键。

三、关键技术挑战与解决思路

第一个难点是区域亲和，调用方来源要能识别到区域粒度，我们结合接入点和调用方元数据判定，路由策略优先同区。第二个难点是就近路由，同区有多个实例时还要按负载和延迟选最优，我们做了区内加权路由，避免一窝蜂打爆一个实例。第三个难点是跨区切换，兜底必须快且对，主区健康探测要做到秒级，切换时正在进行的请求要能续上或优雅失败，不能雪崩。第四个难点是成本可视，跨区贵在哪要算清，我们看板把带宽成本摊到区域，哪里贵一清二楚。第五个难点是容量前置，我们按历史区域峰值做预扩，高峰前把算力铺到对应区，减少被迫跨区。

案例片段（已脱敏）： 区域亲和配置：affinity=region、prefer_same_region=true、cross_region_fallback=health_probe<2s；区内加权 weight_by=latency+load。 调度效果：跨区流量占比从 38% 降至 9%，平均延迟从 210 毫秒降至 95 毫秒，月度跨区带宽成本降约 62%。区域容量前置后，高峰跨区触发次数从月均 21 次降至 2 次。

四、效果数据

区域亲和和就近路由生效后，跨区流量占比从近四成降到一成不到，平均延迟从两百多毫秒压到百毫秒内，用户最直观的感受是响应稳了。月度跨区带宽成本降了六成多，账单里这块从扎眼变成可忽略。跨区兜底切换做到秒级，主区异常时业务基本无感。容量前置之后，高峰被迫跨区从月均二十多次降到两次，运维半夜被叫醒的次数断崖式下降。

我们曾经图省事没测透跨区切换，一次主区抖动切换没续上请求，造成短暂报错，之后把切换和续传狠狠测了一遍。路由认区域省的钱比想象多，但兜底必须稳，否则一次故障比慢更糟。还有一个坑，区内加权一开始只按延迟，没算负载，结果低延迟实例被挤爆，加上负载权重才平衡，路由策略的细节决定上限。

五、可复用经验总结

路由不认区域就是白烧钱，我们把亲和和就近做成默认策略后延迟和账单一起下来，省下的带宽比优化模型还立竿见影。区内也要加权，否则就近反而把单实例打爆，亲和加负载均衡才稳。跨区兜底必须测透，切换和续传不做扎实一次故障就前功尽弃，我们栽过才补的课。成本要看板摊开，哪里贵一目了然，治理才有抓手，盲调永远调不到点上。容量要前置到区域，高峰前把算力铺好，比临时跨区救火体面得多。 就近和兜底这两件事，一个省钱一个保命，区域调度把两者同时做对，才算真正落地，少一样都不算完。 容量和路由两手抓，这套打法后来也用到了别的区域型业务上，跑下来都稳，说明就近加兜底的思路经得起复用。