“边缘计算”这个词经常被描述成“把服务器搬到用户旁边”。这只说对了一半。另一半是：你会失去很多在中心云里理所当然的东西。
一、边缘运行时给你的，和拿走的
典型边缘函数提供这些：
- 全球或区域级的就近接入点
- 基于请求触发的执行模型
- 内置的 KV、对象存储、缓存
- 与 CDN 静态资源天然一体
同时它拿走这些：
- 常驻进程与本地内存状态
- 长事务、长连接池
- 任意文件系统写入
- 任意 npm 原生模块（很多运行时只支持部分 API）
- 宽裕的 CPU 时间（常见是几十到几百毫秒）
这不是“缩水版服务器”，而是一种函数化的请求处理模型。把它当服务器用，一定会踩坑。
二、三个必须重新设计的点
1. 状态放在哪里
边缘节点之间不共享内存。你需要把状态放进 KV、数据库或对象存储，并接受：
- 写入不是全局立即可见（最终一致，常见秒级）
- 没有跨键事务，读改写存在竞态
- 列表、分页要靠索引键自己维护
一个典型问题是“先读索引、追加一条、再写回”。并发下两条请求可能互相覆盖。解决办法通常是：要么接受偶尔丢一条，要么改用能原子追加的存储，要么把写操作收敛到单一区域。
2. CPU 时间是硬预算
边缘函数通常按 CPU 时间计费并设上限。一个不小心写出的 O(n²) 循环、一次同步的大 JSON 解析、一张大图的重编码，都可能超时。
实践上要：分页读取、限制单次处理条数、把重活放回源站或异步任务。
3. 冷启动与包体积
边缘节点分布广，冷启动概率高。包越大，启动越慢。控制依赖数量、避免在模块顶层做大初始化，是很实际的优化。
三、什么适合放边缘，什么不适合
适合：鉴权与重定向、A/B 分流、个性化片段、图片/HTML 缓存、API 聚合、地理路由、简单的 CRUD。
不适合：长任务、批量数据迁移、复杂事务、需要强一致的计数、重型图像/视频处理。
四、一个真实的取舍
以博客系统为例：把文章读取放在边缘，命中 KV 时延迟很低；但“发布文章”要同时更新正文、索引、分类计数、标签计数，这是典型的多键写。放在边缘就必须接受竞态，或者退化为“单写者”模型。
我们的选择是：读在边缘、写也尽量在边缘，但对索引采用整表读改写 + 冲突可容忍的策略，并在后台提供“重建索引”的兜底。这不是最优解，但在“个人站点、写少读多”的场景里是合理的。
结语
边缘计算的价值不在于“便宜”，而在于把延迟和可用性问题前移。接受它的约束，才能用好它；否则只是把中心云的复杂度搬到了更难调试的地方。
评论 (0)