本次大会官网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、对账出现问题及时报警并交由人工处理。
三、核心银行架构在国内和海外的影响因素对比
客户问题
由于海外(尤其东南亚)的客户没有统一的身份识别号，也并没有像国内的实名认证机制，针对这种情况。多变的客户信息校验思路。用户使用新平台旧渠道。
支付问题
海外市场第三发支付机构复杂多样，增长迅速，需要做适配改动的频率很高。尤其需要考虑内部领域的业务逻辑的共性和差异性。外部差异如何在频繁改动中降低对支付整体系统的影响。支付渠道本身能力/设施的良莠不齐
部署问题
对于云部署的接受程度较高、数据托管服务（托管模式的差异）、数据保护（微服务由于数据保护需要而不得不采取的折中或补偿）、跨境问题。
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上大数据知识点，真正体系化！
由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新
系化！**
由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新
扫一扫
513
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
