1. 为什么选择Next.js和Vercel Edge做短链服务

上周我帮一个跨境电商客户紧急部署短链服务时，从零开始到全球可用只用了63分钟。这种效率在传统架构下根本不可能实现，关键就在于Next.js的API Routes和Vercel Edge Functions的完美配合。

短链服务的核心诉求很简单：把长URL转换成短字符串，访问时快速跳转。但要做到生产级可用，需要解决几个关键问题：

• 毫秒级响应（直接影响转化率）
• 全球低延迟访问（用户可能来自任何地区）
• 高并发承载（促销活动时流量激增）
• 简单易维护（小团队也能快速迭代）

传统方案要么用Nginx重写规则（难维护），要么上K8s集群（成本高）。而Next.js + Vercel Edge的组合给出了全新解法：用Edge Runtime在全球31个边缘节点运行业务逻辑，请求就近处理，数据库用Vercel的Edge Config实现全局同步。实测新加坡用户访问延迟仅23ms，比传统中心化架构快8倍。

2. 核心架构设计

2.1 技术栈选型分析

先看完整技术栈：

• 前端：Next.js 14（App Router）
• 计算层：Vercel Edge Functions
• 存储层：Vercel Edge Config + PostgreSQL（存原始URL）
• 部署：Vercel全球边缘网络

这个组合的独特优势在于：

1. 零配置全球化：代码自动部署到所有边缘节点，无需操心CDN配置
2. 冷启动<5ms：Edge Functions使用V8隔离而非容器，比传统Serverless快10倍
3. 数据一致性：Edge Config的变更能在300ms内同步到所有节点
4. 成本可控：前10万次/天的请求完全免费

重要提示：Edge Config适合存储小型配置数据（最大8KB/条），不适合存用户数据。我们只用它存短码映射，原始URL仍存PostgreSQL。

2.2 数据流设计

当用户访问https://sl.cn/abc123时：

1. 请求被路由到最近的边缘节点（如东京POP）
2. Edge Function查询本地Edge Config获取abc123对应的原始URL ID
3. 用ID向中心数据库请求完整URL（包含UTM参数等元数据）
4. 返回302重定向响应

这种分层存储设计既保证了速度（Edge Config读取仅1ms），又保留了灵活性（可随时修改原始URL）。实测在100QPS压力下，P99延迟始终低于50ms。

3. 关键实现步骤

3.1 初始化项目

npx create-next-app@latest shortlink-service --typescript --eslint cd shortlink-service npx shadcn-ui@latest init # 可选，添加漂亮UI组件

项目结构重点：

/app /api/redirect/route.ts # Edge Function处理跳转 /api/create/route.ts # 创建短链 /edge-config # 存储映射关系

3.2 跳转逻辑实现

在app/api/redirect/[slug]/route.ts中：

import { NextResponse } from 'next/server' import { get } from '@vercel/edge-config' export const runtime = 'edge' export async function GET( request: Request, { params }: { params: { slug: string } } ) { // 从Edge Config查询短码 const urlId = await get(params.slug) if (!urlId) return NextResponse.json({ error: 'Not Found' }, { status: 404 }) // 从中心数据库获取完整URL const { url } = await fetch(`https://db.example.com/urls/${urlId}`) .then(res => res.json()) return NextResponse.redirect(url, 302) }

3.3 短码生成算法

短码需要满足：

• 抗碰撞（不同长URL生成不同短码）
• 可解码（不含易混淆字符如0/O）
• 长度可控（6-8字符为宜）

推荐使用nanoid：

import { customAlphabet } from 'nanoid' const alphabet = '346789ABCDEFGHJKLMNPQRTUVWXY' const generateSlug = customAlphabet(alphabet, 6)

实测在100万条记录下，6位长度的碰撞概率仅0.0001%。如果担心冲突，可以先查询db确认不存在再写入。

4. 性能优化技巧

4.1 Edge Config缓存策略

虽然Edge Config本身很快，但频繁读取仍有开销。利用Next.js的静态路由优化：

export const dynamic = 'force-static' export const revalidate = 3600 // 1小时缓存

这样Vercel会在边缘节点缓存响应，大幅减少Config读取次数。当Config更新时，通过webhook主动清除缓存。

4.2 数据库连接池

中心数据库连接是性能瓶颈，推荐：

1. 使用Vercel Postgres（自动管理连接池）
2. 或配置PgBouncer（连接复用）
3. 为Edge Function设置单独用户（避免连接数耗尽）

4.3 监控指标埋点

在Vercel仪表板外，建议添加：

• 每个地域的延迟热力图（用Cloudflare Workers收集）
• 短链点击的UTM参数分析（存ClickHouse）
• 异常请求监控（如频繁访问不存在的短码）

5. 真实场景踩坑记录

5.1 冷启动时延波动

虽然Edge Functions冷启动很快，但某些地区的初始化可能达到100ms。解决方案：

• 每天定时访问核心短链保持热启动
• 对VIP短链启用Vercel的Early Hints

5.2 短码失效问题

Edge Config的最终一致性可能导致短时间内的数据不一致。应对措施：

• 新建短链时返回两个备选短码
• 重要链接配置fallback URL（通过Cookie判断）

5.3 恶意刷量防护

短链服务容易被滥用，必须添加：

• 每个IP每分钟限流100次
• 可疑短码自动验证（如随机访问/abc123时弹出验证码）
• 敏感词过滤（防止生成违规短链）

6. 高级功能扩展

6.1 动态短链

在跳转时注入参数：

const urlWithParams = new URL(originalUrl) urlWithParams.searchParams.set('ref', 'edge_redirect') return NextResponse.redirect(urlWithParams.toString())

6.2 A/B测试支持

在Edge Config存储多个版本：

{ "product-link": { "A": "https://example.com/v1", "B": "https://example.com/v2", "ratio": 0.5 } }

6.3 数据统计方案

推荐架构：

1. 用Edge Function发送点击事件到Kafka
2. Flink实时计算点击量
3. 结果存Redis供实时查询
4. 离线数仓用Hive做深度分析

这套系统上线三个月后，日均处理短链跳转1200万次，运维成本仅为传统方案的1/5。最让我意外的是Edge Functions的稳定性——即使在黑色星期五的流量高峰，错误率始终保持在0.001%以下。对于需要快速验证的业务场景，这可能是目前最理想的短链实现方案。