网关为什么会成为新的单点
推理引擎通常按多副本部署，但所有流量都要先经过网关，如果网关只有一个副本，它就成了整条链路里唯一的必过节点：引擎再稳，网关一挂全部模型同时不可用。把网关做成高可用的前提是它本身无状态——会话、配额计数、配置与密钥都放在外部，任一副本可以随时被替换，前面再有一层能感知健康的入口。
基本信息
| 部署形态 | 两副本起步，前端负载均衡或虚拟地址 |
|---|---|
| 状态要求 | 无状态，会话与计数外置到共享存储 |
| 调度要求 | 副本反亲和，避免集中在同一台物理机 |
| 配置管理 | 集中下发，避免各副本配置漂移 |
| 发布方式 | 滚动升级，先摘流量再更新 |
典型使用场景
- 对外正式服务：网关必须避免单点，否则升级窗口等于服务中断窗口
- 多引擎集群：网关承担模型路由，是唯一需要严格做冗余的组件
- 突发流量：多副本可以横向扩展，单副本扩容受单机资源限制
- 滚动升级：无状态设计让副本可以逐个替换而不中断流量
- 故障演练：主动下线一个副本，验证流量是否被平滑接管
形态与验证
形态与验证
负载均衡 / 虚拟地址
├─ 网关副本 A ─┐
└─ 网关副本 B ─┴→ 引擎实例组
验证步骤：
1 同时查看两个副本的健康检查状态
2 主动摘除一个副本，确认请求成功率不受影响
3 升级一个副本后重新纳入，观察是否有配置漂移
4 检查配额计数在副本切换后是否延续去掉单点的检查单
| 层面 | 单点风险 | 做法 |
|---|---|---|
| 接入 | 单条解析记录、无虚拟地址 | 多记录加健康检查，或使用虚拟地址与负载均衡 |
| 副本 | 单副本运行 | 两副本起步，反亲和部署 |
| 状态 | 计数与配置在本地文件 | 外置到共享存储集中管理 |
| 发布 | 升级即全停 | 滚动升级，先摘流量再更新 |
| 密钥 | 各副本手工维护 | 集中管理并统一下发 |
副本间无状态是前提：会话与计数若留在本地内存，切换副本时用户会感到上下文丢失、配额被重置，负载均衡的会话保持会让问题暂时隐藏。
定期做一次主动摘除演练：不做演练时，健康检查配置错误、副本实际未接入这类问题往往到真故障时才发现。