10-API网关、反向代理与边缘网络

要点

  • 一个 AI API 请求从浏览器发出后，并不是直接到达你的 Hono 服务，中间至少经过 DNS、CDN 边缘节点、反向代理或 API 网关
  • 反向代理和 API 网关解决的问题不同：前者偏向流量管理和安全防护，后者偏向业务层面的认证、计费和协议转换
  • CDN 不只是缓存静态资源，现代边缘网络已经在承担 API 加速、安全防护甚至边缘计算的角色
  • Cloudflare 的边缘网络把 Workers、WAF、AI Gateway、Vectorize 等能力组合在一起，正在改变 AI 后端的部署方式
  • 对 AI 后端来说，网络架构直接影响延迟、安全、成本和可靠性四个维度
  • Hono 通常运行在反向代理或 API 网关之后，搞清楚职责边界比记住工具清单更重要

1. 请求的网络旅程

前面九篇，我们把一个请求的生命周期从 HTTP 协议、运行时、Serverless 聊到了事件循环。但这些讨论都集中在「请求到达你的代码之后发生了什么」。本篇要把视角拉到请求到达之前——它在网络中经过了哪些节点。

先看一条完整路径。用户在浏览器输入一句话，点击发送，等待 AI 回复。这个请求从浏览器出发，到最终返回响应，经过的路径大致如下：

浏览器
  │
  │ ① DNS 解析（域名 → IP）
  ▼
CDN 边缘节点（离用户最近的 PoP）
  │
  │ ② TLS 握手，HTTP/2 或 HTTP/3 连接
  │ ③ 安全过滤：WAF、DDoS 防护、Bot 检测
  │ ④ 路由判断：缓存命中 or 回源
  ▼
反向代理 / API 网关
  │
  │ ⑤ 认证、限流、请求转发
  │ ⑥ SSL 终止，协议转换
  ▼
应用服务器（Hono 服务）
  │
  │ ⑦ 业务逻辑处理
  │ ⑧ 调用模型 API（OpenAI / 本地模型）
  ▼
模型 API
  │
  │ ⑨ 生成响应（可能是 SSE 流式数据）
  ▼
原路返回：应用服务器 → 反向代理/网关 → CDN → 浏览器

每一步都有延迟开销、安全考量和潜在的故障点。AI 请求的特殊之处在于：模型生成本身就慢（几秒到几十秒），网络链路上的每一毫秒额外延迟都会被放大成可感知的体验问题。

2. 反向代理（Reverse Proxy）

2.1 什么是反向代理

反向代理是一种位于客户端和后端的中间服务。客户端发出的请求先到达反向代理，由反向代理决定把请求转发给哪个后端服务，再把后端的响应返回给客户端。

与正向代理（代表客户端访问外部服务）不同，反向代理代表的是服务端。客户端不知道后端有多少台服务器，也不知道后端的具体地址，它只知道反向代理的地址。

客户端  ──→  反向代理  ──→  后端服务器 A
                ├──→  后端服务器 B
                └──→  后端服务器 C

2.2 核心功能

反向代理在 AI 后端中承担的职责：

负载均衡：把请求分发到多个后端实例。AI 后端通常需要调用耗时的模型 API，如果只有一个实例，长连接容易耗尽。负载均衡保证流量被均匀分配。

SSL 终止：TLS 加解密在反向代理完成，后端服务器处理明文 HTTP。这简化了后端配置，也减少了后端 CPU 开销。

请求转发与路由：根据请求路径、Header 或参数，把请求分发到不同的后端服务。例如 /api/chat 转发到 AI 服务，/api/users 转发到用户服务。

静态资源服务：图片、CSS、JS 等静态资源可以直接由反向代理返回，不必经过应用服务器。

连接管理：反向代理维护与后端的连接池，复用连接，减少后端压力。AI 后端的模型 API 调用通常需要长时间保持连接（SSE），连接管理在这里很关键。

2.3 常见工具

工具特点AI 后端适用场景
Nginx高性能、生态成熟、配置灵活传统部署中最常见的反向代理
Caddy自动 HTTPS、配置简洁快速搭建、开发环境、小项目
HAProxy专注负载均衡、稳定性强高并发、需要精细流量控制
Envoy云原生、支持 gRPC 和 HTTP/2微服务架构、Service Mesh

对大多数 AI 后端项目，Nginx 或 Caddy 已经足够。如果你部署在 Cloudflare Workers 上，反向代理的角色会被 Cloudflare 的边缘网络部分替代。

3. API 网关（API Gateway）

3.1 与反向代理的区别

反向代理解决的是「流量怎么到后端」的问题，API 网关解决的是「流量怎么被管理」的问题。

两者的边界并不总是清晰。很多反向代理（如 Nginx）可以通过插件实现部分网关功能，很多 API 网关本质上也是一个增强型反向代理。但在职责侧重上，它们有明确分工：

维度反向代理API 网关
核心关注流量转发、负载均衡业务治理、安全策略
认证通常只做 SSL 终止支持 API Key、OAuth、JWT 等多种方式
限流简单的速率控制精细的限流策略（按用户、按接口、按配额）
协议转换通常不处理HTTP ↔ gRPC、REST ↔ GraphQL 等
监控基础访问日志完整的 API 调用链路追踪、用量统计
计费不涉及支持按调用量计费、套餐管理

3.2 核心功能

认证与鉴权：API 网关是统一的认证入口。所有请求先经过网关验证身份，通过后才能到达后端。在 AI 后端中，这意味着 API Key 验证、用户身份校验、权限检查都可以在网关层完成，不需要每个后端服务重复实现。

限流与配额：AI API 的调用成本很高（模型 API 按 token 计费）。API 网关可以在入口层就限制每个用户的调用频率和总量，防止成本失控。

路由与版本管理：同一个 API 可能有多个版本（/v1/chat、/v2/chat），网关负责把请求路由到正确的后端版本。

协议转换：前端可能用 REST 接口，后端可能是 gRPC 服务，网关负责在中间做协议适配。

监控与日志：API 网关可以记录每次调用的完整信息：请求耗时、状态码、Token 用量、错误类型。这些数据对 AI 后端的成本分析和故障排查至关重要。

3.3 代表产品

产品类型特点
Kong开源/商业基于 Nginx，插件生态丰富，支持自定义插件
AWS API Gateway云服务与 AWS 生态深度集成，按调用量计费
Cloudflare API Shield云服务侧重安全，提供 Bot 管理和 API 指纹
Tyk开源/商业Go 语言实现，性能较好
Apigee商业Google 旗下，企业级 API 管理平台

对于独立开发者和小团队，Cloudflare 的能力组合（API Shield + Workers + AI Gateway）提供了一个低维护成本的选择，后面会展开讲。

4. CDN 与边缘网络

4.1 CDN 的基本原理

CDN（Content Delivery Network）的核心思路很简单：把内容缓存到离用户更近的节点，让用户不必每次都访问源站。

用户在广州
  │
  │ 传统方式：请求 → 源站（北京）→ 响应
  │ 延迟：~50ms 单程
  │
  │ CDN 方式：请求 → CDN 广州节点 → 缓存命中 → 响应
  │ 延迟：~5ms 单程

CDN 节点（也叫 PoP，Point of Presence）分布在全球各地。用户请求一个资源时，DNS 会把请求路由到最近的 CDN 节点。如果节点上有缓存，直接返回；如果没有，节点向源站请求，缓存后返回。

4.2 CDN 对 API 的价值

传统 CDN 主要缓存静态资源（图片、CSS、JS）。但现代 CDN 的能力已经扩展到 API 加速：

动态内容加速：CDN 节点可以与源站保持长连接，优化传输路径。对于 AI 后端的 SSE 流式响应，CDN 可以在节点和源站之间维持稳定的连接，减少网络抖动对用户体验的影响。

边缘计算：CDN 节点不再只是缓存，还可以运行代码。Cloudflare Workers、Vercel Edge Functions、AWS Lambda@Edge 都允许你在 CDN 节点上执行逻辑。

安全防护：CDN 作为流量入口，天然适合做 WAF（Web Application Firewall）、DDoS 防护和 Bot 管理。所有请求先经过 CDN 过滤，恶意流量在边缘就被拦截。

4.3 Cloudflare 的边缘网络

Cloudflare 在全球 300 多个城市有数据中心。它的边缘网络提供的不仅仅是 CDN 缓存，而是一套完整的计算和安全平台：

  • Workers：在边缘运行 JavaScript/WASM 代码，延迟通常在个位数毫秒
  • KV / D1 / R2：边缘存储，数据分布在多个区域
  • Vectorize：边缘向量数据库，用于 RAG 和语义搜索
  • Workers AI：在边缘运行 AI 模型推理
  • AI Gateway：统一的 AI API 代理层，提供缓存、限流、日志、路由能力

4.4 边缘计算 vs 传统 CDN

维度传统 CDN边缘计算
核心能力缓存静态资源在边缘运行代码
执行逻辑无可以执行任意逻辑
数据存储缓存持久化存储（KV、数据库）
典型场景图片、CSS、JS 加速API 服务、认证、A/B 测试、AI 推理
代表产品Akamai、FastlyCloudflare Workers、Vercel Edge

边缘计算不是替代传统 CDN，而是在 CDN 的缓存能力之上增加了计算能力。一个请求到达边缘节点后，可以执行认证、限流、甚至 AI 推理，而不必回源。

5. Cloudflare 在 AI 后端中的角色

5.1 Workers 运行在边缘

Hono 与 Cloudflare Workers 的集成是官方支持的。Workers 运行在 Cloudflare 的全球边缘网络上，每个请求都在离用户最近的节点执行。

对 AI 后端来说，这意味着：

  • 鉴权、限流、请求转发这些「前置逻辑」在边缘执行，延迟极低
  • Hono 服务本身也可以运行在 Workers 上，享受全球部署和 Serverless 的优势
  • 冷启动时间几乎为零（Workers 使用 V8 Isolates，不使用容器）

5.2 安全能力

AI API 面临的安全威胁包括：API Key 泄露、恶意刷接口、DDoS 攻击、爬虫抓取敏感数据。

Cloudflare 的安全能力在边缘层就能处理这些威胁：

  • WAF：基于规则过滤恶意请求（SQL 注入、XSS 等）
  • DDoS 防护：自动检测和缓解大流量攻击
  • Bot Management：区分人类用户和自动化脚本
  • API Shield：为 API 提供设备级别的认证，防止 API Key 被滥用

5.3 AI 能力

Cloudflare 近年在 AI 方向投入明显。与 AI 后端直接相关的产品：

Workers AI：在边缘运行 AI 模型推理，支持 LLM 文本生成、Embedding、图像生成等。不需要自己管理 GPU，按 token 或按调用次数计费。

Vectorize：向量数据库服务，运行在边缘。适合 RAG 场景——用户的文档切分后生成向量，存入 Vectorize，检索时在边缘完成相似度计算。

AI Gateway：一个统一的 AI API 代理层。你的后端不直接调用 OpenAI/Anthropic，而是通过 AI Gateway 转发。AI Gateway 提供：

  • 请求缓存（相同的 prompt 不重复计费）
  • 限流和配额管理
  • 请求日志和用量统计
  • 多模型路由和故障转移
  • 日志和可观测性

5.4 Hono + Cloudflare Workers 为什么值得学

把前面的能力组合起来看：

Hono（路由、中间件、类型安全、流式响应）
  + Cloudflare Workers（边缘运行时、全球部署、无冷启动）
  + Cloudflare AI（Workers AI、Vectorize、AI Gateway）
  + Cloudflare 安全（WAF、DDoS、API Shield）

这个组合覆盖了 AI 后端从代码到部署到安全的大部分需求。Hono 负责业务逻辑，Workers 负责运行环境，Cloudflare 负责基础设施和安全。你不需要自己搭建 Nginx、配置证书、管理服务器。

这不是说它是唯一选择，但对独立开发者和小团队来说，它把运维复杂度降到了很低的水平。

6. 对 AI 后端的实际影响

网络架构的选择对 AI 后端有四个维度的实际影响：延迟、安全、成本、可靠性。

6.1 延迟优化

AI 请求的延迟由几部分组成：网络传输、网关处理、模型生成、流式回传。

模型生成延迟通常无法优化（取决于模型本身和网络位置）。但其他部分可以：

  • 边缘部署：把 Hono 服务部署在 Cloudflare Workers 上，用户的请求到达最近的边缘节点，减少网络往返时间。一个从广州发出的请求，到北京源站单程约 50ms，到广州边缘节点约 5ms。
  • 连接优化：CDN 与源站之间保持长连接，减少 TCP 握手和 TLS 握手的开销。
  • HTTP/2 或 HTTP/3：多路复用减少队头阻塞，QUIC 减少连接建立时间。
  • 边缘缓存：对于不常变化的响应（如模型列表、配置信息），在 CDN 边缘缓存，避免回源。

对流式响应来说，第一个 token 到达用户的时间（Time to First Token, TTFT）是核心体验指标。网络层面的优化直接影响 TTFT。

6.2 安全防护

AI API 的安全风险比普通 API 更高，因为涉及用户对话内容和付费调用。

关键安全措施：

  • API Key 保护：API Key 不应该直接暴露在前端。通过 API 网关或 Workers 转发，API Key 只存在于服务端环境变量中。
  • 限流：防止恶意用户大量调用导致成本失控。AI API 的每次调用都有 token 成本，不限流等于不设防。
  • IP 黑名单：发现恶意 IP 后，在边缘层直接拦截，不必到达后端。
  • 请求体检查：WAF 检查请求体是否包含恶意内容（如注入攻击），在边缘层过滤。

6.3 成本控制

AI API 的成本主要来自模型调用。网络架构可以从几个方面帮助控制成本：

  • CDN 缓存：对于相同的请求（如固定问答、文档查询），在 CDN 边缘缓存响应，不重复调用模型 API。
  • AI Gateway 缓存：Cloudflare AI Gateway 可以缓存相同的 prompt 响应，直接返回缓存结果。
  • 边缘过滤：无效请求、重复请求、恶意请求在边缘被拦截，不消耗后端的模型调用额度。
  • 边缘计算：一些轻量逻辑（如简单的意图分类、关键词匹配）可以在边缘完成，不必调用大模型。

6.4 可靠性

AI 后端需要面对模型 API 的不稳定性（超时、限流、服务故障）。网络架构可以提供额外的可靠性保障：

  • 多区域部署：Cloudflare Workers 自动在全球多个区域运行，一个区域故障不影响服务。
  • 故障转移：API Gateway 可以配置多个上游模型服务。如果 OpenAI 不可用，自动切换到 Anthropic 或本地模型。
  • 重试机制：在网关层配置重试策略，对于临时性错误（502、503、超时）自动重试。
  • 熔断：当上游服务连续失败时，暂时停止调用，返回降级响应，避免级联故障。

7. Hono 在网络架构中的位置

理解了网络架构的各个组件后，需要明确 Hono 在这个架构中的位置和职责边界。

7.1 典型的部署架构

浏览器 / 移动端
  │
  ▼
Cloudflare CDN（边缘网络）
  │  - DNS 解析
  │  - TLS 终止
  │  - WAF / DDoS 防护
  │  - 静态资源缓存
  │  - 边缘计算（Workers）
  ▼
API 网关 / 反向代理
  │  - 认证（API Key / JWT）
  │  - 限流
  │  - 请求日志
  │  - 路由转发
  ▼
Hono 应用服务
  │  - 业务逻辑
  │  - 参数校验
  │  - 模型调用编排
  │  - 流式响应处理
  │  - 数据持久化
  ▼
模型 API / 数据库 / 存储服务

如果你的 Hono 服务运行在 Cloudflare Workers 上，架构会更扁平——CDN 和计算在同一个边缘节点完成，不需要单独的反向代理层：

浏览器 / 移动端
  │
  ▼
Cloudflare 边缘节点
  │  - DNS / TLS / WAF / DDoS
  │  - Workers 运行 Hono 服务
  │  - 认证 / 限流（中间件）
  │  - AI Gateway 调用模型
  │  - KV / D1 / R2 数据存储
  ▼
外部模型 API / Vectorize / 其他服务

7.2 职责划分原则

一个常见的困惑是：哪些职责应该交给网关/CDN，哪些应该在 Hono 中处理？

一个实用的划分原则：

放在网关/CDN 层：

  • TLS 终止和证书管理
  • DDoS 防护和基础 WAF
  • 静态资源缓存
  • 全局限流（防止恶意流量到达后端）
  • 请求日志和基础监控
  • AI API 的缓存和重试（如 AI Gateway）

放在 Hono 层：

  • 业务逻辑和参数校验
  • 用户级别的认证和权限检查
  • 模型调用编排和流式响应
  • 数据持久化和事务处理
  • 业务级别的限流（按用户配额）
  • 错误处理和降级策略
  • 业务日志和可观测性

两者都可以做，根据项目规模选择：

  • 简单的认证（如 API Key 验证）可以放在 Hono 中间件，复杂的（如 OAuth、多租户鉴权）考虑网关
  • 简单的限流可以在 Hono 中间件做，全局限流和配额管理交给网关更合适
  • 请求日志两边都可以记录，但网关日志偏向访问统计，Hono 日志偏向业务追踪

对早期项目，不必一开始就搭建完整的网关架构。Hono 中间件可以承担大部分职责。随着用户量增长和安全需求提升，再逐步引入独立的网关层。

8. 本分组总结与下一步预告

8.1 回顾：Web 服务基础与运行时原理

这是「01-Web 服务基础与运行时原理」分组的最后一篇。回顾一下这个分组走过的路径：

01 HTTP 协议基础
   └─ 理解请求-响应模型、方法语义、状态码、Headers 结构
 
02 Headers、Body 与状态码
   └─ 深入 HTTP 协议的细节，Content-Type、认证、流式响应
 
03 RESTful API 设计
   └─ 如何设计可理解、可维护的 AI API 接口
 
04 Web Standards 与跨运行时
   └─ Fetch API、Request/Response、ReadableStream 等标准
 
05 Fetch API 工作模型
   └─ 如何发起请求、处理响应、管理流式数据
 
06 运行时与跨平台
   └─ Node.js、Bun、Deno、Cloudflare Workers 的差异与选型
 
07 Serverless 与 Edge 计算
   └─ 无服务器架构、冷启动、边缘部署的核心概念
 
08 事件循环与并发模型
   └─ JavaScript 异步机制、并发、阻塞与性能
 
09 同步、异步与事件循环
   └─ 深入理解运行时的执行模型
 
10 API 网关、反向代理与边缘网络（本篇）
   └─ 请求在网络中经过的节点、各层职责、对 AI 后端的实际影响

这个分组的核心目标只有一个：让你清楚一个请求从发出到返回，中间发生了什么，你在什么环境里写后端代码。

这些知识不会直接让你写出一个 AI 功能，但它们决定了你在后续遇到性能问题、安全问题、部署问题时，能否定位到真正的根因，而不是在表面来回试探。

8.2 下一步：Hono 快速上手

从下一篇开始，进入第二个分组「Hono 快速上手」。

你会从概念层进入代码层：

  • 搭建第一个 Hono 项目
  • 理解 Hono 的项目结构和核心概念
  • 写出第一个可运行的 API 服务
  • 把服务部署到 Cloudflare Workers

本分组建立的知识——HTTP 协议、运行时、网络架构——会在实际编码中不断被调用。你会发现自己写出的每一行 Hono 代码，都在与这些底层概念打交道。

延伸阅读

总结

一个 AI API 请求从浏览器发出到返回，经过了 DNS 解析、CDN 边缘节点、反向代理或 API 网关，最终到达你的 Hono 服务。每一层都有自己的职责：CDN 负责缓存和安全，反向代理负责流量管理和 SSL 终止，API 网关负责认证、限流和业务治理，Hono 负责核心业务逻辑。

这些网络组件对 AI 后端的影响体现在四个维度：延迟（边缘部署减少往返时间）、安全（边缘层拦截恶意流量）、成本（缓存和过滤减少模型调用）、可靠性（多区域部署和故障转移）。

Cloudflare 的边缘网络把这些能力组合在一起，配合 Hono 提供了一个从代码到部署到低运维的完整方案。这不是唯一选择，但对独立开发者和小团队来说，它是一个值得认真评估的起点。

至此，「Web 服务基础与运行时原理」分组完成。下一篇开始进入「Hono 快速上手」，你会把前面建立的概念落地到实际的代码和项目中。

10-API网关、反向代理与边缘网络 - Hono AI 项目知识体系 - AI共学社