社区讨论LinuxDo 最新
从 Node.js 到 Go：夸克资源搜索站( pansou.de )的架构重构实践
背景 PanSou盘搜得 是一个夸克网盘资源聚合搜索平台，上线以来月活用户超过200万，索引资源量达800万+条。随着用户规模增长，原有的 Node.js 技术栈逐渐暴露出一些问题，最终决定进行一次彻底的架构重构。 旧架构的痛点 初版架构采用 Next.js + BullMQ + PostgreSQL + Redis 的组合： Next.js 负责前端渲染和 API Routes BullMQ 处理异步任务（资源转存、定时清理） PostgreSQL 存储资源索引和转存记录 Redis 做查询缓存和任务队列 这套…
内容摘要
作者：#LaoMa
板块：#开发调优
背景
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：过期资源清
资讯来源
LinuxDo