9.6 边缘计算模型
一句话
边缘计算把 “几毫秒就能做完的决策” 放到离用户最近的地方；但它有三条硬约束——无状态、有时限、存储小——凡是超出这三条的逻辑，都应该放回中心。
三种模型：从 “改请求” 到 “跑代码”
| 模型 | 能力 | 典型用途 | 约束 |
|---|---|---|---|
| 边缘函数（请求/响应钩子） | 改写请求、生成响应、鉴权、A/B | 重写 URL、灰度分流、JWT 校验、返回 302 | CPU 时间毫秒–几十毫秒、内存几十 MB |
| 边缘 KV / 配置 | 读小数据（配置、名单、路由表） | 灰度名单、租户路由、机器人名单 | 最终一致，写入延迟高 |
| 边缘容器 | 跑较完整的服务 | 图片处理、轻量 SSR、边缘网关 | 冷启动更慢、成本更高、运维更接近中心 |
选择顺序：能用配置/规则解决的，不要写函数；能写函数的，不要上容器。
四条硬约束，决定了 “什么能放边缘”
| 约束 | 具体限制 | 越界的后果 |
|---|---|---|
| 无状态 | 不保证本地磁盘/内存持久化，实例随时换 | 把会话放边缘 → 用户随机掉线 |
| 时限 | 单次执行有 CPU/墙钟上限（常见几十毫秒–几秒） | 重计算被中断，返回 5xx |
| 存储小 | KV 有大小与读写频率限制 | 当数据库用 → 延迟飙升、写入丢失 |
| 一致性弱 | 配置与 KV 是最终一致（秒级传播） | 用边缘做过期判断 → 放行了已封禁用户 |
一条判据：这段逻辑在 “不知道其他节点发生了什么” 的前提下，还能得出正确结论吗？ 不能，就别放边缘。
适合 / 不适合
| 适合（毫秒级、无状态、读多） | 不适合（有状态、重计算、强一致） |
|---|---|
| URL 重写、A/B 分流、灰度 | 订单创建、库存扣减 |
| JWT/签名校验、bot 名单 | 复杂风控（需要全量特征） |
| 图片/视频的缩放裁剪 | 视频转码（CPU 与时长都不够） |
| 边缘 SSR / 静态拼装 | 依赖数据库事务的渲染 |
| 地理位置路由（按国家/城市） | 需要精确全局计数（限购、防刷） |
一致性与运维：两个被低估的成本
| 问题 | 现实 | 应对 |
|---|---|---|
| 配置传播延迟 | 改一条规则，全球节点几秒–几分钟才一致 | 关键规则要有版本号，客户端可回退 |
| 调试困难 | 无法 SSH，日志分散在几百个节点 | 依赖 trace_id + 采样日志 + 本地模拟器 |
| 部署风险 | 一次错误规则影响全球 | 先灰度 1% 节点，再全量；保留一键回滚 |
| 计费复杂 | 按请求/CPU 时间/流量组合计费 | 先算 “每万次请求成本”，再对比中心处理 |
一个典型的组合：在边缘做 “鉴权 + 分流”，在中心做 “业务”
用户 → 边缘（验签、判灰度、重写 URL、命中缓存则直接返回）
├─ 命中：直接响应（不经过中心）
└─ 未命中：带身份头回源 → 中心做业务与数据
这样边缘只承担 “几毫秒的判定”，不碰数据；中心仍是唯一真相。边缘负责快，中心负责对。
反模式
| 反模式 | 后果 |
|---|---|
| 在边缘做完整业务逻辑 | 一致性、调试、部署三重成本，且难以回滚 |
| 把边缘 KV 当数据库 | 写入受限、延迟高、数据丢失 |
| 边缘做重计算（转码、加密大包） | 超时被中断，成本反而更高 |
| 忽略冷启动 | 低频路径首次请求慢几百毫秒 |
| 一套规则全量直推 | 一次错误规则全球生效 |
| 不做本地模拟 | 只能上线后才发现语法/权限错误 |
三条铁律
🔑 边缘只做 “无状态、毫秒级、读多写少” 的判定；有状态与强一致的逻辑留在中心。
🔑 配置即代码：版本化、灰度、一键回滚，缺一不可。
🔑 先算成本再上边缘：请求数 × 单价 + 回源流量，往往不比中心便宜。
自检
Q1 团队想把 “库存扣减” 放到边缘函数，为什么不可行？
▸ 答案：因为库存扣减需要强一致的读-改-写与全局计数，而边缘是无状态、最终一致、且各节点互不可见。放在边缘会出现超卖：两个节点各自看到 “还有 1 件”，各扣一次。正确做法是边缘只做 “预校验/限流/排队”，真正的扣减回到中心（见 67.6 秒杀与抢购 (库存 / 限购 / 防刷 / 削峰)）。
Q2 为什么 “JWT 校验” 适合放边缘，而 “封禁名单” 要谨慎？
▸ 答案：JWT 校验是无状态的本地计算（验签 + 过期时间），边缘完全能独立完成，收益是把无效请求挡在边缘。封禁名单依赖 “最新状态”，而边缘 KV 是最终一致的——刚封禁的用户可能在几秒内仍被放行。若必须放边缘，要接受这个窗口，或在中心再做一次校验。
Q3 边缘函数常见的时间限制会导致什么设计变化？
▸ 答案：把 “长任务” 拆成 “短判定 + 异步”：边缘只做 “要不要处理、转发到哪”，重活交给中心或异步队列。同时要设超时与降级（超时就直接回源，而不是返回错误），否则边缘的抖动会变成用户的 5xx。
Q4 怎么验证一条边缘规则是安全的？
▸ 答案：四步：① 本地模拟（多数厂商提供 CLI/模拟器）跑通语法与匹配；② 灰度 1% 节点或 1% 流量，观察错误率与回源率；③ 准备好 一键回滚（规则版本化）；④ 观察 配置传播 是否完成（不同地域抽样验证）。跳过第 ② 步的团队，通常会在第一次全量时学到同一个教训。
Q5 什么情况下 “边缘计算” 反而更贵？
▸ 答案：三种：① 请求量大但命中率低，每次都要回源，边缘只增加一跳；② 逻辑重（CPU 时间超限被中断重试），单位成本高于中心；③ 运维成本（调试、灰度、回滚、观测）没被计入。判断方法：算 “每万次请求的边缘费用 + 回源流量 + 人力”，与 “中心扩容成本” 对比，而不是只看单价表。
跨篇相关：边缘缓存与命中率见 9.1 边缘缓存原理；回源策略见 9.2 回源策略与回源率；缓存键与越权风险见 9.3 缓存键设计；动态内容的路径优化见 9.5 动态加速；CDN 的整体组成见 9.0 CDN 全景：它到底是什么；无服务器形态的取舍见 33.3 Serverless / FaaS；库存与防刷见 67.6 秒杀与抢购 (库存 / 限购 / 防刷 / 削峰)。