1. 课程导入
欢迎进入《核心银行单体到微服务迁移规划实战》。在动手拆分任何一个服务之前，我们必须先建立一张完整的“认知地图”：核心银行为什么会走到今天这个架构形态，单体架构的边界在哪里，微服务究竟解决了什么问题，以及一次可落地的迁移规划应该包含哪些阶段。本章不讨论具体代码，而是为后续29章建立统一的语言体系和判断标准。
一、核心银行系统的演进背景
核心银行系统（Core Banking System）是银行处理存款、贷款、支付、账户、利息、总账等关键业务的“心脏”。它的演进大致经历了四个阶段：
- 主机集中时代：以大型机、COBOL、DB2为代表，强调稳定与批处理，日终跑批是典型特征。
- 客户端/服务器时代：业务逻辑从主机下移，形成部门级应用，但数据仍高度集中。
- 单体集中式时代：Java EE、Spring、Oracle成为主流，一个WAR包承载数百个功能模块，这也是当前多数银行的核心形态。
- 分布式与微服务时代：面对互联网渠道、高频交易和快速产品创新，系统开始向服务化、云原生演进。
推动迁移的根本动力并非“技术时髦”，而是三个现实压力：业务敏捷性不足（一个产品上线要等几个月）、系统耦合风险高（改一个利率计算可能影响支付）、弹性与成本矛盾（只能整体扩容，无法按热点服务伸缩）。
二、单体架构与微服务架构的对比
理解差异不能停留在“大与小”的层面，而要从部署单元、数据边界、团队协作和故障隔离四个维度去看。下表给出核心银行场景下的关键对比：
| 对比维度 | 单体架构 | 微服务架构 |
|---|---|---|
| 部署单元 | 单一WAR/EAR包，整体发布 | 按业务能力独立部署，灰度发布 |
| 数据边界 | 共享数据库，表间强耦合 | 服务私有数据，通过接口访问 |
| 事务模型 | 本地ACID事务，强一致 | 最终一致，Saga/TCC补偿 |
| 故障影响 | 单点故障可导致全系统不可用 | 故障隔离，可降级与熔断 |
| 团队协作 | 大团队共享代码库，协调成本高 | 小团队按服务自治，独立迭代 |
| 技术栈 | 统一技术栈，升级困难 | 可异构，按服务选型 |
关键提醒：微服务不是“免费午餐”。它把复杂度从代码内部转移到了分布式治理、数据一致性和运维体系上。核心银行迁移若只拆服务而不建治理能力，结果往往比单体更糟。
三、迁移规划的整体学习地图
本课程将迁移规划拆解为一条可执行的主线，下图展示了从现状评估到持续演进的核心路径与关键决策点：
围绕这张地图，课程将依次展开：现状评估与迁移可行性、领域驱动设计与限界上下文、服务拆分策略与反模式、数据拆分与分布式事务、服务治理与可观测性、灰度迁移与双跑验证、组织与流程配套，以及迁移后的持续演进。
四、常见误区与复盘视角
在过往的核心银行迁移项目中，以下误区反复出现，值得在课程开始就建立警觉：
- “先拆再说”——没有领域模型就按技术分层拆服务，结果形成分布式单体，调用链更长、故障更多。
- “数据库最后再拆”——服务拆了但共享库没动，数据耦合让独立部署形同虚设。
- “一步到位替换”——试图一次性切换核心，忽略业务连续性和回退方案，风险不可控。
- “只关注技术，不调整组织”——团队仍是集中式管理，服务自治无法落地。
- “忽视非功能需求”——核心银行对一致性、审计、监管报送的要求远高于互联网系统，必须前置设计。
学习建议：每学完一个规划阶段，请回到本节的学习地图，问自己三个问题——这一阶段的输入是什么？输出是什么？如果做错了，最早会在哪里暴露？把答案记录下来，它们将成为你实际项目中的检查清单。
核心银行迁移不是一次技术升级，而是一次涉及业务、数据、组织和治理的系统工程。本章建立的整体框架，将作为后续所有具体方法的锚点。接下来，我们将从现状评估开始，进入迁移规划的第一个实操阶段。