模块化核心银行系统:为什么设计良好的单体架构胜过过早的微服务化

每一个核心银行项目最终都会面对同一个问题:是从第一天就采用微服务架构,还是先用一个模块化单体架构,随着真实需求的出现再逐步演化为独立服务?

最常见的错误

按技术层而非业务领域进行拆分——比如一个"数据库"服务、一个"规则"服务、一个"API"服务。其症状总是相同的:关闭一个账户需要跨五个不同服务编排同步调用,其中任何一个服务出现故障都会导致整个操作失败。

在实践中真正站得住脚的限界上下文

在成熟的核心银行平台中,长期保持稳定的边界通常是:

• 账户与总账 —— 会计层面的唯一真相来源,独立且可审计。
• 支付方式 —— PIX、Boleto 票据、转账、卡片:每一种都有自己的生命周期,但共享同一个总账。
• 信贷 —— 决策引擎与合同管理,对规则版本管理有很强的需求。
• 合规 —— 身份核验、反洗钱与监管报告,需要观察所有领域,但不能与它们产生耦合。

以模块化单体作为起点

从模块化单体开始——模块之间具有清晰定义的代码边界,通过明确的内部契约进行通信——可以让系统在规模或团队结构真正需要的地方,再演化为独立服务,而不必在没有收益的地方,提前承担网络调用和最终一致性带来的成本。

拆分为微服务不再是一种教条,而是一项工程决策,应基于负载数据与团队组织方式做出——而不是出于潮流。