Expert guidance for designing …

# Cloudflare Workers 三层边缘服务架构设计

一、整体架构分层

三层职责拆分：

• L1 限流层：入口网关，前置所有流量
• L2 鉴权层：API Key / JWT 验证，按渠道区分（App / Web / 合作伙伴）
• L3 图片压缩层：仅图片资源路由触发，降低源站带宽

架构示意：

```

用户请求 → CF CDN → Worker入口(路由分发)

├─ 静态图片 → 图片压缩Worker → Images/R2

├─ API请求 → 鉴权Worker → 限流Worker → 后端源站

└─ 非法请求 → 直接边缘返回429/401

```

二、请求路由方案

• 路由匹配策略：用 wrangler.toml 配置多 Worker 路由，图片走 /static/img/*，API 走 /api/*
• 单Worker内分发：入口 Worker 根据 pathname + method 分发到 Service Bindings（Worker 间通信走内网，零延迟损耗、不计请求数）
• Host 维度：多区域站点（如美/欧站）用不同域名绑定同一 Worker，通过 header 注入区域标识

三、限流层设计

• 数据存储：Cloudflare KV 不适合高频计数（有最终一致性），推荐 Durable Objects（强一致计数器）+ Cache API 做本地缓存兜底
• 限流维度：IP + API Key + 用户 ID 三维度，多级阈值
• 算法：滑动窗口（适合防突发），配合指数退避提示
• 降级策略：DO 不可用时放行并打日志，避免限流组件故障拖垮全站

四、鉴权层设计

• JWT 方案：边缘校验签名（用 Web Crypto API，不引入重型库），密钥存 Workers Secrets
• API Key：存 KV（读多写少场景），Worker 内缓存热数据
• 跨境要点：把地区合规检查（如某些市场商品白名单）挂在鉴权后置逻辑

五、图片压缩层设计

• 优先用托管服务：Cloudflare Images / Image Resizing，按需裁剪 + 自动 WebP/AVIF，减少自建复杂度
• 自建方案：R2 存储 + Worker 拉取 + wasmsharp（wasm 版压缩库），按 Accept 头协商格式
• 缓存策略：压缩结果按 “原图URL+尺寸+格式” 生成缓存键，写入 Cache API，TTL 设长（图片变更少）

六、可观测性与成本控制

• 日志：Workers Analytics Engine 采样埋点，对接外部监控（如 Grafana Cloud 免费层）
• 成本要点：Workers 免费版每日请求数有限，生产建议付费版；Durable Objects 计费按请求+时长，限流计数注意批量合并写入
• 灰度发布：利用 Workers 的版本管理 +渐进式部署，先切 1-5% 流量验证