【技术底稿 35】低配单机混跑 Dev/Test 微服务环境，Jenkins 部署包错乱踩坑全复盘
一、核心背景
在不新增服务器、沿用现有7G 低配开发机前提下，同时承载：
开发环境（2 个 admin 节点）
测试环境（1 个 admin 节点）
Jenkins 打包编译
MySQL / Redis / Zookeeper / Milvus 等全套中间件
机器硬件资源极度吃紧，开发与测试环境同机混跑，既要最大化复用现有硬件与中间件资源，又要规避环境串扰、部署出错、内存溢出、打包卡死等各类隐性问题。
本次复盘基于连续两天真实排障经历，记录 Jenkins 脚本路径疏漏、部署包环境错乱、内存资源争抢、服务启动持续报错的完整踩坑与根治全过程。
二、现状与核心痛点
硬件瓶颈
单台 7G 内存服务器，同时运行多微服务实例、中间件常驻进程、Jenkins Java 进程，内存长期占用居高不下，负载时常飙高。
部署隐患
Dev、Test 环境共用一台 Jenkins，早期未做 Job 与路径隔离，脚本修改后路径未同步校准，极易错传包、错部署环境。
排障迷惑性极强
服务启动后持续报错，但因日志被重定向至/dev/null而未留下有效信息；本地开发环境使用相同代码可正常启动。反复排查 JVM 参数、端口占用、Nacos 配置、中间件连通性均无果，排障陷入盲猜困境。
人为疏漏隐患
依赖人工记忆区分 Dev/Test 包、Nacos 命名空间、配置文件，无标准化核对流程，稍有疏忽就环境串位。
中间件逻辑隔离方案（已落地）
| 中间件 | 隔离方式 |
|---|---|
| MySQL | 独立 database（dev / test） |
| Redis | 统一加前缀（dev: / test:） |
| Zookeeper | 不同根路径（/dev / /test） |
| Milvus | 不同集合名称 |
三、现场踩坑实录
1. 故障现象
Jenkins 打包部署后，task-server服务启动后持续报错，但本地开发环境使用相同代码可正常启动。
反复排查 JVM 参数、端口占用、Nacos 配置、中间件连通性，均未找到原因。日志因被重定向至/dev/null，无有效错误信息，排障全靠猜测。
2. 无效排查过程
怀疑 JVM 堆内存配置过大，反复调整
-Xms、-Xmx、新生代比例怀疑启动脚本逻辑问题，修改 nohup、环境变量、进程检测逻辑
怀疑端口占用、Nacos 注册失败、配置加载异常，逐一核对注册中心与配置中心
怀疑服务器环境差异，对比本地与服务器各项配置
全程没有怀疑过“包是不是就是错的”—— 潜意识里默认 Jenkins 不会犯这种低级错误。
3. 真实根因落地
最终将服务器上已部署的 Jar 包下载到本地，解压查看内部配置与环境标识，实锤核心问题：
Jenkins 脚本路径未改干净，误把 Test 环境的 Jar 包，部署到了 Dev 环境目录
包本身环境配置不匹配，导致 Nacos 命名空间、数据库配置、环境标识全部错乱
服务启动阶段上下文初始化失败，持续报错
并非脚本问题、并非 JVM 参数问题、并非服务器环境问题，纯粹是部署包与目标环境不匹配。
4. 排障核心教训
本地能跑 ≠ 服务器能跑，服务器报错 ≠ 服务器环境问题，先验包，再排障。
四、衍生连带问题
内存资源争抢：7G 机器多服务常驻，内存被多个 Java 实例占满，Jenkins 一旦触发打包编译，瞬间内存拉满、负载飙升、打包卡死
无错峰启停规范：Dev 与 Test 环境同机混跑，两套环境服务同时常驻，进一步挤压系统剩余资源
日志不可追溯：启动日志直接丢弃到
/dev/null，故障后无日志可查，只能盲猜排障，效率极低无部署核对流程：习惯性默认 Jenkins 打包产物一定对应目标环境，缺少验包校验环节
五、根治落地解决方案
1. Jenkins 环境彻底隔离
Dev、Test 拆分独立 Jenkins 任务，各自专属：
打包分支
产物目录
部署脚本
服务器部署路径
完全分家不混用，从源头杜绝路径错乱、错发包问题。
2. 新增部署标准化核对清单
固化上线部署前置校验，不走省略流程：
验包时间戳
解压查看内部环境配置
核对 Nacos 命名空间
检查配置文件加载日志
确认端口与内存余量
3. 启动脚本规范整改
禁止默认将日志重定向至
/dev/null统一落地日志文件，故障可追溯、可实时
tail排查固定
--spring.profiles.active环境参数，不随意混用
4. 低配机器资源管控
同机 Dev/Test 环境不允许全部满负荷常驻，采用错峰启停策略：
开发环境服务：工作日 8–20 点常驻
测试环境服务：20 点–次日 8 点常驻
Jenkins 打包时段错开两套环境同时高负载
闲置非核心业务实例，为 Jenkins 打包预留充足内存资源，避免编译期卡死、负载飙高。
5. 服务环境强隔离
沿用已有架构规范：
中间件库表/前缀/路径/集合隔离
日志目录隔离
部署目录隔离
硬件与无冲突中间件共用，有数据与配置冲突的全部逻辑隔离。
六、最终闭环结果
| 问题 | 结果 |
|---|---|
| Jenkins 包与环境错位 | ✅ 修正脚本与部署逻辑，Dev 包归 Dev、Test 包归 Test |
| 服务启动报错 | ✅ Nacos 注册、配置加载、接口调用全部正常 |
| 7G 机器打包卡死/内存爆满 | ✅ 错峰启停 + 资源预留，彻底解决 |
| 部署无规范 | ✅ 沉淀标准化核对清单，后续按清单兜底 |
| 开发/测试环境共用机器 | ✅ 物理共用一台，逻辑完全隔离，资源利用率最大化 |
七、固化铁律
微服务同机多环境部署，绝不盲目信任 Jenkins 打包产物
必须人工验包、核对内部环境配置服务启动日志强制落盘归档
禁止一律定向/dev/null，保留排障线索低配服务器严禁 Dev/Test 全套服务同时常驻
必须错峰启停，给编译、打包预留资源Jenkins 不同环境必须独立 Job、独立路径、独立脚本
绝不共用一份部署配置排障优先级
先怀疑「包不对、环境不对、配置不对」
其次再纠结脚本、JVM、端口等表层问题本地能跑 ≠ 服务器能跑
服务器报错时，先确认部署的包是否真的对应当前环境
八、底稿收尾落款
本文是《技术底稿》系列第 35 篇，记录低配单机混跑 Dev/Test 微服务场景下，Jenkins 脚本疏漏、部署包环境错乱、内存资源争抢的完整踩坑、排障与规范固化全过程。
沉淀可复用的部署核对清单与同机多环境运维铁律，适合小团队低配服务器微服务部署参考范本。