一、项目背景

多个业务系统共用同一个 AI 网关，本来是图省事，结果一家流量突增就把别人拖垮。有回智能客服搞活动，调用量瞬间翻倍，把同网关的风控模型请求挤到排队，风控延迟一高，反欺诈判定跟不上，业务侧急得跳脚。问题根源是大家共用一个池子，没有隔离，责任也分不清，出了事谁都说是别人的锅。更糟的是，故障定位时运维要在共享日志里翻半天，才能确定是哪家的流量惹的祸，等到定位清楚黄花菜都凉了。

二、落地场景

我们给网关做了业务域隔离：每个业务线在网关里是一个独立域，配置专属的路由策略、模型实例组和配额。智能客服的流量再怎么涨，也被限制在自己的配额和实例组里，碰不到风控的资源。管控台里每个域的消费、延迟、错误率一目了然，哪个域出问题一眼定位，再也不用全公司一起背锅。新业务接入时，默认分配独立域，从第一天就隔离，不会因为它没配就被挤进公共池，从根上杜绝了后来者被老业务拖垮的可能。

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

隔离要物理和逻辑都到位。逻辑上用命名空间把路由、配额、计量分开；物理上关键域走独立实例组，避免共享热点。配额治理分两层：硬配额封顶防雪崩，软配额做预警，域快用完时先告警业务自己收。路由策略按域配，风控域优先走低延迟小模型，客服域可走大模型保效果。我们还做了跨域借用机制，平时隔离、极端情况下经审批可临时借调闲置配额，兼顾安全和弹性，避免业务高峰期被自己定的规则卡死。借用记录全留痕，事后可审计，谁借的、借了多少、还了没有一目了然。

四、效果数据

隔离上线约五个月，业务间互相影响的事故从之前每季度两三起降到零。智能客服大促当天调用量涨约两倍，风控域 P99 延迟纹丝不动，稳定在目标值内。各域配额使用率监控覆盖百分百，月度软配额预警触发约十余次，均在业务侧自行收敛。资源整体利用率反而提升，因为闲置域的配额能被借用，浪费减少。运维排障时长从平均半小时降到五分钟，全靠按域可视化定位，那次客服挤垮风控的事故再没重演，风控同学终于睡上了安稳觉。

五、可复用经验总结

多业务共用网关，隔离是底线，不是可选项。我们那次风控被挤趴下的事故，根子就是没隔离，之后这成了最高优先级。硬配额兜底下限，软配额给业务留面子，两者配合比一刀切封顶 humane 也有效，业务方不觉得被卡脖子，配合度自然高。跨域借用要留审批口子，太死板业务会绕开你另搞一套，反而更难管。监控按域拆开，责任清晰了，扯皮就少了，这是组织收益不只对技术。先把隔离做扎实，再谈弹性，顺序不能反，否则弹性只会放大混乱。

结语

隔离这件事，我们是用一次风控被挤趴下的事故才真正重视起来的。那回智能客服搞活动，流量翻倍把同网关的风控请求挤到排队，反欺诈判定跟不上，业务急得跳脚，根子就是没隔离。从那以后多业务共用网关，隔离是底线，没有商量余地。硬配额兜底下限、软配额给业务留面子，这套组合比一刀切封顶更温和，业务方配合度高。跨域借用我们留了审批口子，太死板业务会绕开你另搞一套，反而更难管。运维排障时长从半小时降到五分钟，靠的就是按域可视化定位，那次事故再没重演，我们后来也把隔离规范写进了新业务接入清单，先把隔离做扎实再谈弹性，这个顺序不能反，我们在这上面交过实在的教训。

我们后来也把隔离规范写进了新业务接入清单，默认独立域，从源头杜绝后来者被老业务拖垮。回头看先把隔离做扎实再谈弹性，这个顺序不能反，反过来弹性只会放大混乱。监控按域拆开之后责任清晰了，扯皮肉眼可见地少了，这是组织收益，不只对技术。

现在新业务接入我们默认就给独立域，从源头杜绝后来者被老业务拖垮，这条规范写进 checklist 之后，再没出过混用公共池的事故。隔离带来的另一个好处是故障定位快，运维不用在共享日志里翻半天，看板上一眼就知道是哪家的流量，排障时长直接从半小时降到五分钟。

案例片段（已脱敏）： 管控台某日快照： 域=智能客服：配额 80 万 token/日，已用 78 万（软配额预警，触发业务自查，发现一处循环调用已修复） 域=风控反欺诈：配额 30 万，已用 12 万，P99=210ms，错误率 0% 域=营销文案：配额 50 万，已用 9 万 当日无跨域资源争抢，风控域未受客服高峰影响。后续智能客服申请临时借用营销域闲置配额 10 万，经审批后生效，平稳度过活动尾声，借用记录归档备查，次月自动归还无残留，两个域的负责人都没为此扯过一次皮。