557 字
1 分钟
API 网关的故障转移，为什么有时不该自动切换
API 网关的故障转移，为什么有时不该自动切换
自动故障转移听起来很直接：一个模型渠道报错，就换另一个继续请求。但对持续生成、带工具调用的 Agent 请求来说，“换渠道”不是简单的重发。请求可能已经产生部分输出、消耗了上下文缓存，甚至进入了需要客户端配合的工具阶段；中途换路由，结果可能从“报错”变成更难追踪的状态错乱。
一种可选设计是实时展示请求日志；上游失败时先保留错误状态，让操作者查看详情后手动切换渠道。这样可以避免自动切换时丢失上下文缓存，但会增加人工等待时间。
设计时先写清楚失败语义
- 请求还没发送到上游：可以安全地尝试另一个渠道，但仍需限制次数和总耗时。
- 上游已处理、客户端尚未收到完整结果：盲目重放可能重复扣费或重复执行动作。
- 流式输出进行到一半：切换后需要明确告诉客户端这是新响应，不能假装原流无缝继续。
- Agent 正在执行工具：重放前必须确认工具是否已经产生副作用，例如创建记录或发送消息。
同协议的请求尽量透传，可以减少网关改写工具调用格式的机会；跨协议转换则需要独立测试结构、流式事件和错误映射。日志应足以诊断，又不应长期保存密钥和完整的私密提示词。
标题和版本说明可能使用不同的功能描述。评估网关时，我会以当前版本的变更记录和实际行为为准，确认它究竟是自动重试、自动切换还是等待人工选择。
分享
如果这篇文章对你有帮助，欢迎分享给更多人！
API 网关的故障转移，为什么有时不该自动切换
https://blog.zpooi.com/posts/api-gateway-failover-design/ 部分信息可能已经过时
相关文章 智能推荐
1
把 AI 放进测试流程：先生成候选，再由人确认
开发实践 将需求转成测试点、在隔离环境执行并核对证据，比让 Agent 直接“测一下”更容易落地。
2
给单个应用走代理：Antigravity 的进程级配置思路
开发实践 当编辑器不遵循系统代理时，可只转发指定进程的流量，并逐层验证辅助进程与代理日志。
3
代理节点显示断开，为什么应用还在收到响应？
开发实践 界面状态、代理进程和既有网络连接反映的是不同层；用新连接和日志验证实际出口，别只凭一条回复判断直连。
4
个人服务器需要电话告警？先设计升级路径，再挑 API
开发实践 个人服务器的电话告警常受账号资质限制；先设计多层告警，再按合规条件选择服务。
5
排查 “Stream ended without receiving any events”：先定位请求在哪一层断了
开发实践 流式 API 没有返回事件时，按客户端、代理、网关和 SSE 响应分层排查。