3. 单体架构的典型特征
在核心银行系统的演进历程中，单体架构曾是主流选择。它把账务、客户、产品、交易、报表等模块打包在一个应用中，共享同一套数据库和运行进程。理解单体架构的典型特征，是判断“是否必须迁移、迁移到什么程度”的前提。本节围绕代码耦合、数据库共享、部署单体、扩展瓶颈、故障隔离差五个维度展开，并结合核心银行场景给出识别方法与复盘要点。
一、核心原理：单体架构的五个典型特征
单体架构并非简单的“代码放在一起”，而是一种耦合方式、数据组织方式、部署方式和运行方式的集合。它的典型特征可以归纳为以下五个方面。
- 代码耦合：模块之间通过直接方法调用、共享实体类、公共工具类相互依赖。例如转账交易直接调用账务记账类，账务类又依赖客户信息类，形成编译期强耦合。修改一个字段可能引发多个模块重新编译和回归测试。
- 数据库共享：所有模块访问同一个数据库实例，表之间通过外键、触发器、存储过程紧密关联。账务表、客户表、交易流水表往往被多个模块直接读写，数据边界模糊。
- 部署单体：整个应用打包为一个WAR或JAR，任何一个小改动都需要全量构建、全量部署、全量重启。核心银行系统通常有严格的变更窗口，这导致发布频率低、回滚成本高。
- 扩展瓶颈：只能整体水平扩展，无法按模块差异化扩容。例如“查询交易”压力大，但“开户”压力小，却必须同时扩容整个应用，资源利用率低。
- 故障隔离差：一个模块出现内存泄漏、线程阻塞或慢SQL，会拖垮整个进程。报表导出占用大量内存，可能导致联机交易超时，故障影响面被放大。
核心判断：单体的根本问题不是“代码量大”，而是“变更影响面不可控、资源无法按需分配、故障无法被限制在局部”。这三点决定了迁移的必要性和优先级。
二、方法流程：如何识别单体架构的耦合与瓶颈
在规划迁移之前，需要先对现有单体进行“体检”。建议按以下流程操作，输出可量化的现状基线。
- 代码依赖分析：使用依赖分析工具扫描包、类之间的调用关系，识别循环依赖和高扇入/扇出模块。重点关注账务、客户、交易三个核心包。
- 数据库访问分析：统计每张表的读写来源，找出被多个模块直接访问的“共享表”。例如客户表被开户、转账、查询、报表同时访问，就是典型共享点。
- 部署与发布分析：统计近半年发布次数、每次发布涉及模块、平均回滚时间。若发布频率低于每月一次，说明部署单体已成为业务响应瓶颈。
- 性能与容量分析：采集CPU、内存、线程池、数据库连接池指标，识别是否存在“局部压力拖垮全局”的现象。
- 故障复盘分析：梳理近一年生产故障，标注故障根因模块和影响范围。若多次出现“报表拖垮联机”“单个接口超时导致全站不可用”，则故障隔离差已被验证。
下面是一段用于统计共享表访问来源的示例SQL，可帮助快速定位数据库共享程度：
-- 统计每张表被哪些模块访问（基于慢查询日志或审计日志）
SELECT table_name,
COUNT(DISTINCT module_name) AS module_count,
GROUP_CONCAT(DISTINCT module_name) AS modules
FROM db_access_audit
WHERE access_time >= DATE_SUB(NOW(), INTERVAL 30 DAY)
GROUP BY table_name
HAVING module_count > 3
ORDER BY module_count DESC;
执行后若发现大量核心表被3个以上模块直接访问，说明数据库共享严重，迁移时必须优先做数据边界拆分。
三、案例/场景：核心银行单体的真实表现
某城商行核心系统采用单体架构，账务、客户、产品、交易、报表五个模块部署在同一WebLogic集群，共享一个Oracle数据库。一次典型的生产事件如下：
- 月末报表模块执行大额汇总查询，占用大量数据库CPU和连接。
- 联机转账交易因获取不到数据库连接而超时，柜面出现大量失败交易。
- 运维尝试只重启报表模块，但因为是单体部署，只能整体重启，导致全行交易中断约8分钟。
- 事后复盘发现，报表模块与联机交易模块共享同一连接池，且报表SQL未做限流。
这个案例集中体现了单体的三个特征：数据库共享导致资源争抢、部署单体导致无法局部重启、故障隔离差导致影响面扩大。迁移规划中，该行将“报表与联机交易分离”作为第一批次，优先解决连接池和数据库访问隔离问题。
教学提示：在核心银行场景中，故障隔离差往往比代码耦合更早暴露。因为金融业务对可用性要求极高，一次全站中断的代价远大于代码重构成本。因此迁移优先级应优先考虑“隔离故障”和“按需扩展”，再逐步解耦代码和数据库。
四、误区/复盘：常见认知偏差与纠正
在识别单体特征时，团队容易陷入以下误区，需要提前纠正。
| 常见误区 | 错误认知 | 纠正后的认知 |
|---|---|---|
| 代码耦合等于代码量大 | 只要代码行数多就是单体问题 | 耦合的关键是依赖方向和变更影响面，而非代码量。小系统也可能高度耦合。 |
| 数据库共享必须立即拆库 | 迁移第一步就是分库分表 | 应先做数据访问隔离和读写分离，再逐步拆分，避免一次性拆库引发数据一致性风险。 |
| 部署单体只是发布慢 | 只要加自动化流水线就能解决 | 部署单体的根本问题是无法独立部署和独立回滚，自动化只能缓解不能根治。 |
| 扩展瓶颈靠加机器解决 | 整体扩容就能应对所有压力 | 整体扩容成本高且无法精准匹配局部压力，应按模块差异化扩展。 |
| 故障隔离差是运维问题 | 加强监控和告警即可 | 故障隔离是架构问题，需要通过进程隔离、资源隔离和熔断限流从设计上解决。 |
复盘时建议使用“影响面—发生频率—修复成本”三维矩阵对每个特征打分，优先处理高影响面、高频率、低修复成本的问题。例如“报表拖垮联机”通常影响面高、频率中、修复成本低，应排在第一优先级。
注意：不要为了追求“微服务化”而否定单体的一切。单体在事务一致性、部署简单、开发门槛低方面仍有优势。迁移的目标是解决单体在核心银行场景下的瓶颈，而不是盲目拆分。识别典型特征的意义在于：知道哪些问题必须通过架构迁移解决，哪些可以通过治理手段缓解。
五、可视化：单体架构典型特征关系图
通过上述五个特征的系统识别，团队可以形成一份可量化的单体现状基线。这份基线既是迁移必要性的论证依据，也是后续拆分优先级和验收标准的起点。在核心银行场景中，建议优先处理故障隔离和扩展瓶颈，再逐步推进代码解耦和数据库拆分，确保迁移过程风险可控、业务连续。