全栈开发的未来：边缘计算

边缘计算 vs 传统云计算

传统全栈应用的架构是：用户 -> CDN（静态资源）-> 负载均衡器 -> 应用服务器（us-east-1）-> 数据库（us-east-1）。如果你的用户在东京，而服务器在弗吉尼亚，请求往返需要 200ms+ 的网络延迟。

边缘计算的思路是：把计算从少数几个中心机房搬到遍布全球的数百个边缘节点上。代码运行在离用户最近的地方，而不是离服务器最近的地方。结果是：全球各地的用户都能获得接近本地访问的响应速度。

// 传统架构：用户请求到服务器，延迟高
// 东京用户 -> 200ms -> 弗吉尼亚服务器 -> 20ms -> 数据库 -> 200ms -> 用户
// 总延迟: ~420ms

// 边缘架构：代码运行在离用户最近的节点
// 东京用户 -> 5ms -> 东京边缘节点 -> 30ms -> 就近数据库 -> 5ms -> 用户
// 总延迟: ~40ms

Vercel Edge Functions

Vercel 的 Edge Functions 基于 V8 Isolates 运行，而不是传统的容器或虚拟机。这意味着冷启动时间极短（通常 < 50ms），可以在全球每个请求到达时动态决定在哪个节点执行：

// app/api/hello/route.ts
import { NextRequest, NextResponse } from 'next/server';

export const runtime = 'edge';

export async function GET(request: NextRequest) {
  // 获取用户的地理位置信息（由 Vercel 自动注入）
  const country = request.geo?.country ?? 'Unknown';
  const city = request.geo?.city ?? 'Unknown';

  return NextResponse.json({
    message: `Hello from ${city}, ${country}!`,
    timestamp: Date.now(),
  });
}

Edge Functions 特别适合：A/B 测试、地理位置相关的内容、API 鉴权、URL 重定向、动态 OG 图片生成等场景。

Cloudflare Workers

Cloudflare Workers 是边缘计算的另一个主流选择。它的优势在于更广泛的全球节点（超过 300 个），以及完整的生态：

// Cloudflare Worker 示例
export default {
  async fetch(request: Request, env: Env, ctx: ExecutionContext): Promise<Response> {
    // 从 KV 存储中读取数据
    const cached = await env.MY_KV.get(request.url);
    if (cached) {
      return new Response(cached, {
        headers: { 'Content-Type': 'application/json' },
      });
    }

    // 从源站获取数据
    const data = await fetch('https://api.example.com/data');
    const result = await data.json();

    // 缓存到 KV
    ctx.waitUntil(env.MY_KV.put(request.url, JSON.stringify(result)));

    return Response.json(result);
  },
};

边缘数据库的崛起

边缘计算的一个关键挑战是数据访问。如果代码运行在边缘，但数据库还在 us-east-1，那延迟优势就大打折扣了。新一代的边缘数据库解决了这个问题：

• Turso：基于 libSQL（SQLite 的分支），数据分布在多个边缘节点，支持多主写入
• PlanetScale：基于 Vitess（MySQL 兼容），提供全球分布式的读写能力
• Cloudflare D1：Cloudflare 自己的边缘 SQLite 数据库，与 Workers 深度集成
• Neon：Serverless PostgreSQL，支持分支数据库（类似 Git 分支）

// 使用 Turso 在边缘节点查询
import { createClient } from '@libsql/client';

const client = createClient({
  url: process.env.TURSO_DATABASE_URL!,
  authToken: process.env.TURSO_AUTH_TOKEN!,
});

// 查询自动路由到最近的边缘数据库副本
const posts = await client.execute(
  'SELECT * FROM posts WHERE status = ? ORDER BY created_at DESC LIMIT 10',
  ['published']
);

边缘计算的局限

边缘计算不是银弹，理解它的局限性才能做出正确的架构决策：

• 运行时限制：Edge Functions 通常有执行时间限制（Vercel: 30s，Cloudflare Workers: 30s CPU）。不适合长时间运行的任务
• Node.js API 不完整：Edge Runtime 不支持 fs、net 等原生模块。很多 npm 包无法直接使用
• 冷启动：虽然 V8 Isolates 的冷启动比容器快，但仍然存在。对于需要极低延迟的场景需要关注
• 调试困难：分布式调试比单一服务器复杂得多。需要搭配完善的日志和追踪系统
• 成本模型：按请求量计费，高流量项目的成本可能超过传统服务器

什么时候不该用边缘计算

如果你在做一个面向中国用户的 SaaS 产品，把所有计算放在边缘节点上可能不如在华东部署一个传统服务器集群来得实际。

不适用边缘计算的场景：

• WebSocket 长连接（边缘节点连接可能不稳定）
• 大型文件处理（视频转码、图片批量处理）
• 需要强一致性的事务操作
• 对延迟不敏感的批处理任务

总结

边缘计算不是要取代传统云计算，而是提供了一种新的架构选择。我的建议是：把不需要完整 Node.js 运行时的逻辑（鉴权、重定向、A/B 测试、轻量 API）迁移到边缘，把需要数据库事务、文件处理、长连接的任务留在传统服务器上。这种"边缘 + 核心"的混合架构，可能是未来 3-5 年全栈开发的主流范式。

---