中小银行核心系统架构如何解决去耦和扩展性难题？ | 最佳实践
中小银行核心系统基础架构现在普遍存在耦合性太高、资源的物理格局限制、基础架构扩展性存在短板、数据安全技术局限性等问题。以下是针对相关难点问题，社区专家赵海、saltyp、邓毓等进行的实践分享，供大家参考。
并可参考文章：《中小银行如何做好核心系统基础架构实践规划》（点击标题可阅读）
一、业务及应用层面
【问题】：交易和核算的分离问题？
【回答】：
交易和核算分离，其实说白了，就是先让客户将业务做完，而账务处理却在晚上通过跑批的方式处理。这样就是借贷平衡记账了，比如我们现在的一个缴费交易，首先从客户账务上扣钱，然后记到一个对应的内部科目里去。这样就实现了一借一贷。但是这样的记账有个弊端。就是客户可以很多个，但是对应的内部科目却只有一个，由于每次记账这个内部户都是被锁住的（防止脏数据），那么如果在大量并发交易的时候，很多客户都在缴费，就会出现锁表的情况，造成业务中断。还是这个缴费功能，白天客户缴费了，客户金额立刻扣减，同时登记一个客户台账。等到晚上批处理来执行的时候，批量的将这个台账数据跑入内部户中完成记账处理。这样从客户的角度来看，金额实时减少了，说明缴费成功了，而对于账务处理，在晚上按顺序批量执行，不会出现大量抢占内部户资源的情况。
【问题】：总账系统从传统核心剥离，前期的梳理工作？
【回答】：
总账系统从核心剥离要看剥离到什么程度了，剥离得太多，那原来的核心就不叫核心了，涉及到具体业务层面的术语我不太清楚，个人理解是，要剥离就得梳理总账系统的组成，这些组成之间又有哪些关联性，剥离之后如何继续进行关联，跨系统关联的性能和并发如何考虑；应用系统（无论是外部交易系统还是核心内部交易系统）对这些组成的交易事务是在一个事务内部还是分开多个事务（如果这些组成剥离开来，各系统的交易事务也得考虑到剥离）；剥离后的批量问题如何解决（原来集中式批量，现在分布式批量）；剥离后原核心的定位和新核心的位置（两个或多核心间其实也是紧耦合的，毕竟总账中的子集还是要依赖于总账的，如果剥离了子集，核心总账还是要出来获取子集的）；如何分步式，稳妥的进行剥离，也就是剥离方式的安全有序性问题，等等。
【问题】：核心系统那些模块高耦合？如何梳理去耦思路？
【回答】：
耦合性最大的应该是账务系统，清算头寸等，几乎只要是交易系统，只要涉及到账务，也就是钱的交易，都要记账，那就得去核心系统的数据库里记，取核心系统数据库里查，否者各个系统都管着各自的账务，那这个账务同步的开销就更大，没法进行下去了，就想区块链那样，账务交易实时性能更是无法保证。所以说交易系统和账务系统是高度耦合的，无论这个交易系统是在核心内部还是核心外围，都有这样的问题，所以问题的核心不在于剥不剥离交易系统，而在于剥不剥离账务类系统，也就是双核心或者多核心其实做的事情都是一件事，就是账务类系统剥离，有的把清算头寸从核心剥离，有的把互联网账务处理从核心剥离等等，为的就是减轻传统核心的压力，组建多核心，但可能也会带来很多新的问题，剥离的过程也是需要仔细梳理和思考的，比如账务和清算头寸是紧耦合的，头寸剥离出去后，核心还可能要出去取这个头寸信息，那此时的核心就不是真核心后台了，而是多核心共存，互相融合的了，这个融合又可能带来很多新的问题和思考，总之不是那么轻易的事，任重道远，稳重求进。
【问题】：应用架构解耦？
【回答】：
这个解耦其实是核心系统本身的解耦，因为传统核心系统将联机业务和账务业务结合到一起，非常庞大。而且联机业务本身各个模块之间得耦合度非常高，产品灵活性及架构的扩展性不是非常好。所以这个解耦是说我首先要把核心系统中的总账剥离，然后将联机业务涉及的模块进行重新分析设计，改造为内部耦合性相对小一些的架构，从而可以支撑应用节点本身的分布式部署。并不是说要打破现有的总线架构。
【问题】：去耦合性时不同业务如何设计？
【回答】：
实际上核心系统的去耦主要就是要把总账系统剥离，总账系统从核心剥离出来之后，核心面临的集中式压力就分散，其他交易系统与原有核心系统的架构耦合性就会小，整体架构的耦合性都会降低。同时也为未来互联网的核心交易业务架构的变革提供了条件。业界并没有一个统一的定义，但是有一点可以明确的是银行的核心系统不是一个单一的应用系统，而是一组应用系统的组合。具体包括：存款管理、贷款管理、支付结算、会计处理、总账处理等等。在这些模块儿当中有一个核心的线索可以将其串联到一起就是账户数据，这个账户既有个人的账户也有机构的账户。所有围绕账户产生的一些借贷行为组成了银行核心系统联机业务的流转以及会计实务的处理。今天的互联网时代，很多银行的互联网业务已经成为银行的核心业务。
要解决传统核心的去耦问题，首先第一个需要解决的问题就是根据自己银行的业务发展模式来决定是否将互联网的账户和本地账户进行分离，也就是一类账户和二三类账户的分离。如果我们的二三类账户业务非常庞大，而且发展趋势页也非常明确，那么不仅仅需要核心系统本身的账户分离，更需要业务部门重新来定义二三类账户业务的管理模式和权限归属问题。
接下来，第二个需要解决的问题就是联机业务和总账业务的分离。总账业务系统可以单独切分为一个独立系统，联机业务、信贷业务、支付业务、互联网交易等等这些业务完全成为一中对等的模式来支撑银行的日常金融服务。总账业务系统成为一个单独的可以对接各种业务类型的账务平台，由于它属于账务类系统没有实时提供金融服务的属性，也就不会成为业务服务瓶颈，它的处理只影响银行后台会计事务，属于内部业务。
第三个需要解决的问题就是联机业务系统内部本身的设计。以客户为中心的设计，建立基于全面了解客户能力的客户统一视图，提供客户统一入口的客户服务全面整合。建立组合模式的产品工厂，可以根据业务创新进行产品的灵活组合，而不是单一死板的产品模式。
实现灵活定义的利率工厂模式，根据未来客户服务的市场化建立内部定价体系，提供多维参数化定价体制，提供多为利率组合模式，既可以实现通用计算模型又可以实现特殊化的利率模型。多法人支持，在数据库底层设计中引入法人字段，做到数据隔离。
二、基础架构层面
【问题】：核心系统基础架构选择？
【回答】：
就核心系统的压力和负载，一般采用物理机居多。当然如果是物理机本身的处理性能非常高，那么在其之上作虚拟化，也有很多案例。传统的核心系统，无论是联机应用还是批量应用基本的部署方式还是物理机的独立格局部署方式，从其他系统的业务请求到核心系统内部请求的处理基本都属于独立格局，这个流程涉及到的请求、调用、处理等事务基本都属于固定模式，没有任何动态分配算法来支撑。我们在核心系统去耦工程当中，非常重要的一个事情就是要解决这种独立部署的格局。首先就是要解决核心系统联机应用的负载均衡支持问题。有些核心系统的设计已经采取了分布式架构，利用一些分布式中间件以及缓存的中间件来实现联机业务请求的分布式部署。这是一种趋势，无论是用Tuxedo软件负载，还是利用F5硬件负载，都应该实现应用层面的负载均衡部署。当然支撑这种部署方式的前提是应用层面必须具备对业务处理逻辑的校验，无论是会话策略还是链接策略，都因该具备交易处理的逻辑校验功能，以支撑核心系统业务处理的分布式架构。
【问题】：建设核心银行系统是采用分布式架构还是集中式架构？
【回答】：
其实银行的核心系统本身，从应用层面看，就目前的状况来看，应用集中度非常高，但是并不单表说其业务的集中度不可以拆分，比如说联机业务和批量业务，就联机业务来讲完全可以实现分布式部署，就批量业务来讲由于它的业务特殊性，对数据访问的集中程度，最好还是跑在集中式的架构下。
从数据层而看，由于交易系统对数据强一致性的要求以及其数据特点而言，必须是关系型数据库，而且关系性数据库中访问的热点相对比较集中，所以数据库层面来讲，其横向扩展性有，但是并不是非常强，也是目前不能立刻解决的问题。
三、数据层面
【问题】：传统核心系统的数据库如何实现分库分表？
【回答】：
数据量大表的迁移到历史库，表名加一个年份的时间作为新的表名。
水平切分，比如按营业机构分开不同的库；垂直切分，比如按业务功能，卡交易相关的分成独立的库表。
【问题】：小型类金融机构核心架构设计时对备份和灾备设计应注意哪些因素？
【回答】：
一、灾难恢复能力有不同的等级，备份是属于灾备的一种较低等级要求。
1.国家对金融行业数据中心的安全性非常重视，陆续出台了容灾建设的标准和规范：
2006年4月，《中国人民银行关于进一步加强银行业金融机构信息安全保障工作的指导意见》（简称123文件）（中国人民银行）；
2007年5月，《商业银行操作风险管理指引》（银监会）；
2007年11月，《信息系统灾难恢复规范》GB/T 20988-2007（国家质检总局）；
2008年2月，《银行业信息系统灾难恢复管理规范》（中国人民银行）；
2008年4月，《银行业重要信息系统突发事件应急管理规范（试行）》（银监会）；
2009年6月，《商业银行信息科技风险管理指引》（银监会）；
2010年4月，《商业银行数据中心监管指引》（银监会）。
2.人民银行监管要求：灾难恢复工作情况应在每年年底前向中国人民银行报备：
灾难备份中心建设及变更情况
年度灾难恢复演练情况
3.银行信息系统灾难恢复最低要求：
第一类：5级，RTO<6小时，RPO<15分钟
第二类：3级，RTO<24小时，RPO<120分钟
第三类：2级，RTO<7天
4.银监会颁布的《商业银行数据中心监管指引》监管要求：
总资产规模一千亿元人民币以上且跨省设立分支机构的法人商业银行，及省级农村信用联合社应设立异地模式灾备中心，重要信息系统灾难恢复能力应达到《 信息安全技术信息系统灾难恢复规范》 中定义的灾难恢复等级第5级（含）以上；
其他法人商业银行应设立同城模式灾备中心并实现数据异地备份，重要信息系统灾难恢复能力应达到国标第4级（含）以上。
灾备中心异地模式是指灾备中心与生产中心处于不同地理区域，一般距离在数百公里以上，不会同时面临同类区域性灾难风险，如地震、台风和洪水等。
二、云架构下基于存储的灾备或者备份方式不一样
1、基于存储的灾备属于底层的存储复制技术，不同厂商的存储产品支持不同的数据灾备方式，包括同步复制或者异步复制，其要求的传输带宽和资金投入也比较高，RPO=0或者较小，
2、而备份则属于文件、数据库层面的数据复制，一般定期备份，根据业务重要程度不同，1天或者1周，甚至1个月备份一次，其RPO较大，投入也相对小。
【问题】：如何建设双核心系统？
【回答】：
随着银行业务逐步移动互联网化，银行核心业务系统的功能和性能要求也急剧发生变化：
1、银行传统的存贷汇业务逐步扩展了理财、投顾、消费金融、P2P等等各类业务；
2、传统金融的使用频率由每个月几次存取款变成了每天高频次的金融交易服务。
针对这些新情况，人总行特别制订了二三类账户分类体系，以应对互联网趋势下金融交易的小额、多元、高频、高性能要求特点。各银行业金融机构也对银行核心系统进行了改造，或者建设双核心系统。至于如何建设双核心系统，则需结合各家银行的需求和目前面临的痛点。比如：是否目前的核心系统无法对接某些互联网化业务功能？是否目前的核心系统性能在某些时期无法达到互联网化高并发的要求？等等。传统的核心系统基于几十年来的积累和实践经验，一般采用传统IT架构模式，追求高稳定性；而互联网化核心则更加关注业务的高并发能力，快速响应和迭代开发，IT架构也学习互联网企业的分布式架构。互联网化核心的建设不仅仅需要考虑应用架构的业务逻辑，如账务分离与合并，会计科目的记账等等，还要考虑互联网化IT基础架构的高可用性和高并发性，达到核心重要系统的RTO/RPO要求，容灾架构等等。
推荐阅读：
点击文末阅读原文关注社区 “银行”技术主题 ，将会不断更新优质资料、文章，您也可以前往提出疑难问题，与同行切磋交流。
下载 twt 社区客户端 APP
与更多同行在一起
高手随时解答你的疑难问题
轻松订阅各领域技术主题
浏览下载最新文章资料
长按识别二维码即可下载
或到应用商店搜索“twt”
*本公众号所发布内容仅代表作者观点，不代表社区立场