📫 作者简介：小明Java问道之路，专注于研究 Java/ Liunx 内核/ C++及汇编/计算机底层原理/源码，就职于大型金融公司后端高级工程师，擅长交易领域的高安全/可用/并发/性能的架构设计与演进、系统优化与稳定性建设。

📫 热衷分享，喜欢原创~ 关注我会给你带来一些不一样的认知和成长。

🏆 InfoQ 签约作者、CSDN 专家博主/后端领域优质创作者/内容合伙人、阿里云专家/签约博主、51CTO 专家 🏆

🔥 如果此文还不错的话，还请👍关注 、点赞 、收藏三连支持👍一下博主~

前言

2022 年 9 月 26 -27 日，有幸参加极客邦科技旗下 InfoQ 中国举办的 ArchSummit 全球架构师峰会（杭州站）。

本专栏是以“微服务架构设计模式与实践”为主题，经过推行多年，确实有很多应用程序落实了微服务架构，不过任有一些应用程序还处在 Monoliths 模式，而另一些则介于两者之间，而出现这样的情况，基本上就是公司在决定采用微服务和 Monoliths 时的技术折衷。这个专题，会相对聚焦在可落地的微服务架构经验分享。

大会内容涵盖人工智能、云计算、微服务、元宇宙、智能运维、大数据等主题，为企业管理者、架构师与开发人员提供了行业前沿视角与参考，帮助企业在数字化时代赢得先机，把握竞争优势。

本次大会官网ArchSummit 全球架构师峰会（杭州站），感兴趣的同学可以自行了解，错过杭州站的同学可以去了解一下北京站 。

本文导读

由平安金融壹账通吕书峰老师带来银行核心系统的微服务设计验分享。

微服务作为现代互联网应用的主流架构风格，已经在很多行业应用的实践中获得广泛的成功，而银行核心系统由于其复杂性和风险敏感性，其主流架构依然在从单体式 SOA 到真正的微服务分布式架构的转型期。

本次分享主要介绍壹账通在银行核心系统领域的微服务架构的设计经验，侧重在几个关键的问题领域。

第一是利用 DDD 方法分析了银行核心系统要处理的几种典型问题，并以利息计算为例阐明 ES 模式的应用；

第二对比分析在核心系统领域国内外在微服务架构应用上的差异；

第三是如何真正做到大幅度降低系统运营成本，这个问题是通过讨论面向云原生的设计要素来看一些案例如何做到的；

第四讨论微服务应用在和众多的传统和多变外围系统对接时的问题，通过以支付平台的外部对接为例讨论。从以上几个方面提供在核心银行领域内的最佳实践的参考。

一、核心系统的业务领域整体介绍

云原生的数字化银行核心平台的整体产品视图，如下所示：

整套业务采取分层架构体系组成，自底向上为 Professional Service（专业服务）、Infrastructure（基础设施）、云原生基础核心平台、基于基础核心的中台产品层、场景金融端产品和服务以及高效运营支持。

整个搭载在云平台 Cloud Platform（IaaS | PaaS | Compliancc&Security）上面

由此可见数字化银行核心平台的整体产品、业务量是极其复杂的。

最终采取微服务设计的基础有 DDD（领域驱动设计），下面对核心系统的业务领域模型分析，最终核心系统设计核心银行领域模型，由下所示

核心引擎由服务编排、流控制、调度器和 DSU 控制器组成。

在核心引擎的基础上，开发了基本的核心银行服务，涵盖存款、贷款、客户信息、会计和常见功能，均标准 API 提供服务

为运营效率提供核心统一后管；为最佳用例实现的多个设计模式，例如在利息计算的模块上应用事件源解耦原有实现实时批处理。

DSU 用于管理分布式计算需求以及多实体。

二、核心系统微服务转型的痛点举例分析

1、核算

核心系统的微服务转型–核算的问题，核算与交易分离为什么？性能，扩展性，适应性，易管理；全行级统一 vs 按领域分体？涉及产品、机构管理，地区和法人实体……

根据以上问题，系统要从多角度考虑：个人、企业、行业特点、业务模式、产品服务、管理要求等等，核算的种类还有异步核算、日终核算、交易核算。同时核算的方法还有：明细核算（按账户进行核算，反应资金运动详情）、综合核算（按科目进行核算，反应资金运动概况）。

根据以上问题、业务特点和复杂性分析得出，设计要点：

1、解耦前端业务与后端账务

2、账户体系与服务接口

3、异步记账日志是关键

4、补偿机制——实时/准实时/offline

2、事务处理

总体的原则，就是尽量避免分布式事务

普通交易

1、利用 AT 模式，以最小的代价实现分布式事务。；2、AT 模式在正向交易下可实现一定程度的高并发；3、在热点账户情况下存在脏写问题，Seata 给出的解决方案是乐观锁，这个在热点账户场景下不适用。

高频热点交易

1、使用 Saga 模式+事后对账机制；2、工作量较大、仅适用少数交易场景；3、在正交易过程中可以保证高并发；4、可能会产生某些情况下余额出现负值的情形。

事后对账机制

1、作为分布式交易的兜底机制；2、对账出现问题及时报警并交由人工处理。

三、核心银行架构在国内和海外的影响因素对比

客户问题

由于海外(尤其东南亚)的客户没有统一的身份识别号，也并没有像国内的实名认证机制，针对这种情况。多变的客户信息校验思路。用户使用新平台旧渠道。

支付问题

海外市场第三发支付机构复杂多样，增长迅速，需要做适配改动的频率很高。尤其需要考虑内部领域的业务逻辑的共性和差异性。外部差异如何在频繁改动中降低对支付整体系统的影响。支付渠道本身能力/设施的良莠不齐

部署问题

对于云部署的接受程度较高、数据托管服务（托管模式的差异）、数据保护（微服务由于数据保护需要而不得不采取的折中或补偿）、跨境问题。

四、降低运营成本-从微服务到开放银行

总结

本文围绕平安壹账通在银行核心系统领域的微服务架构的设计经验，以及如何通过云原生与微服务结合显著降低运营成本来学习已落地的微服务架构经验分享。

感兴趣的同学可以自行了解其中更加详细的信息（微服务架构设计模式与实践），错过杭州站的同学可以去了解一下北京站。