中小银行核心系统去耦和扩展性架构设计.docx

? ? ? ? ? ? ? ? 中小银行核心系统去耦和扩展性架构设计 最佳实践 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?? 中小银行核心系统基础架构现在普遍存在耦合性太高、资源的物理格局限制、基础架构扩展性存在短板、数据安全技术局限性等问题。 一、业务及应用层面 【问题】：交易和核算的分离问题？ 【回答】： 交易和核算分离，其实说白了，就是先让客户将业务做完，而账务处理却在晚上通过跑批的方式处理。这样就是借贷平衡记账了，比如我们现在的一个缴费交易，首先从客户账务上扣钱，然后记到一个对应的内部科目里去。这样就实现了一借一贷。但是这样的记账有个弊端。就是客户可以很多个，但是对应的内部科目却只有一个，由于每次记账这个内部户都是被锁住的（防止脏数据），那么如果在大量并发交易的时候，很多客户都在缴费，就会出现锁表的情况，造成业务中断。还是这个缴费功能，白天客户缴费了，客户金额立刻扣减，同时登记一个客户台账。等到晚上批处理来执行的时候，批量的将这个台账数据跑入内部户中完成记账处理。这样从客户的角度来看，金额实时减少了，说明缴费成功了，而对于账务处理，在晚上按顺序批量执行，不会出现大量抢占内部户资源的情况。 【问题】：总账系统从传统核心剥离，前期的梳理工作？ 【回答】： 总账系统从核心剥离要看剥离到什么程度了，剥离得太多，那原来的核心就不叫核心了，涉及到具体业务层面的术语我不太清楚，个人理解是，要剥离就得梳理总账系统的组成，这些组成之间又有哪些关联性，剥离之后如何继续进行关联，跨系统关联的性能和并发如何考虑；应用系统（无论是外部交易系统还是核心内部交易系统）对这些组成的交易事务是在一个事务内部还是分开多个事务（如果这些组成剥离开来，各系统的交易事务也得考虑到剥离）；剥离后的批量问题如何解决（原来集中式批量，现在分布式批量）；剥离后原核心的定位和新核心的位置（两个或多核心间其实也是紧耦合的，毕竟总账中的子集还是要依赖于总账的，如果剥离了子集，核心总账还是要出来获取子集的）；如何分步式，稳妥的进行剥离，也就是剥离方式的安全有序性问题，等等。 【问题】：核心系统那些模块高耦合？如何梳理去耦思路？ 【回答】： 耦合性最大的应该是账务系统，清算头寸等，几乎只要是交易系统，只要涉及到账务，也就是钱的交易，都要记账，那就得去核心系统的数据库里记，取核心系统数据库里查，否者各个系统都管着各自的账务，那这个账务同步的开销就更大，没法进行下去了，就想区块链那样，账务交易实时性能更是无法保证。所以说交易系统和账务系统是高度耦合的，无论这个交易系统是在核心内部还是核心外围，都有这样的问题，所以问题的核心不在于剥不剥离交易系统，而在于剥不剥离账务类系统，也就是双核心或者多核心其实做的事情都是一件事，就是账务类系统剥离，有的把清算头寸从核心剥离，有的把互联网账务处理从核心剥离等等，为的就是减轻传统核心的压力，组建多核心，但可能也会带来很多新的问题，剥离的过程也是需要仔细梳理和思考的，比如账务和清算头寸是紧耦合的，头寸剥离出去后，核心还可能要出去取这个头寸信息，那此时的核心就不是真核心后台了，而是多核心共存，互相融合的了，这个融合又可能带来很多新的问题和思考，总之不是那么轻易的事，任重道远，稳重求进。 【问题】：应用架构解耦？ 【回答】： 这个解耦其实是核心系统本身的解耦，因为传统核心系统将联机业务和账务业务结合到一起，非常庞大。而且联机业务本身各个模块之间得耦合度非常高，产品灵活性及架构的扩展性不是非常好。所以这个解耦是说我首先要把核心系统中的总账剥离，然后将联机业务涉及的模块进行重新分析设计，改造为内部耦合性相对小一些的架构，从而可以支撑应用节点本身的分布式部署。并不是说要打破现有的总线架构。 【问题】：去耦合性时不同业务如何设计？ 【回答】： 实际上核心系统的去耦主要就是要把总账系统剥离，总账系统从核心剥离出来之后，核心面临的集中式压力就分散，其他交易系统与原有核心系统的架构耦合性就会小，整体架构的耦合性都会降低。同时也为未来互联网的核心交易业务架构的变革提供了条件。业界并没有一个统一的定义，但是有一点可以明确的是银行的核心系统不是一个单一的应用系统，而是一组应用系统的组合。具体包括：存款管理、贷款管理、支付结算、会计处理、总账处理等等。在这些模块儿当中有一个核心的线索可以将其串联到一起就是账户数据，这个账户既有个人的账户也有机构的账户。所有围绕账户产生的一些借贷行为组成了银行核心系统联机业务的流转以及会计实务的处理。今天的互联网时代，很多银行的互联网业务已经成为银行的核心业务。 要解决传统核心的去耦问题，首先第一个需要解决的问题就是根据自己银行的业务发展模式来决定是否将互联网的账户和本地账户进行分离，也就是一类账户和二三