从 CDN 到 ESA：构建现代多应用平台的“边缘网关”重构实践

1. 序言：为什么我们要重构？

在早期的项目开发中，我们使用了最传统的“OSS 静态托管 + 传统 CDN 加速”模式。虽然能够支撑起步，但随着平台向 MPA（多页面应用） 架构演进，集成多个独立子项目时，传统 CDN 的局限性逐渐显现：

• 统一管理 SSL 证书： ESA 自动管理 SSL 证书，无需手动配置。并且提供免费的泛域名证书。
• 路由逻辑僵化：无法优雅地处理子目录下不同单页应用（SPA）的内部路由。
• 配置割裂：DNS、CDN、安全防护散落在多个控制台，管理成本极高。
• 同源策略瓶颈：跨子域名导致 LocalStorage 共享困难，用户登录态同步逻辑复杂。

于是，我们将架构转向了 ESA (Edge Service Anywhere)。它不再只是一个缓存加速工具，而是一个**“可编程的边缘网关”**。

---

2. 核心挑战：在同一域名下驱动“门户”与“子应用”

我们的架构场景非常具有代表性：

1. 根目录：运行着一个基于静态框架的内容门户（每一处路径如 /docs/ 都需自动对应 index.html）。
2. /sub-app/ 路径：运行着 React 编写的独立业务应用（需要 SPA 路由支持，即访问 /sub-app/order/123 实际上要读取 /sub-app/index.html）。
3. 同源策略：所有内容必须在同一个域名（erdianzhang.cn）下，以确保主入口与子应用之间能顺畅共享 LocalStorage 中的用户 Token。

---

3. ESA 迁移实战：架构演进的关键路径

3.1 DNS 接管：从 CNAME 到 NS 模式

我们将域名彻底接入 ESA 的 NS 模式，由其作为 DNS 调度中心。

• 核心操作：在域名注册商处将 DNS 服务器修改为 ESA 提供的地址。从此，域名解析、SSL 证书自动管理、边缘规则引擎都在一个后台完成闭环。

3.2 解决“0 字节下载”：回源 HOST 的陷阱

迁移初期，访问路径时常触发 0 字节文件下载或报错。这是由于 OSS 私有桶的安全机制导致的：

• 问题根源：ESA 默认的“跟随请求 HOST”会导致 OSS 无法通过请求头中的自定义域名识别对应的存储桶。
• 解决方案：在 ESA 配置中，将 “回源 HOST” 从“跟随请求 HOST”改为 “跟随源站域名”。ESA 随后会自动将 Host 改写为 OSS 的内部域名，确保鉴权成功。

3.3 转换规则：精准排除静态资源

为了支持子应用的内部路由，我们需要把非文件请求重写到入口 index.html，但必须精准避开 .js 或 .png 等静态资源。我们采用了逻辑组合法：

• 匹配条件：
  • URI 路径 开始于 /sub-app/
  • And URI 路径 不开始于 /sub-app/assets/
• 执行动作：
  • 重写 URL 路径到：/sub-app/index.html
• 逻辑价值：除了 assets 文件夹内的真实物理资源请求，其余路径请求全权交给前端路由处理，实现了完美的无感刷新。

---

4. 后端演进：Redis 核心化的无状态集群

在分发层进化的同时，后端服务也完成了 “去状态化” 重构：

• 接入与逻辑分离：网关层（NLB）只负责维持海量长连接，业务逻辑层通过 Redis Pub/Sub 进行指令广播。（注：关于此处为何后来转向了房间粘滞架构，请参考最新篇：为什么我最终放弃了分布式 Pub/Sub，选择了房间粘滞（Affinity））
• 状态全部 Redis 化：应用进程内部不存储任何业务状态。所有实时数据（会话状态、操作记录、队列）全在 Redis 中完成同步。
• SSL 卸载：利用 ESA 的边缘节点处理 SSL 握手（支持 HTTP/3），回源到 NLB 时走纯净的内网协议，极大减轻了业务服务器的 CPU 压力。
• 后续优化建议：关于分布式转发与房间粘滞的深度权衡，可以移步阅读 这篇文章。

---

5. 经验总结与架构思考

1. 同源是平台化的基石：坚持在一个域名下通过路径分发管理多应用。这不仅是为了部署方便，更是为了让 LocalStorage 的共享变得天然、透明，彻底规避跨域登录的复杂性。
2. MPA 模式的稳定性：对于复杂应用，通过路径跳转（MPA）比全量 SPA 架构更稳健，尤其在处理内存回收和环境隔离方面具有天然优势。
3. 缓存清理是第一准则：在配置边缘规则时，如果发现逻辑不生效，第一时间执行 “全量清理缓存”。
4. 边缘网关的价值：ESA 的核心意义在于它将“路由重写”、“SSL 卸载”和“安全防护”从业务代码中剥离，下沉到了离用户最近的节点。

架构的终局是“简单”。通过 ESA + NLB + Go + Redis，我们构建了一套既能承载海量并发，又具备极致开发体验的多应用集成平台。

---

兔特科技架构组
2026.03.06