边缘计算

边缘运行时（Edge runtimes）将逻辑部署得更靠近用户——具备严格的 CPU/执行时间限制、与完整 Node 环境不同的 API 集，以及必需的租户隔离（tenant isolation）能力。

何时提供该工作流

触发条件：

• 在 CDN 层执行鉴权（Auth）、重定向或个性化处理
• 在边缘层执行 HTML 重写、A/B 分组分配或机器人缓解（bot mitigation）
• 对读多写少（read-heavy）路径有全局延迟 SLO 要求

初始建议方案：

采用六个阶段：（1）工作负载适配性评估，（2）边缘与源站职责划分，（3）数据与状态管理，（4）安全与租户隔离，（5）资源限制与成本分析，（6）测试与灰度发布。需明确所选平台（如 Workers、Lambda@Edge、Fastly Compute 等）。

阶段 1：工作负载适配性评估

目标：优先选择短时、低 CPU 占用、以单次请求为作用域的工作负载——不适用于长时间运行任务或需缓冲超大请求体的场景。

退出条件：明确列出仍须保留在源站（origin）执行的内容（例如重型 SSR、大文件上传等）。

阶段 2：边缘与源站职责划分

目标：清晰定义各组件的执行位置：地理位置（geo）请求头处理、重定向逻辑、缓存键（cache key）生成规则、A/B 分桶（bucketing）策略、部分 HTML 注入等。

实践建议

• 明确记录 Vary 响应头及 Cookie 行为，避免因缓存导致个性化内容错误泄露

阶段 3：数据与状态管理

目标：若使用边缘 KV、Durable Objects 或区域化存储（regional stores），需明确定义状态一致性模型（最终一致性 vs 强一致性），并评估往返源站的调用频次。

阶段 4：安全与租户隔离

目标：在边缘层完成 JWT/session 验证；实现租户间严格隔离；严禁将密钥等敏感信息嵌入客户端可访问的部署包中。

阶段 5：资源限制与成本分析

目标：确认实际可用的挂钟时间（wall-clock）CPU 限制、单请求大小上限、出向流量（egress）计费模型；设计优雅降级机制或回退至源站的容错路径。

阶段 6：测试与灰度发布

目标：按地域或 PoP（Point of Presence）进行金丝雀（canary）发布；从多个地理位置运行合成监控（synthetics）；对比 p95 延迟指标与纯源站路径的表现差异。

最终评审检查清单

• 工作负载符合边缘运行时约束条件
• 边缘与源站的职责划分已明确文档化
• 状态管理及一致性策略已清晰定义
• 多租户安全机制已完成评审
• 资源限制、成本模型及降级/回退方案已文档化
• 已完成多地域验证

高效提供指导的实用建议

• 边缘运行时与完整 Node 环境存在显著差异——请务必核实平台支持的 API（如 fs、streams、crypto 等）。
• 仔细阅读所选平台关于冷启动（cold-start）行为与隔离模型（isolate model）的官方文档。

应对偏差情况的策略

• 混合架构：仅在边缘处理请求头与缓存逻辑；高计算密度任务保留在源站执行。