Node.js 到 Go：夸克资源搜索站(pansou.de)的架构重构实践

爱意满满的作品展示区。

背景

PanSou 盘搜得是一个夸克网盘资源聚合搜索平台，上线以来月活用户超过 200 万，索引资源量达 800 万+条。随着用户规模增长，原有的 Node.js 技术栈逐渐暴露出一些问题，最终决定进行一次彻底的架构重构。

旧架构的痛点

初版架构采用 Next.js + BullMQ + PostgreSQL + Redis 的组合：

Next.js 负责前端渲染和 API Routes
BullMQ 处理异步任务（资源转存、定时清理）
PostgreSQL 存储资源索引和转存记录
Redis 做查询缓存和任务队列

这套架构在早期运行良好，但随着流量增长，问题逐渐显现：

1. 并发处理能力受限

Node.js 单线程模型在高并发场景下压力明显。搜索请求需要调用上游 API 、数据库查询、Redis 缓存，在流量高峰期 P99 响应时间经常突破 2 秒。

2. 资源占用偏高

Next.js 进程内存占用大，加上 BullMQ Worker 进程，整体资源消耗不低。在用户量翻倍后，服务器成本压力开始显现。

3. 维护复杂度上升

API Routes 、Service 层、Worker 任务散落在不同模块，依赖链路长，排查问题需要跨多个层级。

4. 定时任务可靠性不足

BullMQ 虽然成熟，但在资源清理这种长周期任务上偶尔会出现任务堆积，需要人工介入重启。

重构方案

核心思路是前后端彻底分离，业务逻辑下沉到性能更强的 Go 服务。

新架构设计

用户请求
    ↓
宝塔 Nginx （反代）
    ↓
Docker 内部 Nginx
    ├─ /api/v1/*  → Go API (8080)
    └─ /*         → Next.js (3000)
         ↓
    PostgreSQL + Redis
         ↓
    Go Worker (定时清理)

职责划分：

Next.js：纯前端渲染 + SSR SEO 落地页，不再承担任何业务逻辑
Go API：搜索、转存、账号管理、管理后台所有接口
Go Worker：过期资源清理、每日计数重置
Nginx：请求路由，未来可扩展灰度发布、限流等能力

关键技术点

1. 流式搜索优化
搜索请求需要调用上游 PanSou API 并实时检测链接有效性。Go 的协程模型天然适合这种场景：

用 Goroutine 并发调用多个上游接口
Redis Stream 实现搜索结果的流式推送
检测到 N 条有效链接后提前终止，避免无效等待

实测搜索 P99 响应时间从 2 秒降到不到 1 秒。

2. 请求合并防穿透
热门关键词短时间内可能被重复搜索。通过分布式锁实现请求合并：

相同查询参数的请求只触发一次上游调用
后续请求直接订阅 Redis Stream 获取结果
显著降低了上游 API 压力和缓存穿透风险

3. 双写模型解决 SEO 问题
资源转存后生成的落地页对 SEO 至关重要，但分享链接 15 分钟后会过期。采用双写策略：

temporary_shares 表：存储短期分享数据（ 15 分钟 TTL ）
resources 表：永久保留 SEO 数据（ slug/title/description ）
Worker 清理时只删网盘文件和临时表，SEO 落地页始终可访问

用户访问过期资源时显示"资源已过期，请重新搜索"，既保留了 SEO 价值，又不影响体验。

4. 内部网络优化
Next.js SSR 渲染 SEO 落地页时需要调用 Go API 获取数据。通过 Docker 内网直连：

// SSR 走内网
const INTERNAL_API_URL = 'http://go-api:8080';

省去了公网绕行的延迟，SSR 响应速度提升 50-200ms 。

迁移策略

采用灰度发布 + 双运行的策略，而非一刀切：

阶段 1：Go API 上线，Node.js API 继续服务
阶段 2：通过 Cookie 或 IP 规则切换 10%流量到 Go
阶段 3：观察监控指标（错误率、响应时间、转存成功率）
阶段 4：逐步扩大到 50% → 100%
阶段 5：下线 Node.js API ，清理废弃代码

全程保留回滚能力，任何阶段出现问题都能快速切回。

效果

重构上线后，核心指标全面改善：

指标	重构前	重构后	提升
搜索 P99 响应时间	~2s	<1s	50%+
服务器内存占用	-	↓30%+	显著降低
转存成功率	~90%	>95%	更稳定
并发处理能力	受限	线性扩展	质变