一、背景：为什么拆
项目前期部署三台物理服务器，配置 16G、16G、8G。8G 节点资源压力大，频繁内存告警，打包编译极易卡死。
开发、测试环境同机混跑，仅依靠路径、命名空间、前缀做逻辑隔离，边界模糊。日常出现资源争抢、配置串扰、Jenkins 错发包、服务启动异常等问题。
业务进入规模化迭代，正式生产环境需要落地，原有架构无法满足稳定性与扩展需求，因此启动集群扩容与环境拆分改造。
二、新旧架构对比
旧版：三机混跑
16G Java 节点 + 16G Python 节点 + 8G 受限节点
- Dev、Test 无物理隔离边界
- Jenkins 任务共用，错包、跨环境部署频发
- 无独立生产集群
新版：四机均分隔离
扩容为四台统一 16G 服务器，硬件规格一致
- 节点一：开发环境 Java 服务
- 节点二：Python 算法、知识库业务
- 节点三：测试环境 Java 服务
- 节点四：生产环境 Java 集群
核心原则：硬件物理拆分环境，中间件集群共用，业务服务完全隔离，域名独立区分，部署分级管控。
三、中间件隔离方案
共用一套中间件集群，逻辑划分隔离，减少重复运维成本
表格
| 中间件 | 隔离规则 |
|---|---|
| Zookeeper | 路径前缀：/dev、/test、/prod |
| Redis | Key 前缀：dev:、test:、prod: |
| Nacos | 命名空间：public (开发)、test、prod |
| MySQL | 独立库：db_dev、db_test、db_prod |
| Milvus | 独立库：dev 库、test 库、prod 库 |
| Nebula | 独立空间库划分 |
| vsftpd | 仅开发环境使用 |
| SeaweedFS | 测试、生产环境挂载使用，开发按需适配 |
网关配置：单 Nginx 搭载三套独立站点 访问域名：dev.main.com、test.main.com、main.com
部署管控：单 Jenkins 划分三类独立视图，脚本完全分离
- 开发：代码推送自动打包部署
- 测试：人工手动触发部署
- 生产：手动触发，严格权限管控
四、旧架构的核心痛点
-
日志无溯源 启动日志定向黑洞文件，故障无查询依据，多环境日志混杂，报错问题定位难度大。
-
运维规范缺失 无部署校验流程，默认打包包体匹配环境；缺少启停管控，多服务满载运行加剧资源消耗。
五、落地解决措施
- 物理拆分节点，各环境独占服务器，杜绝资源争抢
- 中间件按规则逻辑隔离，数据配置互不穿透
- 独立域名代理，划分专属环境访问入口
- Jenkins 分级部署，上线前置核验包体与环境信息
- 规范日志目录存储，异常问题可实时排查
- 固定节点业务范围，预留资源应对业务峰值
六、核心收益
- 双重隔离彻底规避环境串扰、部署错包问题，运行稳定性提升
- 全节点硬件规格统一，消除低配性能瓶颈
- 分级部署模式降低人为操作失误，上线安全性提高
- 资源、日志、进程归属清晰，故障排查效率大幅优化
- 标准化架构具备良好兼容性，支撑后续业务迭代扩展
七、运维固化准则
- 严守环境边界，节点、数据库、域名互不混用，禁止跨环境操作
- 部署分级执行，开发自动发布提效，测试、生产手动发布保稳
- 完整留存运行日志，舍弃日志丢弃配置，保留排障依据
八、底稿收尾落款
本文为《技术底稿》系列第 41 篇，承接往期低配单机混跑部署踩坑经验，记录项目从三机不均衡混跑架构，升级为四机均分三环境隔离集群的完整落地过程。
基于业务上线需求拆分三套独立运行环境，统一规划中间件隔离规则、域名访问体系、Jenkins 自动化部署流程，彻底解决往期资源挤占、部署错乱、环境串扰等顽疾。
整套架构兼顾资源利用率、运行稳定性、运维安全性，适配中小团队微服务多环境迭代、正式项目上线场景，沉淀的环境隔离方案与分级部署规范，可作为同类集群架构搭建参考范本。