搞服务器运维搞到第四十三篇今天想聊聊一个看起来不起眼、但在联调阶段能省下大量时间的活儿——用 Node 搭一个“伪请求”pseudo http服务。我们内部有个后台系统叫“东方仙盟”前后端小团队联调时最烦的就是后端接口还没就绪前端只能干等。干脆在测试服务器上用 Node 起一个模拟接口服务把接口的返回、延迟、异常全部伪装出来前端照常发请求后端后面再接真逻辑。这篇就把这个方案的落地过程、踩坑点、以及服务器端环境配置的注意项完整梳理一遍给同样被联调卡住的朋友做个参考。1. 伪请求到底解决什么问题1.1 前后端联调的真实痛点先说场景。东方仙盟这个项目是老业务系统改造页面多、接口多后端团队在排期上又是分批交付接口。前端把静态页面都画完了结果发现接口联调才是大头接口没出页面上的表格、表单、图表全都只能摆 UI 没法验证交互。以前的做法是前端自己写死一份 json 数据塞进代码里跑通界面但问题很明显——写死的数据一旦要换场景就得到处改代码而且数据是假的这件事儿没法让后端知道接口长什么样。伪请求服务解决的就是这个“假数据不统一、不可切换、不可回放”的问题。你在服务器上起一个独立的小服务监听固定端口把接口路径、请求方式、返回结构全部约定好。前端代码里只需要把请求地址指向这个 mock 服务剩下的联调工作就变成了“等后端把接口按约定实现了前端把代理地址切回后端”这么简单。说白了就是把后端接口的“合同文本”提前变成“能交互的原型DEMO”。我之所以选择 Node 而不是其他方案的另一个原因是团队本身是前端团队Node 技能是现成的。让前端去维护一个 mock 服务完全没有学习成本对后端来说mock 服务的路径和参数规范又可以在联调之前就以代码评审的形式检查一遍提前消灭掉参数不一致这类低级问题。1.2 为什么不直接靠 Swagger 或 json-server可能有人会说这类问题用现成工具不就行了比如 Swagger Mock、json-server或者直接用 YApi 这类平台。用下来我的体会是现成工具适合“快速演示”但放进正式运维环境就有点力不从心。Swagger 生成的 mock 只能按字段类型随机填值没法精细控制“这个接口在请求头缺参数的时候返回 401”这种业务化行为json-server 更偏向纯 CRUD 场景遇到要模拟一个多步骤流程接口、要读文件、要对接 Redis 之类的需求就捉襟见肘了。自建 Node 伪请求服务最大的好处是把控制权完全握在自己手里。延迟多少毫秒、返回什么错误码、是否随机抽风、是否记录日志、是否支持按请求参数返回不同数据这些全都能写死。虽然前期搭建多花了小半天时间但后续每一次联调改动都是分钟级的这个成本很快就能赚回来。如果让我对比一下方案上手速度可控程度适合场景json-server快低简单 CRUD 演示Swagger Mock快中按 Schema 生成假数据YApi中中团队协作管理自建 Node 伪请求服务中高复杂业务流程联调、日志回放、异常注入东方仙盟这个项目选择自建还有一个原因是内部有一条安全审查要求不允许把测试接口暴露在公网平台上所有开发测试数据必须留在内网服务器。自建服务部署在自己服务器上数据不出内网合规上明显更省心。2. 环境准备Node 版本管理与安装2.1 服务器端 Node 安装的两种姿势伪请求服务本质上就是一个 Node 进程所以服务器上必须先有 Node 环境。这里先聊安装姿势。如果你对服务器有 root 权限网络又正常最省事的是用官方二进制包或者包管理器。我这边服务器是 CentOS 7.9最开始是直接用的 nvm 安装。nvm 的好处是版本切换方便不用 root 权限也能装到用户目录下对于“没有 root 权限只能申请普通账号”的运维场景特别友好。安装 nvm 的方式很简单curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash source ~/.bashrc nvm --version装完之后就可以安装指定版本的 Nodenvm install 20.11.1 nvm use 20.11.1 node -v npm -v国内服务器如果拉取超时可以设置镜像源再装这一步在运维环境里几乎都会遇到export NVM_NODEJS_ORG_MIRRORhttps://npmmirror.com/mirrors/node/ nvm install 20.11.1另一个姿势是直接下载 Node 官方编译好的 Linux 二进制包解压后配置 PATH。这个方法的好处是不依赖 nvm 脚本也不污染 shell 配置适合更保守的运维策略wget https://nodejs.org/dist/v20.11.1/node-v20.11.1-linux-x64.tar.xz tar -xJf node-v20.11.1-linux-x64.tar.xz -C /usr/local/ ln -s /usr/local/node-v20.11.1-linux-x64/bin/node /usr/local/bin/node ln -s /usr/local/node-v20.11.1-linux-x64/bin/npm /usr/local/bin/npm注意顺手把 npm 全局包的 bin 目录也放进 PATH否则后面用npm i -g pm2这种命令时会提示命令找不到。2.2 nvm 全局配置与版本切换用 nvm 管理版本还有几个细节如果没配好很容易在下一次登录服务器的时候才发现“诶node 命令怎么没了”。原因是 nvm 的初始化脚本是写到~/.bashrc里的如果你用的是 zsh或者服务器登录 shell 不是 bash就要确认初始化脚本有没有在对应 rc 文件里生效。我踩过的实际坑是在 root 账号下用 nvm 装了 Node之后用普通运维账号想切到同一套环境结果发现 node 命令不存在。这里有两层问题。第一nvm 默认装在用户目录~/.nvm不同账号之间不共享第二即便你把NVM_DIR指到同一个目录不同账号的~/.bashrc里还是得有那三行初始化脚本。更好的做法是把 Node 版本固定装到系统级目录或者用 nvm 别名机制在项目启动脚本里显式指定 Node 版本路径避免依赖 shell 的环境变量。多版本并存时的全局依赖也要注意。虽然 nvm 支持nvm use v20.11.1切换当前 shell 的版本但 npm 全局包是按 Node 版本分开存放的。如果你用nvm use 18时全局装了 pm2切换到 20 版本后pm2命令可能就找不到了这时候要么重新安装要么在项目目录下用npx pm2指定调用。这个特性容易让人误以为“npm 全局安装失效了”其实是版本隔离在起作用。2.3 离线安装 Node 的坑国内有些服务器环境属于内网隔离区外网根本连不上这时候离线安装就不可避免。离线安装的核心就一句话提前在外网机器上把需要的包下载完整拷贝进去。Node 的 Linux 二进制包是自包含的不依赖额外的系统动态库这一点比很多编译安装的软件省心得多。但离线环境真正麻烦的不是 Node 本身而是 npm 依赖。伪请求服务要用的 express、axios、cors 这些包在内网机器上npm install永远会卡死。我当时的处理方法是在外网一台同系统同架构的机器上先建好项目执行一遍npm install然后把整个 node_modules 目录和 package-lock.json 一起打成 tar 包传进内网。只要 Node 版本一致、系统架构一致x64 对 x64这种方式基本不会出问题。另外一种离线思路是用npm pack把单个依赖打包成 tgz再通过内网 npm registry 自建仓库来安装。但那是大工程我们这种小团队没那个精力直接拷贝 node_modules 反而最实用。唯一要注意的是如果依赖里有原生模块node-gyp 编译的跨机器拷贝极容易因为 glibc 版本不同而加载失败。express 这类纯 JS 库没有这个问题但像 bcrypt、sharp 这些就得小心。伪请求服务里我刻意避开了所有原生依赖纯 Express mockjs拷贝过去就万事大吉。3. 伪请求服务的落地实现3.1 项目结构与路由设计先看项目结构这个结构在我这边已经稳定跑了两个迭代版本可以直接抄作业pseudo-http/ ├── package.json ├── src/ │ ├── server.js # 服务入口 │ ├── router/ │ │ ├── auth.js # 登录鉴权模块 │ │ ├── member.js # 会员管理模块 │ │ └── order.js # 订单模块 │ ├── middleware/ │ │ ├── logger.js # 请求日志 │ │ └── delay.js # 延迟模拟 │ ├── data/ │ │ ├── member.json # 静态假数据 │ │ └── generator.js # 动态数据生成 │ └── utils/ │ └── response.js # 统一返回格式 └── .env # 端口等配置路由设计的原则是“按业务模块划分”而不是“按接口数量划分”。这样每个前端页面开发人员只需要关心自己负责的模块目录不会出现所有人改同一个路由文件导致冲突。每个业务模块的 mock 路由单独成文件文件里再按 HTTP 方法和路径细分。前端约定以/api前缀访问后端真实接口也是这个前缀联调切流量的成本最低。统一返回格式这步一定要做。伪请求服务越像真实后端联调时发现的问题就越真。我们内部约定的返回结构是{ code: 0, msg: ok, data: {} }前端封装的所有请求都基于这个结构做拦截。伪请求服务在返回时也严格按这个结构这样前端在处理登录过期、权限不足、业务报错时和真后端完全一致。3.2 动态数据与条件分支静态假数据只能覆盖最简单的场景真正有价值的是动态数据。我的做法是结合 mockjs 和自写 generator在返回不同业务状态时生成不同数据。比如登录接口要模拟“密码错误”“账号锁定”“验证码过期”几种情况这时候就不能只返回固定 json而是要根据请求参数决定响应。举一个订单查询接口的例子判断用户传入的status字段返回不同状态下的订单列表const Mock require(mockjs); router.post(/order/list, (req, res) { const { status, page 1, pageSize 10 } req.body; const total status pending ? 23 : 87; const list Mock.mock({ list|10: [ { id|1: (page - 1) * pageSize 1, orderNo: string(number, 12), status: status, amount|100-9999.2: 1, createTime: datetime(yyyy-MM-dd HH:mm:ss) } ] }).list; res.json({ code: 0, msg: ok, data: { total, page, pageSize, list } }); });这段代码的核心思路是前端传状态mock 端按状态返回对应的数据结构和条数。前端就可以在口袋里随时切换“待处理订单”“已完结订单”的页面展示而不需要后端真的改数据库。更复杂的场景是“条件分支 随机异常”。比如在下单接口里模拟“库存不足”的返回我不能每次都是同一个错误否则前端无法验证错误提示出现后再点一次按钮应该恢复。我的做法是按请求参数里的商品数量做判断数量大于 10 就返回库存不足小于 10 正常返回订单号。这样联调时前端改一下输入就能切换分支可比在代码里注释来注释去要直观得多。3.3 延迟与异常场景模拟真实网络环境总有延迟而联调时如果用 mock 服务秒回前端所有接口都感觉“快到不正常”等切到后端环境才发现一堆加载态、loading 时机的问题没测出来。所以延迟模拟是我强烈建议加入的。做法很简单加一个中间件按路由前缀匹配不同的延迟区间const delay (ms) new Promise((resolve) setTimeout(resolve, ms)); app.use(async (req, res, next) { const delayMs req.path.startsWith(/api/slow) ? 2000 : 300; await delay(delayMs); next(); });更精细的控制是用 .env 文件配置MOCK_DELAY_MAX2000之类的参数想模拟弱网环境就把值调大想模拟高并发就把值调小。这比在代码里硬编码方便得多因为不同阶段的联调对延迟的要求完全不一样UI 验收时希望快点异步并发测试时希望慢点。异常模拟的另一块是 HTTP 状态码和业务错误码的区分。前端请求库通常会把 HTTP 502 当成网络错误处理把业务 code 非 0 当成业务错误处理。mock 服务要能把这两种情况都模拟出来。我通常会在路由处理里留一个X-Mock-Error请求头开关前端在调试工具里手动加这个头mock 服务读到后直接返回 500 或特定业务错误码这样不改变业务请求参数的情况下就能测异常分支。3.4 请求日志与回放伪请求服务除了给前端用还有一个意外收获是成为接口联调的“对话记录”。每个请求进来我都会把时间、路径、请求参数、响应状态码、耗时打日志。一开始仅为了排查问题后来发现这些日志对后端联调特别有用——后端把真实接口做出来后可以直接拿 mock 服务记录的请求样本来验证参数格式省去了自己拼参数的麻烦。日志实现不需要引入重型日志框架直接用 fs 追加写 JSON 行然后按天分文件即可const fs require(fs); const path require(path); function record(req, res, body) { const line JSON.stringify({ ts: Date.now(), method: req.method, url: req.originalUrl, query: req.query, body: req.body, status: res.statusCode }); const file path.join(__dirname, ../logs, ${formatDate(new Date())}.jsonl); fs.appendFileSync(file, line \n); }每行一条 JSON方便 grep 也方便后续写脚本回放。回放场景我确实用过一次前端报了一个“提交订单重复”问题由于是 mock 服务理论上数据不落库很可能是前端重复提交导致的。我把当天的日志拉出来发现同一个 orderNo 在 200 毫秒内出现了两次 POST立刻定位到是前端按钮防抖没做好。日志回放的价值在这一刻算是体现到位了。4. 守护与部署别让服务悄悄挂掉4.1 SSH 断开后 Node 服务停止的问题伪请求服务如果只在前台跑node src/server.js只要 SSH 一断开进程就会被 SIGHUP 信号杀掉这是新手最容易踩的坑。原因很简单当你直接在一个终端前台启动进程时该进程会跟随终端会话的生命周期会话结束进程退出。解决这个问题的第一反应是用nohup包一层nohup node src/server.js 确实可以做到退出 SSH 后进程继续跑。但 nohup 的缺点是进程管理太弱没有自动重启、没有进程状态查看、崩溃了不会自己恢复。在服务器运维中这只能算一个“能用但不推荐”的方案。我个人的建议是直接用 pm2 或者 systemd。两者各有各的适用场景pm2 更适合开发/测试环境上手快日志管理方便systemd 更适合生产环境由系统级守护开机自启更稳。伪请求服务放在测试服务器上我用的 pm2因为它自带负载均衡、内存监控和一键重启很贴合联调阶段高频改路由的节奏。4.2 PM2 守护与开机自启pm2 安装和使用的整个过程比较简单但有几个配置细节值得写出来。先安装npm i -g pm2 pm2 start src/server.js --name pseudo-http pm2 savepm2 save这一步经常被忘记。它的作用是把当前进程列表保存到 dump 文件这样重启机器后可以用pm2 resurrect恢复。但注意pm2 resurrect是手动恢复如果想开机自动恢复还得再执行pm2 startup执行后系统会提示你复制一行命令到/etc/systemd/system/pm2-root.service作为系统服务。这一步在 CentOS 上需要注意用户权限如果 pm2 是以 root 运行那pm2 startup建议也以 root 执行否则重启后服务起不来。pm2 的日志管理也值得一提。默认日志会写到~/.pm2/logs/pseudo-http-out.log和pseudo-http-error.log。联调阶段经常需要把报错日志发给后端同事看但 pm2 默认日志会无限增长跑一个月可能几个 GB。我一般会加一句清理脚本pm2 install pm2-logrotate pm2 set pm2-logrotate:max_size 50M pm2 set pm2-logrotate:retain 7 pm2 set pm2-logrotate:compress true这样日志超过 50MB 自动切割保留最近 7 天同时旧日志压缩不会把磁盘写满。4.3 容器环境中的资源限制问题有些测试环境用的是 Docker 容器跑服务我在排查问题时就遇到过he node was low on resource: ephemeral-storage这类报错。这其实是 Kubernetes 节点上的临时存储ephemeral-storage不够用了容器被驱逐的典型提示。伪请求服务本身不产生多少数据但如果你在容器里写日志、装 npm 依赖临时存储占比会迅速上升。处理思路有两步第一限制写入。把日志目录映射到外部挂载卷避免在容器可写层里积累第二清除缓存。npm 的_cacache目录可能占用几百 MB构建镜像时最好执行一次npm cache clean --force。另外 Node 镜像也有大小差异同样是 Node 20 基础镜像node:20-bullseye-slim比node:20小很多在离线导入镜像的场景下这个差距非常明显。我这边还有一次容器内服务一直启动失败查了半天发现是内存限制——容器只分配了 128MB而 Express 应用正常启动后加上日志缓存内存经常冲到 150MB 以上直接被 OOM Killer 干掉。排查办法是启动时加上 Node 的堆内存限制node --max-old-space-size96 src/server.js这个方法可以让 Node 在内存吃紧时主动触发 GC而不是直接崩溃。5. 常见问题与排查技巧实录5.1 高版本 Node 兼容低版本代码问题联调过程中发现一个非常现实的问题同一个伪请求服务代码开发机上是 Node 18服务器上是 Node 20可能一个接口在本地正常、在服务器上报错。最常见的原因有三个一是高版本 Node 对废弃 API 的移除更严格二是某些第三方包在高版本下还没适配三是项目里用了较新的 ESM 语法而运行环境的package.json缺少type: module声明。在我踩过的坑中最典型的是fs.existsSync这类同步 API 其实还好但有的老代码会直接用new Buffer()这在 Node 20 下会直接报错。解决办法是不要试图在一大堆代码里去替换而是先把 Node 版本统一开发环境和服务器环境都记录在.nvmrc文件里nvm use时自动读取。伪请求服务这种内部工具保持环境一致比纠结兼容性更加省事。如果确实需要低版本兼容高版本的场景比如开发机上被迫升到了新版本我的建议是给项目明确指定一串可用的版本范围在package.json里写清engines: { node: 18 21 }启动时再用engine-stricttrue配置强制校验这样版本不一致的问题在服务启动阶段就能暴露而不是被用户先发现。5.2 安装 Node 后 npm 不可用使用二进制包解压安装 Node 后经常会遇到node -v有输出、npm -v却提示找不到命令。这个问题的根源是 npm 在 Node 安装目录里的可执行文件符号链接没有建立起来。用apt install nodejs这类包管理器安装的版本npm 和 node 的链接通常由系统负责但手动解压二进制包时很容易漏。我整理一套快速排查命令# 检查 node 真实路径 which node # 检查 npm 是否存在 ls -l $(dirname $(which node))/npm # 查看 npm 文件头 head -n 1 $(dirname $(which node))/npm如果 npm 文件存在但无法执行检查有没有执行权限如果文件不存在最简单的方法是重新解压一份完整的二进制包而不是单独去复制 npm 文件因为 npm 还依赖同目录下的node_modules/npm包结构单独复制很容易缺文件。这也是为什么我一直推荐直接下载官方完整 Linux 二进制包而不是到处找零散的 npm 可执行文件。另一类 npm 不可用的情况是 Node 自带 npm 版本和镜像源冲突。执行npm config get registry看输出如果指向的源不可达安装任何包都会卡死。国内环境建议设置成 npmmirror 镜像源npm config set registry https://registry.npmmirror.com5.3 端口占用与 EADDRINUSE伪请求服务通常固定监听一个端口东方仙盟这边用的是 4090重启服务时如果上一次进程没有干净退出就会出现EADDRINUSE错误。这种问题在 pm2 场景下不多见因为 pm2 restart 会先停掉旧进程但如果你混用 nohup 和 pm2或者在容器里用不同的启动命令就容易出现端口占用。排查命令也很简单# 查看 4090 端口占用情况 lsof -i :4090 # 直接按 PID 结束进程 kill -9 PID需要注意kill -9虽然能立刻释放端口但如果这个进程是 pm2 管理的你杀了它之后 pm2 会立刻再拉一个新进程还是占用端口。所以最稳妥的流程是pm2 stop pseudo-http确认服务停了再启动或者干脆用pm2 restart pseudo-http让 pm2 自己处理新旧进程的替换。我在排查线上问题时遇到过同事先kill -9然后 pm2 自动拉起旧进程、导致怎么杀都杀不掉的乌龙这个顺序问题值得提醒一下。另外防火墙层面也要确认端口是否放行。服务本身启动成功但前端请求一直超时这种问题往往不是 Node 进程的锅而是 iptables 或安全组规则没放行。测试环境可以直接用curl http://127.0.0.1:4090/healthcheck先确认本地可访问再用另一台机器的telnet 服务器IP 4090确认远端可达以此快速定位是网络问题还是服务问题。5.4 时区与日志时间错乱问题伪请求服务记录的日志如果直接存本地时间戳跨时区排查问题时会特别难受。尤其服务器如果设置为 UTC 时间而前端和测试人员都在东八区那日志里的“下午 3 点 05 分”就要在心里先减 8 小时非常容易出错。我习惯在日志里同时记录时间戳和可读时间时间戳用于排序和精确计算可读时间用于人眼查看。Node 里取东八区时间可以这样function formatDate(d) { return new Date(d.getTime() 8 * 3600 * 1000) .toISOString() .replace(T, ) .slice(0, 19); }更省事的方式是直接在服务器上统一设置时区CentOS 里执行timedatectl set-timezone Asia/Shanghai然后把 Node 进程重启一遍让进程读取到新的 TZ 环境变量。否则即使系统时间变了已运行的 Node 进程拿到的还是旧的时区信息日志时间还是错的。写在最后伪请求这个事从搭建到现在玩了两三个版本我最大的体会是mock 服务的价值不在于把数据造假而在于把前后端之间的“接口契约”提前变成可交互、可回归、可复盘的形式。东方仙盟这边的联调效率从之前等后端接口改成现在拿 mock 服务先跑业务闭环至少缩短了两天起步的等待时间。如果你也在为前后端联调节奏发愁先在服务器上花半天搭一个类似的服务绝对不亏。最后再补一句所有 mock 数据和日志记得在切到真实后端之前清理干净千万别让它影响生产环境的判断。