【技术底稿 33】同机复用开发资源，搭建完整测试环境实战复盘一、核心背景
一、核心背景
在不新增机器、复用现有开发服务器硬件的基础上，搭建一套与开发环境逻辑隔离的测试环境。
核心原则：能共用的全共用，会冲突的必须隔离，最大化利用现有资源，同时彻底避免环境污染。
二、资源拆分与隔离落地
1. 中间件隔离（核心风险点）
- MySQL、Redis、Zookeeper：单独实例 / 库隔离，测试与开发数据完全分离，互不串数据、互不抢锁。
- 中间件层面实现了 100% 隔离，从根源杜绝测试数据污染开发环境。
2. 非核心资源全复用
- Milvus、Nginx、服务器硬件、系统环境、基础运行时：全部共用开发机资源，不重复部署，节省成本与维护成本。
3. 日志隔离
- 测试环境单独日志目录、单独归档策略，与开发日志完全拆分，排查问题互不干扰。
4. 构建与部署隔离
- Jenkins 打包、部署脚本单独一套，dev/test 环境脚本分家，打包、拉包、启停互不干扰，避免误操作。
三、架构与域名布局
- 两套前端：
work.你的域名（开发）、test-work.你的域名（测试） - 两套网关入口：
api.你的域名（开发）、test-api.你的域名（测试） - 后端微服务：一套物理部署，通过配置 + 隔离中间件区分环境，避免重复部署。
四、踩坑实录：Nginx 域名自环大坑
错误配置（踩坑现场）
test-work前端配置中，直接用公网域名做代理转发：
nginx
location /api/ { proxy_pass http://test-api.你的域名/; }诡异现象
- 单独访问
test-api.你的域名正常返回 302 进入网关 - 从
test-work调用/api时，请求被前端location /规则拦截，直接返回 Vue 首页 HTML，无法命中 API 转发规则
无用排查过程
怀疑 location 顺序、怀疑配置未生效、怀疑域名冲突、怀疑前端问题，全部无效，浪费大量时间。
五、根治方案（两步解决）
1. 改造 test-api 配置
在配置顶部定义内网 upstream 组，统一管理网关入口：
nginx
upstream test_api_servers { server 127.0.0.1:你的网关端口; }2. 改造 test-work 配置
将公网域名转发改为内网 upstream 直连：
nginx
location /api/ { proxy_pass http://test_api_servers/; }原理说明
内部转发不走公网 DNS、不走公网 IP、不自环，纯内网直达，避开 Nginx 虚拟主机匹配错乱问题。
六、最终闭环结果
- 中间件隔离、日志隔离、Jenkins 部署脚本隔离全部完成
- 硬件和非核心资源最大化复用
- Nginx 域名自环坑彻底根治，访问
/api正常返回 JSON 业务接口 - 开发环境、测试环境物理共用、逻辑完全隔离，整套架构稳定可用
至此，开发和测试两套环境共用一台机器，中间件隔离、日志不串、部署脚本分家、前端网关不打架。可以放心上线了。
七、固化铁律
同一台 Nginx 下，内部前端 / 服务互相代理，禁止使用公网域名，一律用 upstream 内网直连，从架构层面避免虚拟主机匹配错乱问题。
八、底稿收尾落款
本文是《技术底稿》系列第 33 篇，记录在不新增机器的前提下，复用开发服务器搭建完整测试环境的全流程实战复盘，包含资源隔离方案、域名架构设计与 Nginx 自环坑根治方案，可作为同机多环境部署的参考范本。