2. 迁移基础概念

核心银行迁移不是“把数据从A库搬到B库”这么简单。它同时涉及应用架构、数据架构、基础设施与业务连续性四条主线。理解迁移基础概念，是后续设计批次、制定回退方案与识别风险的前提。本节围绕四个关键词展开：系统架构、迁移类型、批次与风险控制术语。

一、核心银行系统架构：迁移的“地形图”

核心银行系统通常采用分层架构。迁移前必须画清“地形图”，否则批次划分会失去依据。典型分层如下：

• 渠道层：柜面、手机银行、ATM、开放银行API，负责交易发起与结果展示。
• 接入与集成层：ESB、消息队列、文件传输，承担协议转换与流量缓冲。
• 应用层：存款、贷款、卡、支付、总账等核心业务模块，是迁移改造的主要对象。
• 数据层：客户、账户、余额、交易流水、参数表，是迁移数据的主体。
• 基础设施层：主机、数据库、存储、网络与中间件，决定迁移窗口与性能上限。

迁移视角下，架构分析要回答三个问题：哪些模块必须同步切换？哪些数据存在强一致性约束？哪些接口在切换期间需要“挡板”或“双写”？例如存款与总账之间存在借贷平衡约束，若分批迁移而中间态未做补偿，就会出现账务不平。

二、迁移类型：全量、增量与混合

按数据范围与切换方式，核心银行迁移通常分为三类：

迁移类型	适用场景	优点	主要风险
全量迁移	系统整体替换、停机窗口充足	逻辑简单、一致性易验证	窗口长、回退成本高
增量迁移	不停机或短停机、按业务域分批	窗口短、可灰度	追平延迟、数据漂移
混合迁移	先全量初始化，再增量追平后切换	兼顾窗口与一致性	追平与切换衔接复杂

实际项目中，混合迁移最常见。典型流程是：先做历史数据全量初始化，再通过日志或CDC持续增量追平，最后在切换窗口内停止增量、校验差异、执行切换。这里的关键参数是追平延迟与差异容忍阈值。

# 增量追平状态检查示例（伪命令）
migration status --channel cdc-deposit
# 输出：
# source_lag_ms: 120
# target_lag_ms: 95
# pending_rows: 0
# checksum_diff: 0

三、批次概念：把大迁移拆成可控单元

批次是迁移的最小可控执行单元。一个批次通常对应一组业务上高内聚、技术上可独立校验的数据或模块。批次划分要遵循三条原则：

1. 业务闭合：同一批次的账户、余额、流水应能独立完成账务校验。
2. 依赖有序：参数表、客户、账户、交易流水按依赖顺序排列。
3. 可回退：每个批次有明确的回退边界与回退脚本。

批次执行通常包含五个状态：待执行、执行中、已校验、已切换、已回退。每个状态都要有对应的检查点与日志。例如：

batch_id: BATCH-DEP-001
name: 存款-活期账户
status: 已校验
checkpoints:
  - extract_done: true
  - load_done: true
  - checksum_match: true
  - balance_match: true
rollback_script: rollback_dep_001.sh

四、风险控制基本术语：迁移中的“共同语言”

迁移风险控制有一套通用术语，团队必须统一理解，否则沟通会出现歧义。核心术语包括：

• RPO（恢复点目标）：允许丢失的最大数据量，通常以时间衡量。核心银行迁移中RPO应趋近于0。
• RTO（恢复时间目标）：故障后恢复业务的最长时间，决定回退方案的设计。
• 切换窗口：允许停机或只读的时间段，是批次排期的硬约束。
• 回退点：可安全回退到的最近一致状态，通常对应某个批次校验通过后的快照。
• 差异容忍阈值：新旧系统数据比对时允许的差异上限，超过则触发告警或阻断。
• 双写：切换期间同时写入新旧系统，用于过渡期一致性保障。
• 挡板：在切换期间临时阻断某类交易，防止脏数据进入新系统。

五、常见误区与复盘要点

在迁移初期，团队常陷入以下误区：

• 误区一：先迁数据，后补架构。 结果接口未改造，切换后交易失败。正确做法是先完成架构影响分析，再定批次。
• 误区二：批次按表划分，忽略业务闭合。 导致余额与流水分离，校验无法通过。
• 误区三：只关注正向切换，不演练回退。 一旦切换失败，无法快速恢复。
• 误区四：差异阈值拍脑袋。 阈值过松会掩盖问题，过紧会导致频繁阻断。

复盘时应重点检查：批次依赖是否与架构一致？回退点是否可验证？RPO/RTO是否在演练中达标？只有把这些基础概念对齐，后续的批次编排与风险控制才有稳固的起点。