API gateway 的作用：入口路由、策略与后端边界
作者：Ai Flowi · 发布于
API gateway 的作用是作为入口层接收客户端 API 请求，在应用已配置策略的同时，将请求路由到后端服务。根据具体设计，这些策略可以包括身份验证检查、请求限额和转换。网关决定转发请求，与后端决定执行所请求的业务操作，是两回事。
如果请求看似成功，却找不到预期记录，或者受保护的路由存在未受保护的替代路径，理解这一边界就很重要。下方示例说明职责分工，并不配置某个特定网关服务商的产品。
API 网关做什么？
客户端通过 API 契约请求一项操作。网关将入口请求映射到适当后端，检查已配置的入口规则，并转发允许的请求。后端验证自身业务规则、检查特定资源的访问权限，然后执行操作。响应通过入口层返回，该层可以按经过审核的规则筛选响应字段。
客户端请求
↓
网关：选择路由 → 评估入口策略 → 筛选请求字段
↓
后端：授权资源访问 → 验证操作 → 执行操作
↓
后端结果 → 网关响应策略 → 客户端集中管理策略可以让各路由更容易保持一致，也可能让配置错误的影响集中。如果网络允许访问，意外跳过身份验证的路由仍然可达。应同时审核预期路由和替代路径，包括任何向调用方暴露的后端直连地址。
网关与后端职责对照表：窄屏幕上可将焦点移到表格区域，再横向滚动。
| 决策 | 入口层职责 | 后端职责 |
|---|---|---|
| 路由选择 | 将公开操作映射到允许的目标。 | 仅提供预期操作，并拒绝不适当的请求。 |
| 身份验证 | 按照入口策略检查调用方凭据。 | 验证可信身份上下文和资源访问权限。 |
| 限流策略 | 将已配置的请求限额应用到正确的调用方或范围。 | 保护业务资源，并安全处理已接受的工作。 |
| 请求字段筛选 | 仅转发经过审核的字段和请求头。 | 验证字段类型、权限和业务含义。 |
| 业务执行 | 转发请求；不要将转发等同于完成。 | 确认预期写入，或返回已定义的失败结果。 |
| 响应边界 | 对外提供已批准的公共响应契约。 | 提供操作结果证据，不附带不必要的私密细节。 |
API 网关与负载均衡器
负载均衡器在符合条件的目标之间分配流量。API 网关关注 API 入口契约及其策略。一个部署可以兼具两种角色，但仅凭名称，无法判断某个具体部署实际落实了哪些控制措施。在后端实例之间分配流量，本身不会验证 API 调用方或操作允许使用的字段。
应根据需求选择层次：流量分配、API 路由策略、资源授权，或这些需求的组合。如果现有入口层已经满足经过验证的契约，就不必再增加中间层。无论采用何种设计，都应明确谁维护路由映射，以及如何对照现有客户端检查更改。
检查路由目标不匹配
API 对接术语页说明请求异步受理与实际完成的区别；本示例则检查网关从错误目标返回有效响应的情况。
在一个虚构部署中，公开操作 account-summary 应到达生产环境的账户服务，但路由版本 G12 选择了演示服务。两个服务都能理解请求，并返回普通的成功响应。演示记录甚至具有所请求的账户标签。传输检查通过了，调用方却收到来自错误环境的信息。
示意性的路由审核记录，并非生产日志 公开操作：account-summary 路由版本：G12 预期目标：生产环境的账户服务 选中目标：演示账户服务 入口策略：account-reader 策略 P4 关联引用：synthetic-route-check-7 后端环境证据：演示环境 决定：目标不匹配；暂不提供返回的账户摘要
决定性证据是选中的目标及其环境，而不是 HTTP 状态或相同的显示标签。应审核路由 G12 是否发布给了预期客户端群体，以及是否通过可信配置验证了后端身份。如果任意服务都能冒充它，仅凭后端自报名称并不足够。批准该路由版本前，应修正映射，并针对预期环境重新执行读取。
关联关系也必须跨越两个边界而保持完整。应将客户端请求与网关路由决定、后端请求引用关联。如果响应策略删除了公共关联引用，运维人员仍可以在受限诊断信息中保留内部关联。将同一引用复用于无关请求，会使关联不可靠；标识属于具体请求实例，而路由版本属于当时使用的配置。
写入结果不确定时，应采用运维手册中的目标审核流程，并将网关路由版本保留在故障证据中。
分析一次策略绕过故障
假设公开路由要求身份验证，但同一后端可以直接访问，并且信任所有调用方。向直连地址发送未经身份验证的请求，就可能绕过网关策略。如果只通过公开路由测试，配置看似受到保护，而实际服务边界仍然开放。
应按照部署的信任设计关闭绕过路径：限制允许的入口路径，并要求后端验证其所依赖的身份上下文。不能仅仅因为网关通常使用类似请求头，就接受调用方提供的身份请求头。后端必须区分可信的身份声明与不可信输入。
应分别检查：通过网关发送的被禁止请求、直接访问后端的尝试，以及已验证身份的调用方向其权限外资源发起的请求。这是不同的检查。第一项通过，并不能说明另外两项也通过。还应检查响应脱敏：不能意外地让后端私密错误信息成为公开的诊断契约。
AI Flowi Workflow 的组件边界
API Request 和 Universal Webhook 参考文档分别介绍出站调用和工作流入口；在本架构讨论中，其状态为组件目录中有文档说明；Ai Flowi 尚未对其进行生产环境测试。
以下是只读的示例配置，并非已记录的测试：使用 API Request，将 method 设为导出选项 GET
，并将 url_input 设为已授权的网关读取端点。如果端点需要账户或凭据，你须提供自己的服务商账户或凭据，服务商费用另行支付。应根据预期环境和操作契约检查实际响应。这里并未提供端点、响应数据或网关执行结果。
工作流 API 参考文档说明平台自身的 API；HTTP 客户端或工作流触发器都不能证明平台提供托管网关、防火墙或限流策略。如果任务只需要一个私有读取端点，应先检查其现有入口控制是否满足需求。只有存在具体的路由或策略职责需要集中管理时，才有必要考虑独立网关。
常见错误与相关概念
不要把所有资源授权都移到路由选择中，不要假定限流策略覆盖每条入口路径，也不要把响应改写当作后端成功的证据。应区分路由版本、身份信任和业务结果证据。有用的架构审核能够为每种故障指出负责的层次，而不是将所有问题都归咎于“API”。
API 术语页定义底层服务契约。API 测试介绍请求和响应验证。事件驱动架构说明已接受的工作跨越异步投递边界继续执行时会发生什么变化。
相关内容：统一 API：跨服务 API 的共享契约。