金融系统多轮迭代下的 UAT 架构设计：Docker + VM（Baseline / Target 模型实践）

在金融系统交付过程中，UAT（User Acceptance Testing）往往不是一次性的验收，而是一个持续多轮迭代、不断修正的过程。

以恒生电子Summit（在海外通常是Finastra Summit）为代表的系统，在实际项目中往往呈现出：

• 多版本并行验证
• 高频需求变更
• 严格审计与回溯要求

在这种背景下，单一的 VM 或 Docker 架构都很难同时满足：

• 合规隔离要求
• 快速迭代需求
• 多版本对比验证

因此，本文从工程实践出发，介绍一种更贴近 UAT 实际的架构模型：

Docker Runtime + VM + Baseline / Target 双轨模型

---

一、金融系统 UAT 的核心问题

---

1️⃣ 多轮迭代带来的版本爆炸

UAT 过程中常见状态：

• baseline（已验证版本）
• target（当前测试版本）
• fix版本（针对缺陷修复）

👉 实际情况是：

baseline v1
target v2
target v2.1
target v2.2

这些版本需要：

• 可并行运行
• 可对比验证
• 可快速切换

---

2️⃣ 环境影响测试结果

在 Summit 类系统中：

• MQ / DB / Backend 强耦合
• 配置变化直接影响业务行为

👉 核心问题：

测试结果 = 代码 + 环境 + 数据

---

3️⃣ 回滚与复现要求极高

金融 UAT 中必须支持：

• 精确复现问题
• 快速回退版本
• 保留历史环境

---

二、Docker + VM + Baseline/Target 架构模型

---

2.1 核心结构（替代传统分层图）

[ VM（安全隔离） ]

Docker Runtime
├── Baseline（已验证稳定版本）
│ └── summit-backend:v1
│
├── Target（当前测试版本）
│ ├── summit-backend:v2
│ ├── summit-backend:v2.1
│ └── summit-backend:fix1
│
└── Supporting Services
├── ActiveMQ
└── Other components

---

2.2 架构职责划分

组件	作用
VM	安全边界 / 合规隔离
Docker Runtime	运行环境管理
Baseline	对照版本（不可变）
Target	当前测试版本（可变）

---

👉 本质：

Baseline = 稳定参照系
Target = 迭代变化源

---

三、这种模型在 UAT 中的实际价值

---

3.1 多版本对比验证（核心能力）

通过同时运行：

baseline:v1
target:v2

可以实现：

• 行为对比
• 回归验证
• 问题定位

👉 在金融系统中，这一点极其关键。

---

3.2 避免“环境漂移”

Baseline 一旦确认：

• 不允许修改
• 不重新部署

👉 作为：

唯一可信对照环境

---

3.3 支持快速修复验证

开发修复问题后：

target:fix1

👉 可以直接：

• 与 baseline 对比
• 与旧 target 对比

无需重建环境。

---

3.4 UAT 环境“版本化”

通过：

• Docker Image（版本）
• VM Snapshot（环境）

实现：

• 测试可复现
• 审计可追溯

---

四、工程难点与解决思路

---

🔥 难点1：Baseline 被污染

常见问题：

• 临时修改 baseline 配置
• 直接在 baseline 上修复问题

👉 后果：

• 对照失效
• 测试失真

👉 解决：

• Baseline 只读（immutable）
• 禁止登录修改

---

🔥 难点2：Target 版本混乱

问题：

• 多个 target 混用
• 无版本标识

👉 解决：

summit-backend:v2
summit-backend:v2.1
summit-backend:fix-123

👉 必须：

• 明确版本命名规则
• 禁止覆盖 tag

---

🔥 难点3：配置不一致

表现：

• baseline 与 target 配置不同
• 导致结果不可对比

👉 解决：

• 配置外置（volume / env）
• baseline/target 共享同一配置模板

---

🔥 难点4：数据干扰

问题：

• 多版本共享数据库
• 数据被污染

👉 解决：

• 独立数据库实例
• 或使用数据快照

---

五、安全与合规设计

---

5.1 VM 作为安全边界

原因：

• 金融系统要求隔离
• 满足审计要求

---

5.2 Docker 运行策略控制

--user 1001
--read-only
--cap-drop ALL

---

5.3 网络隔离

• Baseline 与 Target 可隔离访问
• 避免误操作

---

5.4 数据与日志保护

• log 挂载但权限控制
• 避免容器直接导出敏感数据

---

六、成本与效率的实际变化

---

在多轮 UAT 中：

项目	传统模式	Baseline/Target 模型
环境搭建	多次重复	一次构建
版本对比	困难	原生支持
回滚成本	高	低
问题定位	慢	快

---

👉 核心变化：

从“环境驱动”转为“版本驱动”

---

七、工程实践总结

---

推荐模式：

• VM：提供隔离
• Docker：管理运行
• Baseline：稳定对照
• Target：迭代验证

---

一句话总结

在金融 UAT 中，真正需要管理的不是环境，而是“对照关系”

Docker Runtime + Baseline / Target 模型，本质上解决的是：

• 多版本并存
• 精确对比
• 可复现验证

---

最后

在 Summit 这类复杂金融系统中，UAT 的成本往往不在“测试执行”，而在：

• 环境准备
• 版本切换
• 问题复现

而 Baseline / Target 模型，使这些问题从“不可控”变为“可管理”