2. Testing环境架构概览：整体拓扑、网络分区、服务依赖关系图
Testing环境是数据库缓存工程回归冒烟测试的核心战场。它并非生产环境的简单缩略版，而是一个经过网络分区、服务裁剪与依赖模拟的独立集群。理解其整体拓扑、网络分区策略以及服务依赖关系，是后续配置数据源、搭建缓存层、准备测试数据的先决条件。
2.1 整体拓扑：三层两域一总线
Testing环境采用经典的“接入层 – 逻辑层 – 数据层”三层架构，并在此基础上引入缓存域与持久化域的网络隔离，以及一条内部测试总线用于异步消息与监控数据采集。整体拓扑如下图所示：
拓扑要点：缓存域与持久化域之间没有直接网络通路。所有缓存回源、缓存预热、缓存与数据库的一致性校验，都必须经过逻辑层的服务代理。这一设计强制了回归冒烟测试中“先测缓存、再测DB、最后测一致性”的执行顺序。
2.2 网络分区：四区隔离与访问控制
Testing环境划分为四个独立的网络分区，每个分区拥有独立的子网段、安全组规则与防火墙策略。分区之间的互通必须通过显式的路由规则或代理跳板。
| 分区名称 | 子网段 | 包含组件 | 对外访问策略 |
|---|---|---|---|
| DMZ区 | 10.200.1.0/24 | Nginx、API Gateway、流量染色代理 | 允许测试客户端入站 80/443；禁止出站到公网 |
| 应用区 | 10.200.2.0/24 | 业务微服务、配置中心、注册中心 | 仅接受 DMZ 区入站；可出站到缓存区与数据区 |
| 缓存区 | 10.200.3.0/24 | Redis Cluster、本地缓存代理 | 仅接受应用区入站 6379/6380；禁止访问数据区 |
| 数据区 | 10.200.4.0/24 | MySQL 主从、分库分表代理、归档节点 | 仅接受应用区入站 3306/3307；禁止访问缓存区 |
网络分区避坑：回归冒烟测试脚本必须运行在 DMZ 区的测试容器内，不能直接部署在应用区或数据区。否则会绕过网络分区规则，导致测试结果无法反映真实生产环境的网络延迟与隔离约束。
2.3 服务依赖关系图
Testing环境共涉及 12 个核心服务，它们之间的依赖关系决定了回归冒烟测试的启动顺序与数据准备策略。下图展示了服务间的调用链与依赖层级：
依赖启动顺序（回归冒烟测试前置条件）：
- 启动 配置中心 与 注册中心（基础服务层）
- 启动 Redis Cluster 与 MySQL 主从（数据层）
- 启动 Kafka（测试总线）
- 启动 业务微服务（用户/订单/商品/库存）
- 最后启动 API Gateway 与 限流降级组件
2.4 关键依赖参数速查表
在回归冒烟测试的数据准备阶段，以下依赖参数必须提前写入测试配置中心或环境变量文件：
| 依赖项 | 连接地址（Testing环境） | 端口 | 超时配置（建议） |
|---|---|---|---|
| Redis Cluster | 10.200.3.10,10.200.3.11,10.200.3.12 | 6379 | connect: 2s, read: 3s |
| MySQL 主库 | 10.200.4.10:3306 | 3306 | connect: 3s, read: 5s |
| MySQL 从库 | 10.200.4.11:3306 | 3306 | connect: 3s, read: 5s |
| Kafka Broker | 10.200.5.10:9092,10.200.5.11:9092 | 9092 | producer ack: 1 |
| 配置中心 | 10.200.2.20:8848 | 8848 | connect: 2s |
| 注册中心 | 10.200.2.21:8849 | 8849 | heartbeat: 5s |
数据准备建议：在回归冒烟测试执行前，应通过
testing-init.sh 脚本一次性完成所有依赖服务的连通性检查，并将检查结果输出到测试报告的控制台日志中。避免因某个依赖服务未就绪而导致测试用例大面积失败。