Gateway、代理和中转在请求链路里的位置

建议用时：25 分钟（含练习）

学习目标

能够解释网关如何统一认证、路由、限流和审计，以及它新增的数据与信任边界。

本节产出

一张官方直连与网关链路对比图

核心知识：多加一跳，就多一组责任

模型请求不一定从客户端直接到达提供商。它可能先经过企业网关、反向代理或第三方中转。名字有重叠，真正要看的是这一跳做了什么：只转发网络连接，还是终止 TLS、验证凭证、改写请求、选择上游、统计用量或存储日志。

术语

网关

网关通常作为统一入口处理一组服务能力，例如鉴权、配额和路由。

代理强调代一方转发请求，在不同架构中可以位于客户端或服务端一侧。中转是较宽泛的业务描述，本身不说明可信度、协议或授权关系。不要仅凭名称判断它是简单通道，还是会读取和改写内容的应用服务。

如果某一跳终止了 TLS，它通常能够在相应处理边界看到明文请求。HTTPS 保护的是连接传输，不意味着连接终点对内容不可见。下游是否继续使用 TLS、谁能访问日志、请求是否会被保存，需要按实际部署和服务政策确认。

图里客户端凭证和上游凭证是两个不同的对象。你发给网关的密钥可能只用于网关认证；网关再用自己管理的上游凭证请求提供商。也可能采用透传或其他模式，不能一概而论。画清这一点，才能知道密钥泄露或轮换会影响哪一段链路。

网关能够解决什么，不能替你解决什么

网关能解决的

统一入口便于集中限流、路由、观测和配置。对于多个应用，可以避免每个应用单独维护全部提供商细节。

网关不替你解决的

但它也增加了故障点和信任边界：网关配置错误可能把请求转向错误目标，协议转换可能丢失字段，重试可能放大上游调用数量。

网关不能把未经授权的账号变成合法可用资源，也不能只靠技术转发消除服务条款和数据处理要求。对于第三方托管服务，应独立核对运营主体、账号与模型来源、数据政策、服务连续性和费用记录。本课不推荐任何未核验的中转商。

案例：为什么一次点击变成多次请求

假设客户端在失败时最多尝试三次，而网关对每个收到的请求也最多向上游尝试三次。极端情况下，一次用户动作可能产生九次上游尝试。这里说的是尝试次数，不等于九次一定成功或九次一定按相同规则计费，但足以说明不能分别配置重试却不考虑整体行为。

对于只读取信息的请求，重复通常主要影响成本和延迟；对于有副作用的动作，例如创建任务或提交记录，重复可能改变外部状态。应优先采用接口支持的幂等机制、唯一业务标识和明确的重试策略。不能因为模型请求主要生成文本，就把整个 Agent 后续动作也当成无副作用。

排错时，为客户端请求、网关处理和上游调用建立可关联的追踪标识。标识应帮助定位一条链路，而不是携带密钥。记录实际尝试次数、响应状态和是否收到正常结束；对正文是否落盘则采用最小化原则。

如何阅读网关架构图

给每个方框写上组织或系统负责人，给每条箭头写上协议和凭证来源，再标明哪个节点能够读取正文。最后问：这一跳不可用时，用户会看到什么？系统是否会自动切换？切换后数据是否进入另一个提供商？如果不能回答，架构图还只是漂亮的连接线。

动手练习

1. 画出一个虚构的“客户端—企业网关—模型提供商”链路，分别标明两段凭证、TLS 终点、日志与配额。
2. 为客户端和网关设计一个整体重试预算，说明哪些错误立即停止、哪些可以等待后重试。
3. 写出使用第三方网关前需要核对的五个问题，每个问题都对应可验证资料或配置，而不是“口碑不错”。

参考答案与推演

展开

完成检查

• 能说明每一跳实际执行的功能与信任边界。
• 区分客户端凭证和上游凭证，不把 HTTPS 当成端点不可见。
• 重试预算考虑整个链路，识别有副作用的动作。
• 网关选择依据可核验信息，而非兼容标签或价格承诺。

参考与来源

• MDN：Proxy servers and tunneling：了解代理角色与转发方式。
• AWS Builders’ Library：Timeouts, retries and backoff with jitter：了解多层重试、超时与退避的设计问题。