全球 AI 网关架构：从入口到计费记录的完整链路
在构建一套能够覆盖全球、多区域部署，并支持跨供应商路由的 AI 网关体系时，我们很快意识到，仅仅把一组区域化的集群堆叠起来并不能真正解决问题。真正的挑战在于链路的完整性：当请求从不同地域、通过不同网络条件，并借助多家入口提供商接入系统时，网关内部的调度与控制插件如何与 DCDN、区域网关协同工作，从而保证“入口稳定性”“跨供应商调度能力”和“故障场景下的可用性”能够形成一条连续且可控的技术链路。本文试图从这个角度拆解整个过程，依次说明每个组件在链路上扮演的角色，以及它们之间如何自然衔接，从而支撑一个稳定、可观测和可审计的全球 AI 调用体系。
为了让讨论更直观，我们沿着请求的自然路径，从 DCDN 入口开始，依次跟踪到区域网关、节点内部调度逻辑，并最终到达 usage / 计费记录的汇总过程，从而呈现整个体系如何在复杂性和一致性之间取得平衡。
从 10,000 米俯视这套系统，可以用一条简单的链路来概括：
终端用户
│ 单一域名访问
▼
〔DCDN / 全局入口层〕
│ 多家 CDN / PoP，按地域、健康度和策略动态选路
▼
〔区域网关集群（Gateway Node，多区域）〕
│ 鉴权 / 风控 / 供应商选择 / 内部调度插件
├──────────────→ 各区域 AI 供应商 / 模型
│
▼ usage / 计费事件
〔全局管理平面〕
├→ Manager：入库 / 结算 / 风控
└→ Admin：统一管理入口（配置 / 报表 / 策略分发）
1. 全局拓扑：三层结构背后的链路逻辑
从任意地点发出的请求，在本架构中通常经历三层逻辑。首先，它落在全局入口层，由多家 DCDN 提供的边缘节点尽可能就近且稳定地接收流量；随后，请求根据地理位置、健康状态以及流量策略被引导至对应区域的网关集群，由区域网关完成鉴权、风控、租户映射以及供应商选择等核心操作；最后，当请求进入具体节点后，节点内部的调度与控制插件会在统一状态视图下执行决策、管理回退，并将整个调用过程的关键事实写入 usage 日志。
前两层的关注点在于“请求在哪里落地以及应送到哪个区域”，而第三层则关注“在区域内如何执行、如何控制状态、如何确保记录的准确性”。三者之间既有清晰边界，也高度协同，形成一条既分层又连续的技术链路。
2. 全局入口层：多路径容错与动态选路
入口层的核心目标是：在全球范围内，以最低延迟和最高可用性接住请求。实现这一目标并非简单堆叠 CDN 节点，而是要求入口对网络状态高度敏感、能够动态适配和调整路由策略。
具体做法如下：
对外单一域名背后接入多家 CDN / PoP，每个节点不仅提供网络覆盖，还参与健康检查与动态权重计算；
入口层持续执行健康检测，包括可用性、延迟、丢包率和错误率等指标，根据策略动态调整流量权重；
当某家提供商或 PoP 出现异常时，流量会自动切换至其他 DCDN 或自建入口，以确保整体链路不受单点故障影响。
在架构设计上，Cloudflare 是其中重要的一环，但其身份是“可替换路径”，而非单点依赖；入口层完成路径选择之后，流量会根据地域策略被分发至对应区域的网关集群，从而为后续调度提供稳定前置条件。
如果单独放大入口层，大致是下面这样的形态：
用户浏览器 / 客户后端
│ 访问 api.xxx.com
▼
统一域名（DNS / Anycast）
│
┌───────┴────────┬───────────────┐
▼ ▼ ▼
〔DCDN 提供商 A〕 〔DCDN 提供商 B〕 〔自建入口〕
│ │ │
└─────── 基于健康度 / 延迟择优 ───────┘
│
▼
目标区域入口（如 AP-SG / EU-FRA）
3. 区域网关层：一致代码、策略下发与区域自治
当请求抵达某个区域后，它将进入部署在该区域的网关集群（Gateway Node）。这些集群之间保持对等关系，运行相同代码并共享统一策略模型，同时基于管理端下发的配置针对区域特性进行策略调优，包括供应商选择、网络线路偏好以及服务级别控制。通过这种方式，系统在全局保持一致服务形态的同时，也能应对区域网络波动和供应商质量差异。
区域网关的主要责任包括：
完成基础鉴权与风控，拦截异常流量；
将请求映射至租户、产品线和具体服务类型；
根据区域配置选择供应商和代理线路，并在必要时执行有边界的本地回退（fallback），避免单个渠道故障引发区域级连锁抖动。
节点内部的调度与控制插件便在此层执行，它将上述动作串成原子化执行过程，确保一次调用从进入到离开都是可控、可审计、可回溯的。
从拓扑上看，一个区域内大致是这样的结构：
区域入口（例如 AP-SG）
│
▼
区域负载均衡
│
┌───────────┴───────────┐
▼ ▼
Gateway 节点 1 Gateway 节点 2 …（同一集群）
│ │
└──────── 共享状态层 / 策略配置 ───────┘
│
▼
本区域 AI 供应商 / 代理池
4. 节点内部调度插件：识别、决策与记录的连续过程
节点级调度插件是整个链路的核心，其流程可划分为三个连续阶段：识别、决策和记录。
识别阶段：构建调用上下文 插件识别调用方身份、调用目标、模型类型、服务级别以及预期区域，并基于管理端下发的配置构建策略视图，为后续决策提供统一上下文，从而保证不同区域或入口的请求在策略执行上保持一致。
决策阶段：在统一状态层上进行原子判断 插件在全局状态层上执行原子操作，包括额度消耗、并发控制、限流判断，并结合区域路由规则选择具体供应商或代理链路；当出现供应商不可用或网络错误时，插件在策略允许范围内发起区域内回退，仅切换至备选渠道，并严格控制边界，避免级联重试或状态重复扣减。
记录阶段：将调用事实写入 usage 插件将调用过程的关键数据（入口来源、落地区域、供应商选择、回退信息等）写入 usage / 日志体系，这些数据会被管理端用于结算、风控、分析以及未来调优。该流程确保多入口、多区域、多供应商环境下的调用结果保持一致、可追踪。
如果只看单个节点内部，可以把这段流程串成一条清晰的处理链路：
进入节点的请求
│
▼
身份 / 租户识别
│
▼
风控校验
│
▼
状态层检查与占用（额度 / 并发 / 限流）
│
▼
按区域 / 策略选择供应商与代理
│
▼
发起下游调用（含一次受控回退）
│
▼
写入 usage / 日志 → 供管理端消费
5. Cloudflare 故障处理：入口与网关双重兜底
我们在设计中不假设第三方入口永远稳定，而是将其视作可能出现局部或区域性故障的组件，并在入口层与网关层构建双重保护。
入口层保护
健康检测是入口层的常态，当 Cloudflare 的某个区域、某组 PoP 或整体网络异常时，系统会立即将对应路径标记为不可用，并将新流量优先路由到其他 DCDN 或自建入口。已有连接短时间内可能受影响，但不会阻塞新请求。
网关层保护
当请求进入网关后，如果下游某 AI 供应商不可用，调度插件会在策略允许下触发一次区域内备选供应商回退，并将回退信息写入 usage。整个过程严格控制边界：不会多次跳转，也不会造成状态重复扣减或计费误差。
这种设计保证了在第三方入口发生故障时，系统能够从入口和区域两端自我修复，最终用户感知更多是性能波动而非服务不可用。
6. 计费与额度管理：插件作为统一状态执行器
尽管本文不展开具体计费公式，但与架构相关的原则明确如下：
所有额度、并发、限流等状态集中存放于全局状态层，而非依赖任何单台 Gateway 节点；
调度插件在全局视角下仅作为“对状态执行原子修改”的执行器。
因此，无论流量来源于哪家 DCDN、落在哪个区域、由哪个节点处理，调用记录都会统一汇总；回退或入口切换不会引起重复计费、漏记或数据歧义，保证全局 usage 数据的唯一性和准确性。
从数据流的角度，再看一眼 usage 与管理端之间的关系，可以抽象成：
多区域网关节点（持续产生 usage 事件）
│
▼
全局管理服务（Manager）
│ 入库 / 结算 / 风控
▼
按日 / 周 / 月的账单与报表
│
▼
管理控制台（Admin：统一管理入口）
│ 人工查看 / 策略调整
▼
回写配置与阈值 → 影响后续调度
7. 总结：分层架构保证链路可靠性，而非单点
如果将系统凝练为一句话，则为： 通过入口多路径、区域多集群、节点内部受控回退以及全局一致的状态管理，我们构建了一条稳健的调用链路，而非依赖任何单一组件的“永不出故障”假设。
入口层保证全球流量“能进来、能切路”；
区域网关保证落地后的路由“精细且自治”；
节点调度插件保证每次调用“有过程、有保护、有记录”。
Cloudflare 在入口体系中是重要的一环，但它不是系统可靠性的基石；真正支撑整个系统稳态运行的，是从入口到执行再到记录的连续架构逻辑。
延伸阅读：体系落地实践
我们已经在生产环境中落地了本文描述的这套从入口到计费的调用体系，如果你希望了解更具体的工程实践、架构演进与踩坑记录，可以参考我们的实践站点：
- 体系落地实践与案例
也欢迎通过站点上的联系方式与我们交流架构设计、接入方案与落地经验，把这套从入口到计费可审计的调用链路应用到你的业务场景中。
