中小银行新一代核心银行系统基础架构方案设计探讨四个方面

本期的交流重点围绕四部分进行探讨：

1、【核心系统进行改造升级的必要性方面】；
2、【核心系统改造升级的思路和方法方面】；
3、【核心系统基础架构发展思路方面】；
4、【核心系统容灾建设方面】

【核心系统进行改造升级的必要性方面】

Q1：中小银行核心系统如何满足丰富多变的产品需求？

A1：我想这是每一个银行在现阶段都会遇到的问题，一层不变的金融产品已经不适合现代金融的发展了。转而要求的是快速变化快速适应市场的金融产品，包括利率的灵活性，包括储蓄以及理财手段的多样化，包括顾客群体的差异化，包括快速顺应金融政策的变化等等。那么这就要求核心系统的设计不能以业务流程为指导思路的紧耦合设计了，而实转为产品工厂模式的设计思路充分解耦。通过模块处理的松散组合形成金融产品才能实现产品的灵活性和快速交付。
A2：做稳后台，做大中台，做活前台。后台是核心银行系统、数据采集系统等。中台是各类产品系统、支付系统。前台是前端系统，如手机银行等。

Q2：银行的核心系统基础架构是不是一定要重构？是部分模块重构还是整体需要重构？

A1：从长远发展来看，其实重构是大家面临的迟迟早早的问题。大部分银行的核心系统都是若干年之前的核心系统，支撑长久不变的传统金融业务是问题不大，单是现在以及未来，金融业务的模式无论从内容上还是从形式上都会逐渐发生颠覆性的变化。总有一天，这种矛盾会严重到必须改变的程度。究竟选择什么样的时机去做这个事情，这是大家面临的问题。但是究竟是全部改造还是部分模块儿改造，这个问题取决于现有核心系统架构的灵活性或者模块化程度如何，如果通过部分模块的的重构以及模块儿的重组能够解决大部分问题，那么久没必要全部重构。但是如果原来的系统耦合性非常高，无法通过模块儿重组的方式来改变业务模式，那么么就需要考虑全部重构了。
A2：系统重构需要注意这是行里驱动的、业务部门驱动的还是科技部门驱动的。不同的驱动方式意味着资源调动能力有非常大的差别。若仅仅是科技驱动，则最好是部分重构，以此组建并锻炼队伍，选择技术合作伙伴，探索合适本行的技术发展路线。而且即便是高层驱动，若是近期没有进行过大规模系统建设，也应小步快跑，从易到难，各个击破，不易齐头并进。

具体到方案设计，宜集思广益，多调研，选取合适的技术方案。应用系统架构与规划也要给予同样重视，不是先进的体系结构一定意味着成功的应用系统。对于业务人员，他们关注的是，在你建设系统期间，他们多久不能提新需求。

【核心系统改造升级的思路和方法方面】

Q1：是重新构建核心系统还是组建双IT架构更稳妥？

A1：新构建核心系统和组建双IT架构,不会冲突,核心系统必须满足未来双IT架构的双活部署,如果核心系统不满足新业务模式需要考虑重构,组建双IT架构是未来数据中心必然趋势,也是银监会规定。

Q2：银行的核心系统基础架构究竟是不是一定要进行微服务架构改造？

A1：微服务还没有准确的定义，与其说是一种架构，不如说是一种理念。微服务的核心诉求是应用或组件独立部署，减少没必要的耦合。如果设计的好，会使一些业务变更不影响其他业务，甚至可以做到灰度部署。但是，微服务到底微到什么程度，则是架构成败的关键。极端的，有将一个系统的每个接口均独立部署，这会加大运维和管理的负担，没有必要。

Q3：如何规划和实施核心系统的升级改造和迁移？

A1：关于核心系统的改造，这是一个很大的解决方案，牵涉到业务、组织架构、开发、基础架构等等诸多方面。说到关键点的话，同样会有很多，但是有一点相信是很多银行都已经碰到过的问题了。传统核心系统的架构在交易业务的设计上对并发性的考虑并不是很完善，往往都是基于账户粒度的交易锁去控制并发，但是在今天互联网时代，很多情况是同一个账户在很集中的时间段内发生了很高的并发。比如说一个企业的微信账户，在同一个时间点会有很多客户消费交易，都会涉及到这一个账户。这个时候就会发生锁等待，甚至更严重的问题。那么解决这个问题一定是需要在核心系统的交易业务设计层面算法进行重构，这样是核心系统在改造或者升级的时候必须考虑到的关键问题点。
A2：核心系统改造，安全是最重要的。整体规划和实施过程中，方案设计、编码其实是相对简单和直接的过程。协调多个部门和系统，安全、正确的迁移数据，很可能会确定项目的成败。核心系统的数据，若不是数据结构设计过差，则不迁移好于平移，平移好于迁移。通过良好的应用设计抽取出通用业务逻辑，与具体的数据库结构解耦，进而做到少迁移数据而升级系统，这应该是上上之选。而且，若是数据可能涉及到客户密码、秘钥的，则数据迁移尤其需要认真设计。

Q4：银行的核心系统去耦化建设是应该从业务层面为出发点还是应该以基础架构层为出发点？

A1：我理解你所谓的去耦化是减少银行系统的紧耦合状况。基于历史原因，部分银行系统可能是大而全的系统，涉及多个客户业务模块，时间久了，修改难度越来越大，到了牵一发动全身的地步。这是许多银行进行核心系统换代的首要原因。从设计和实施的角度讲，必须综合考虑业务层面和架构层面。业务应该是业务发展需要，架构则分为应用架构和体系架构（物理架构）。架构原则易说，但能否成功则源于就事论事的深入分析。至少不要陷入这个误区，过分强调某个概念。例如过分强调微服务架构，把系统拆的太散。

Q5：银行新一代核心建设架构设计如何选择？

A1：现阶段，个人认为银行的核心系统改造或者重构还没有一套完整的体系或者标准让大家遵循。基本上都是各自探索阶段，虽然核心系统的业务模式基本一样，但是不同的银行有不同的区域性特点和业务特点，不完全相同。说到重构或者变革，其实最大的触动力就在于互联网业务模式的冲击。在于产品交付效率、业务灵活性以及并发支持能力等方面的挑战。但是要想解决这些问题，仅仅从基础架构上下功夫是远远不够的，不是说以容器架构代替传统架构就可以解决这些问题，也不是说上一个NOSQL数据库就可以解决这些问题。问题的根源还在于业务模式的固有模式。所以当我们现在面临传统业务和互联网业务同时存在并且相互促进的场景下，首先要分析的就是两种业务在行内未来的发展方向和模式，当业务分析透彻之后，组织架构的改革、应用平台的变革以及基础架构的重构才能更优化的进行。否则局部的优化和变革只能导致我们在问题边缘徘徊。

【核心系统基础架构发展思路方面】

Q1：数据中心弹性负载均衡的设计方案？

A1：前端，中间件和数据库的负载进行详细的数据分析, 保留一定的资源给突发事件。

调整负载一般会使用虚拟化技术自动完成,而不是人为参与在金融数据中心中负载调整和互联网不同,一般是预留资源,避免大负载流过时到导致的系统延迟,而大行对预留资源十分慷慨,即使系统高峰也只会使用系统80%的资源，另外20%的资源预留,避免其他系统宕机导致的vm漂移使负载突然增加。

A2：前端最好还是使用f5好一些，一来f5有完整的云解决方案，不仅可以对前段负载，还能对负载资源本身做弹性调度（参考f5的CE），另外f5的售后和技术支持是很OK的，开源的总是不那么放心，尤其是4——7层的应用交付设备，容易出BUG，除非有一个专门的开发团队来做支持和版本更新。

Q2：新核心系统服务器选型疑问？

A1：首先，核心系统数据库采用的还是关系型数据库，不管是db2还是oracle，总之是关系型数据库。既然是关系型数据库，在金融交易业务这种场景下，依靠横向节点的扩展来增强整体处理能力的可能性不太大。因此考虑到未来业务发展扩张的需要，还是要选择纵向处理能力比较强，稳定性比较好的硬件服务器来支撑。具体什么品牌可靠，业界自有公认。

其次，核心系统应用目前已经有很多版本可以实现一定程度的分布式处理，尤其是联机业务。批量业务可能扩展性还不是特别成熟。而且相对于数据库节点来讲，应用节点承担的负载压力要小很多，所以应用节点的硬件选型倒是完全没有说哪个品牌一定不能用，国内的很多X86品牌服务器完全可以胜任，而且性价比非常好。
A2：传统银行大多还是采用IBM\HP等小型机或大机来承载核心系统的业务，浪潮、曙光、新云东方、华为等基本上没有很好的小型机可供选择，只有x86服务器供选，但目前传统银行中应该还没有哪家是使用x86服务器去搭建核心系统的。
个人认为新一代核心系统最先要做的是业务的解耦剖分，之后在对拆分出的各个业务选择合适的架构去部署相应的业务系统，目前各家银行的核心系统业务还是比较臃肿的，在业务没有做好拆分前，系统架构应该不会有大的调整，所以国产的设备很难大规模进入各家银行核心系统建设的采购清单中。

Q3：新一代核心系统如何选型设计？有没有成功典型经验可供参考？

A1：不同银行对于核心系统定义的范围不同，改造的难度、范围也不同，这点很重要。目前已经完成改造的大行，都经历从过去以引进国外系统、自己消化改造为主，到自主开发建设的过程。国内大型股份制商业银行也大多经历的此类过程。所以可以看出，实施如此重要、难度的工程，逐步积累经验，形成一定规模的人员队伍是极其关键的。没有完全引进的系统，也没有完全合脚的鞋，合适的系统都是要自己参与的。建议根据自身业务规模选取业内比较成熟的构架，组成业务人员、开发人员、运维人员、厂商参与的项目作战团队，才好实施核心改造。架构选型目前已经有很多种成熟方案，适用不同规模和要求的银行。

Q4：银行的核心系统采用的多数为单一的关系型数据库架构，如何将NOSQL的优势融入形成混合格局？

A1：银行的核心系统一般以联机业务为主，这些业务的特点是大并发、低延时，频繁的增删改，对事务一致性要求严格，这类业务适合关系型数据库，不适合NoSQL。对于联机批量和EOD批量场景，则可以考虑，但需考虑从关系数据库中抽取数据到NoSQL的策略。目前，银行的NoSQL一般应用在非客户业务，用于监控类、统计类等对客户影响小，实时性要求不高的场景。
A2：首先明确各个nosql产品的优势是什么？结构灵活？分布式架构？再看业务特征和需求是什么？频繁表结构变更？海量数据？数据类型多样不确定？这两个问题确认后，根据自己业务需求选择合适的nosql产品目前银行业已使用nosql的比如说单一视图使用，日志分析，CMS，客户管理等系统等等。核心系统的话短期内不太建议直接切换至nosql。

Q6：中小银行核心系统架构中如何逐步实现核心软硬件国产化？

A1：所谓软件，包括核心系统应用软件、中间件以及数据库等。应用软件的国产化，这个早就实现了。大部分银行的核心系统都是国产开发商完成的，比如常亮。但是中间件和数据库的国产化，我想这个事情不是那么容易，或者说短时间内几乎没有可能。至于硬件方面，有些小规模的新建的银行已经实现了完全的X86化。但是大体量的银行还是不行。随着国内硬件厂商的不断发展，或许逐渐可以取代，但是这也是一个漫长的过程。最先取代的应该是核心系统的应用节点，只要应用系统能实现稳定的分布式架构，那么联机应用很容易迁移到X86平台。但是批量可能处理起来比较麻烦，除非批量处理可以从应用上切分；但是数据库的替代，对于大体量的银行来讲，短期内可能性不大。

Q7：核心业务系统数据库服务器选型？

A1：数据库选型首先要基于项目的战略目的和架构选型，还要考虑项目周期、资源情况。在目前的银行领域里有多种选择，很多银行使用IBM的产品，也可以采用x86架构作为数据库服务器。使用IBM的产品可以参考IBM提供的最佳实践。若使用x86产品，则需要采用分布式架构体系，因为x86单机性能和可靠性均有限，所以使用x86做数据库服务器一般采用多机分布以及主备同步模式。而且，还要根据将要承载的数据量以及性能要求，合理规划机器的数量和部署。

Q8：在物理架构和资源池架构混合的环境当中，究竟如何进行基础架构的变革才能谋求长远发展？

A1：参考ibm软件定义环境完成云环境部署,目前混合管理模式只是过渡,新建数据中心都是以池的方式完成计算资源供给。未来几年非关键业务会使用容器技术进行技术试探，关键业务和核心和目前技术栈不会有太大变化,容器技术和serverless技术那个先使用在金融关键业务还在讨论中。云数据库会替换目前本地数据库系统。

Q9：新核心系统建设过程中，NAS或对象存储的双中心双活读写的方案建议？

A1：对于非结构化数据来讲，通常有两种存储方式，一种是传统的NAS架构，另外一种是基于分布式技术实现的对象存储。对于传统的NAS架构来讲，要想做到实时同步只能通过存储网关的形式去做。如果是对象存储架构的话，那么关键的是要看双数据中心之间的网络质量如何，如果质量绝对好的情况下可以尝试做跨中心的集群。如果质量不够好的话，只能做到集群之间的异步复制。话说回来，非结构话的数据为什么一定要做到实时同步呢？从银行的业务本身来讲，非结构化数据无非就是信贷系统、票据系统、影像系统、理财系统当中的一些票据，这些票据信息的结构化信息都在关系型数据库当中，存在NAS上的仅仅是一些真正的凭据而已，主要用途无非就是一些审核、历史查询之类的业务。这些业务完全没有那么苛刻的时间窗口要求，而且只要有这些数据的结构化信息，非结构化的这部分是完全可以通过其他方式补齐的。所以与结构化数据相比，完全没有必要花费很高的成本把这部分数据也做到实时同步。能做到异步同步，尽量缩小数据差量就可以了。

【核心系统容灾方面】

Q1：银行核心系统、渠道类系统如何做到多中心数据多活，各中心数据一致性如何保证？

A1：同城系统一般距离60公里左右，采用独立光纤，网络稳定，交易时延完全可以接受，所以在同城进行双活，可选择的方案很多。对于核心银行系统，各个层面均要保证没有单点，但清除单点不一定要同城，有些部件仅需要在不同机架上做HA。银行必须保证数据安全，所以数据库系统必须进行同城双活、异地灾备。主流数据库系统均提供了多种类型的方案供选择，其中，采用半同步方式的主从复制方式是一种比较经济、可靠的选择。数据库集群功能强大，甚至可以提供分布式事务一致性，但是并发数、吞吐量有限，需要按需选择。分布式数据一致性有多种选择，最终一致性或是基于二阶段提交的数据一致性。二阶段算法很多系统均提供，但是选择需要考虑并发量、吞吐量，可以在最终一致性不宜使用的场景下使用。最终一致性是比较好的解决方案，一般借助异步消息机制实现，在网络良好、交易无剧烈波动的情况下，可以接近同步效果，客户体验很好，实现难度不高。但无论采用哪种一致性，交易本身应支持重入或补偿机制，不应仅仅依赖技术保证业务一致性，这是应用系统应该做的。
A2：就金融行业来讲，以目前的业务规则和科技现状来讲，实现异地多活（多个中心数据实时同步）没有可能。问题的关键还是在于远距离数据传输质量和延时。如果说到别的业务场景来讲，如果数据的要求可以容忍最终一致性要求，那么多活倒是可以在一定程度上实现，但不是绝对的微观IO的多活，只是从业务层面上感觉到的多活。

Q2：关于银行核心系统两地三中心的双活新架构如何规划实施？

A1：关于金融行业的两地三中心这个话题，应该算是一个比较常见的话题了。关键的几个点如果都能把控住，做合理的选型。数据复制架构的选择，网络及应用层跨中心的数据流切换，跨中心集群的仲裁问题等。至c于说新核心系统的容灾架构如何去规划设计，这个完全取决于新核心的应用架构和业务模式。

假设只是现有核心系统的升级优化，那么容灾架构不会有任何质的改变，还是要基于从传统的容灾架构去做。避免不了的就是对同城两个中心之间的传输进行深入讨论。假设新核心系统完全将互联网的业务模块儿隔离了出来，将账户分级从数据库层分离了。这部分业务模式由强一致性要求转换到了谋求高并发的最终一致性模式，那么互联网模式的新核心架构可能就是一种全新的跨中心分布式集群部署了。

A2：很多银行的核心系统进行了双活架构设计、两地三中心部署，很好的保证了系统安全性、稳定性，锻炼了运维队伍，进一步带动了很多新技术的引进和落地。双活架构首先要覆盖关键系统，可逐步扩展到其他系统。双活要去除各种类型的单点风险，需要重点关注网络、应用与数据安全。采用F5与Nginx软硬搭配的方式解决反向代理与负载均衡，一些常见的服务治理组件如dubbo也有利于去除单点风险。在双中心部署服务器集群是很好的方案，同时业务要尽量设计为无状态服务。主流的数据库均提供了数据同步或集群的方式，集群方式功能强大但对网络比较敏感，同步方式有同步、半同步、异步方式可以选择。最后，最重要的是，监控系统、自动化切换能力必须跟上，而且要定期进行主从切换。

Q3：新核心系统在同城灾备建设中数据同步类型选择哪种？

A1：数据同步类型,主要分两种：数据库级别，存储级别。数据库级别有份 日志方式和数据内部同步方式；存储级别,需要厂商的相关技术emc srdf, ibm的svc卷同步等 ds也有自己的mirror技术。存储层数据同步属于比较底层的数据同步策略，灾备端将数据拉起到可以状态过程比较复杂。数据库层同步启用灾备端过程相对比较简单可控。

Q4：新核心系统建设过程中，基于Oracle数据库，如果实现双心中同时对外提供读写服务？

A1：说起基于ORACLE的容灾，主要有两种方式：1. 基于Oracle ADG实现的主备库方式，主备库可以做到同步复制和异步复制，主要取决于网络质量，一般都设置为最大性能或者可用模式，实际上网络质量好的情况下，数据的差异就在秒级。这种方式优点就在于安全可靠，缺点就在于人工干预以及应用配合切换。2. 基于Oracle RAC实现的集群模式，可以是extended rac或者是基于存储整合之后架构实现的rac拉伸。这种方式对rac节点之间的心跳网络要求特别苛刻，一旦心跳网络有问题带来的后果非常严重。而且在某些热点数据非常大而且集中的场合下，基本不建议这么干。这种方式优点在于完全的自动化切换，缺点就在于条件要求苛刻风险高。而且一定要根据具体业务特点分析是否可做。