随着全球IT产业的飞速发展，金融行业的IT建设逐步成为主导金融企业业务发展的核心驱动力。对于银行的整个IT架构从应用的角度来看，会分为几个层面：渠道层、总线层、交易系统层、数据层等。其中交易系统层是最关键的要素，所有银行业中的借贷业务最终的完成会在交易系统层完成，所有业务的账户信息以及账务都要在交易系统中的一个关键节点中流转和记录，这个关键节点就是我们熟知的核心系统。由此可见核心系统对于银行的重要性，同样核心系统的基础架构规划和实践又是支撑核心系统能够良好运转并且健康扩展的前提条件。本文以中小银行核心系统基础架构为着眼点，深度分析并总结在规划和实践过程中需要解决的一些关键问题，旨在为同业在此类项目建设过程中提供一些启示和帮助。
1. 中小银行核心系统基础架构现状
伴随着信息技术的发展历程，国内的金融行业一直在经历着各种变革。众所周知在银行业内，其核心系统对于银行的重要意义，可以说核心系统的变迁代表着银行业整体信息技术体系的发展。总的来看国内银行业的核心系统发展经历了三个阶段：
第一阶段：七十年代末到八十年代中期，银行的储蓄业务以及对公业务逐渐以计算机代替手工操作，计算机是一个以网点为基础的分散式信息管理域。这个阶段谈不上信息化的变革，仅仅是电脑取代了手动操作，完全是一种分散式的管理模式。
第二阶段：八十年代中期到九十年代末期，这一阶段银行开始通过使用计算机网络技术实现银行部分业务的实时联机处理，并逐步实现了银行在一定区域范围内的数据集中及互联互通；区域集中让所辖银行得以共享数据资源，统一了科目设置，改进了业务流程。
第三阶段：二十世纪初至今，这一阶段即所谓的数据大集中阶段。全国性的银行数据通信网络框架基本建成，各银行的综合业务处理网络相继建成，一个多功能的、开放的银行信息化体系初步形成；核心系统由原来的网状架构统一成总线集成架构，系统间的接口规范以及报文格式等都形成了统一的行业标准，并且这些技术及标准在不断的优化发展过程当中。
国内大部分城市商业银行，中小股份制银行等都是在第三个阶段直接发展起来的。其核心系统的建设也是直接套用既有标准规范进行实施的。应用架构基本遵循着总线架构模式，业务处理层面既承担了后台联机业务处理又承担了银行账务处理；基础架构层面根据具体的业务负载不同基本会采用IBM的大型机、中型机、小型机等物理机模式；数据库层面基本采用的比较成熟的关系型数据库例如DB2、Oracle、Infomix等；高可用架构多数采用的是前一个时代的操作系统层面的双机热备软件实现的主备模式。
2. 中小银行核心系统基础架构现有问题2.1 耦合性太高
从银行的数据大集中到目前来讲，银行业务已经经历了将近20年的发展。在互联网和信息化没有爆发的年代，银行的业务类型相对固定，发展较为稳定。银行的核心系统大部分处于安全性、稳定性以及高效性的考虑形成了大核心或者旁核心的局面，也就是既有存贷产品服务功能又有基础性的公共服务功能还有银行的会计核算功能。近些年来随着互联网以及信息化的爆发式推进，银行的业务受到了越来越大的冲击。
利率的市场化发展要求银行的产品计算模式必须能够经得起灵活性的挑战；金融产品市场化竞争的激烈要求我们的产品及服务必须能够随时创新随时变化；互联网及移动信息化的发展要求银行的支付结算手段必须能够跟得上客户的环境变化；行业标准及国家政策的变化要求银行能够快速适应并变革。我们举几个简单的例子：比如说为了争取客户，对于符合某些条件的客户的存款产品，我们需要定制特殊的利率或者算法，如果我们的核心系统并非基于面向对象或者服务的设计模式来实现的松耦合架构，那么可能会因为我们流程化的产品定义模型以及客户定义模型导致我们对核心系统内部进行较为大的变更；比如说我们面临互利网的环境希望推出有特色的产品来吸引客户，很可能由于核心系统的接口模式固定化导致我们无法快速实现产品的创新和退出；比如说我们面临的营改增问题，如果账务核算和联机业务以及公共处理模块儿能够逻辑隔离，那么这类的问题就不会带给我们核心系统巨大的改动量，也不必为此承担巨大风险。诸如此类问题会有很多，所有的这些挑战都不是过去那个胖核心或者大核心环境能够解决的问题。这就要求银行的核心系统在应用系统层面必须实现对象化服务化的松耦合模式。
2.2 资源的物理格局限制
从系统的基础架构来讲，由于过去那个大而全的开发模式导致核心系统本身的体量非常大。在一个物理计算节点上需要支撑多个相互复杂调用的应用服务。这也就形成了过去的大型机、中型机、小型机的物理格局现状。从单个业务或者交易的处理上来讲，这种架构一定是稳定的、高效的、安全的。
随着信息技术的发展，我相信今天各家银行的大部分系统都已经实现了资源的虚拟化级池化，最起码在应用节点的部署上基本都实现了。至于资源池虚拟化的好处就不用多说了，但是为什么核心系统迟迟没有实现呢？原因有两点：首先是核心系统的体量太大，如果不是新建，很难把握核心系统内部的逻辑关系实现架构的调整。再有就是由于核心系统的体量太大，那么它对资源的需求量也是非常大的，不是单个虚拟资源能够解决的问题。
我们暂不从架构本身的先进性来谈这个问题，我们从服务的角度来考虑考虑。相信核心系统本身承载的几个模块儿：存贷产品、公共服务、客户信息、账务核算。过去这几个模块儿可能相对提供服务的负载相对比较固定，所以一直安全稳定运行了这么多年。但是今天在渠道整合以及渠道创新的冲击下，相信它们各自在日常的运行当中提供服务的频率以及他们需要的负载是存在巨大差异的，而且是在不断变化的，在这种场景下如果继续保持物理资源的独立格局限制，那么必然带来的是应用上和业务上的僵硬。
2.3 基础架构扩展性存在短板
其基础架构扩展性瓶颈主要集中在两个方面，第一个方面就是支撑银行核心系统平台层的扩展性瓶颈，另外一个方面就是核心系统应用层本身扩展性的瓶颈。从平台层本身来讲，由于传统模式下的核心系统的高负载高压力的特点，大多数银行都是采用小型机、中型机、大型机等集中式物理架构。那么今天互联网业务的膨胀式发展必然会引发核心系统基础架构处理能力本身的扩展性要求，主要表现为处理并发以及处理复杂业务逻辑上的需求。这种基础架构本身是不具备灵活扩展能力的。另外一方面由于互联网渠道业务的扩展，金融管理制度的快速改革，金融账户属性本身的多样化发展等因素造成的应用层面本身的变更也变得比以往任何一个时期都会频繁，但是我们传统的核心系统都是会计、产品、总账、联机等模块儿相对比较聚合的状态，任何一个小的改动都可能影响到所有的模块儿，再有就是传统核心系统业务逻辑似乎都有一个通病，就是对并发处理设计的考虑很少，这些因素都会限制我们核心系统应用层的扩展性。
2.4 数据安全技术局限性
所谓数据安全性主要是指在面临设备物理故障或者是逻辑错误的时候，核心系统数据本身的容错能力。这个容错能力一方面来自于基础架构本身的数据高可用能力以及数据的容灾架构设计，另外一方面来源于应用层对于数据在整个流动过程中的校验保护机制。
1） 基础架构层面
传统核心系统的数据保护从基础架构层主要有几种方式：其一是基于传统块儿存储做的数据复制架构，例如HP的CA技术、IBM 的PPRC技术，EMC 的SRDF技术等；其二是基于操作系统卷管理器层面做的逻辑镜像技术，例如LVM的镜像技术、VxVM的镜像技术等；其三是基于数据库层面的复制技术，例如Oracle 的DG技术，DB2 的HADR技术等；其四是为了避免数据逻辑错误而采用的传统备份技术。这些技术往往各有优缺点，单一的技术体系或者是把不合适的技术手段运用到核心系统数据保护上，在真正发生问题的时候，后果往往是灾难性的。近些年来一些现实的案例也充分说明了这一点，例如本来的双机高可用技术由于设备参数的错误设置导致脑裂问题，由于物理的复制缺乏逻辑校验导致了故障场合下的数据切换失败等等。
2） 应用层面
传统核心系统大部分采用的是胖核心的架构模式，其实有一个非常重要的原因就是过去的技术体系当中，应用系统之间、应用模块儿之间、应用接口之间的数据校验处理机制相对比较空白，一旦一个业务逻辑跨越了比较多的环节，那么非常普通的一个传输错误、网络中断或拥堵等事件就有可能导致整个交易处理的不一致或者是不完整。为了避免这种情况的发生，过去的核心系统尽量将很多的关联模块儿放在了同一个物理平台上，以集中的方式来避免这种情况的发生。但是随着今天我们业务的膨胀式发展，这种集中到了一定的规模就形成了一个限制。要打破这个限制将应用解耦并分布式部署，需要解决的一个难题就是要以完善的校验机制来保障整体业务逻辑的完整性和一致性。
3. 中小银行核心系统基础架构的优化策略3.1 去耦化设计3.1.1业务模块的逻辑拆分
业界并没有一个统一的定义，但是有一点可以明确的是银行的核心系统不是一个单一的应用系统，而是一组应用系统的组合。具体包括：存款管理、贷款管理、支付结算、会计处理、总账处理等等。在这些模块儿当中有一个核心的线索可以将其串联到一起就是账户数据，这个账户既有个人的账户也有机构的账户。所有围绕账户产生的一些借贷行为组成了银行核心系统联机业务的流转以及会计实务的处理。
今天的互联网时代，很多银行的互联网业务已经成为银行的核心业务。要解决传统核心的去耦问题，首先第一个需要解决的问题就是根据自己银行的业务发展模式来决定是否将互联网的账户和本地账户进行分离，也就是一类账户和二三类账户的分离。如果我们的二三类账户业务非常庞大，而且发展趋势页也非常明确，那么不仅仅需要核心系统本身的账户分离，更需要业务部门重新来定义二三类账户业务的管理模式和权限归属问题。
接下来，第二个需要解决的问题就是联机业务和总账业务的分离。总账业务系统可以单独切分为一个独立系统，联机业务、信贷业务、支付业务、互联网交易等等这些业务完全成为一中对等的模式来支撑银行的日常金融服务。总账业务系统成为一个单独的可以对接各种业务类型的账务平台，由于它属于账务类系统没有实时提供金融服务的属性，也就不会成为业务服务瓶颈，它的处理只影响银行后台会计事务，属于内部业务。
第三个需要解决的问题就是联机业务系统内部本身的设计。以客户为中心的设计，建立基于全面了解客户能力的客户统一视图，提供客户统一入口的客户服务全面整合。建立组合模式的产品工厂，可以根据业务创新进行产品的灵活组合，而不是单一死板的产品模式。实现灵活定义的利率工厂模式，根据未来客户服务的市场化建立内部定价体系，提供多维参数化定价体制，提供多为利率组合模式，既可以实现通用计算模型又可以实现特殊化的利率模型。多法人支持，在数据库底层设计中引入法人字段，做到数据隔离。
3.1.2应用模块的分布式部署
传统的核心系统，无论是联机应用还是批量应用基本的部署方式还是物理机的独立格局部署方式，从其他系统的业务请求到核心系统内部请求的处理基本都属于独立格局，这个流程涉及到的请求、调用、处理等事务基本都属于固定模式，没有任何动态分配算法来支撑。
我们在核心系统去耦工程当中，非常重要的一个事情就是要解决这种独立部署的格局。首先就是要解决核心系统联机应用的负载均衡支持问题。有些核心系统的设计已经采取了分布式架构，利用一些分布式中间件以及缓存的中间件来实现联机业务请求的分布式部署。这是一种趋势，无论是用Tuxedo软件负载，还是利用F5硬件负载，都应该实现应用层面的负载均衡部署。当然支撑这种部署方式的前提是应用层面必须具备对业务处理逻辑的校验，无论是会话策略还是链接策略，都因该具备交易处理的逻辑校验功能，以支撑核心系统业务处理的分布式架构。
3.1.3基础架构的逻辑解耦
核心系统的基础架构主要是指支撑核心系统应用以及核心系统数据库的平台架构，既包括计算资源的集成又包括存储资源的集成。如果采用大型机、中型机、小型机的架构势必会导致核心系统本身的灵活性受限。如果采用通用X86分布式的架构又会担心其处理能受限导致系统整体的稳定性和高可用性受限。
因此在核心系统基础架构的选型过程中既要考虑到单个物理资源的处理能力受限问题，又要考虑到单个物理资源对整体核心系统群的扩展性和灵活性受限的问题。因此在当前环境下，应该结合二者之优势来设计整体核心系统整体。单个物理资源的选型我们要考虑到其足够的处理能力，横向的资源扩展我们要考虑到资源的横向组合性，足够适应虚拟化技术、资源池技术带给我们的资源整合优势。数据库的选型我们要充分注重其纵向的处理能力，应用服务器的选型我们要充分注重其横向的扩展能力。
3.2 资源池化设计3.2.1 应用和资源的映射关系分析
说到应用和资源的映射关系，其实就是什么类型的应用需要什么类型的资源去支撑。比如说有些应用是计算秘密性应用，有些应用是内存密集性应用，还有一些应用是存储密集性应用。但是对于资源实体，也就是我们的服务器或者是存储设备来讲，是无法实现特定应用类型的资源配比，因此一定会造成某一方面或者某几方面的资源浪费而某一方面的资源紧缺。
因此，在核心系统各种资源池化的整体思路框架之下，首先是要分析出核心系统各个业务模块，各个层面对资源的需求状况究竟是什么样的。例如，可能联机交易业务的处理更多的是内存资源的耗用，而批量业务的处理更多的是CPU资源的耗用。数据库内的数据处理更多的是IO和内存资源的耗用。只有前期对于核心系统各个模块儿的资源耗用特点有一个清晰的把我，那么才能支撑我们后期对资源池的划分和虚拟资源的设计。
3.2.2 虚拟化方案的设计
多为虚拟化方案的设计，主要是指对虚拟化解决方案的选型以及具体虚拟化设计方案的规划。对于虚拟化解决方案的选型主要依赖于我们所选硬件的兼容性要求，例如X86服务器的虚拟化解决方案相对宽松，而Power架构服务器的虚拟化解决方案相对比较狭隘。所以今天的客户更多是选择了基于X86架构的服务器资源。
当我们选定了支撑我们虚拟化方案的硬件资源之后，那么就是对具体虚拟化设计方案的规划。主要涉及以下几个方面的详细规划设计：
1） 各个资源池的设计
无论是什么样的资源池化技术，一个共通的功能特性就是可以实现CPU、内存、网络、存储等资源的共享技术。用哪些物理资源去组织成为那些可用的资源池就是我们这一个步骤需要考虑的问题。对于应用服务器资源来讲，彼此产生冲突的是CPU和内存资源，需要建立统一的CPU和内存资源池。对于数据库服务器来讲，除了内存资源的冲突之外，更多的是存储资源的冲突，因此需要建立统一的存储资源池。
2） 虚拟服务器对资源的分配策略
由于不同的应用对不同资源的获取和访问具有不同的属性特点以及不同的重要程度之分，因此我们在对不同虚拟服务器的资源分配上需要建立不同的动态分配以及优先级策略分配模型。比如，在数据库服务器和应用服务器的资源竞争策略当中，那么数据库服务器的内存优先级一定高于其他服务器；在联机应用服务器和批量应用服务器的资源竞争当中，一定会有时间段的区分，设计争夺策略的时候需要充分考虑到时间段的分布；数据库服务器和其他服务器存储资源的使用和竞争过程当中，一定会有IOPS和高可用的区分，在具体的分配策略当中我们需要充分考虑到这一点的区别。
3） 资源的动态优化策略
所谓资源的动态优化策略是指在不同的时间区分以及不同的业务场合下，资源的分配是否可以根据实际情况进行变化以及如何变化，再有就是资源产生冲突的场合下，可用资源应该如何分配。成熟的资源池虚拟化技术可以通过资源的优先级、资源的分配粒度、资源的共享以及回收策略来实现资源在不同时间和空间下的平滑迁移。但是前期条件是我们需要根据应用的不同特点来设计合理的资源动态调配策略，其主要涉及以下几个方面：
1、 虚拟资源和物理资源的分配粒度，保障物理资源得到足够细粒度的分配。
2、 虚拟资源的动态分配优先级，根据业务优先级来保障资源的分配优先级。
3、 虚拟资源的预留及限制规则，根据预留规则，限制规则来保障在极端场合下对重要业务的保障。
3.3 基础架构扩展性设计3.3.1前提条件
核心系统的基础架构是否可以实现灵活的扩展性决定于应用系统本身的模块儿化设计是否合理，主要表现为以下几个方面：
1）联机交易是否可以实现跨机处理，也就是联机业务不同业务逻辑是否可以根据交易当中的某些属性实现物理层面的跨机处理，逻辑层面的业务统一性。
2）缓存数据在整个交易过程的一致性保持，通过缓存中间件、消息中间件等机制实现交易临时数据的一致性保持。联机处理业务当中，每一笔交易实际经理的交易逻辑过程可能会比较多，但是如何在分布式处理过程当中区别某一个交易就需要某些会话属性的临时数据在交易过程中的持久性。
3）尽可能的数据分离，对于传统的核心系统来讲，业务上没有太多的区分导致底层数据库当中的数据区分度不是非常合理，尤其在并发较高的场合下，底层数据的热点竞争非常激烈。如果我们要实现基础架构的灵活扩展性，那么从业务上需要将底层数据尽量重新设计实现良好的分离性。
3.3.2应用层的扩展性设计
应用层的扩展性设计主要取决于以下几个个方面：
首先、从整体架构设计上需要有负载分发层来实现业务请求的分布式分发，无论是用F5硬件还是用Tuxedo等实现的软件层面的负载均衡，总之在核心系统应用层之前需要一个负载均衡层来实现整体架构的灵活扩展性。只有负载均衡层作为业务请求的接口才能实现应用服务器的灵活增加或者减少。
其次、将业务交易状态进行分布式缓存。对于存粹的互联网应用来讲，多数是无需保持其业务状态的，但是对于金融行业的交易业务来讲，大部分是需要保持及交易状态信息的，也就是说在整个复杂的交易流程当中，其交易状态是需要保存下来的。如果要实现整体架构的扩展性，那么就必须有相应的状态数据缓存层来支撑其他部件的灵活扩展性。
再有、应用节点的选择要实现虚拟化。用虚拟化之后的规模效应以及其灵活快速交付性来实现应用层的足够扩展性。这个其实并不难理解，如果还是延续传统的物理格局方式，那么即使有前端的负载均衡层以及分布式缓存或者队列，也很难实现架构的灵活扩展性，瓶颈在于其交付和部署的耗时。
3.3.3数据层的扩展性设计
1、对于核心系统的数据层来讲，主要是指数据库。对于传统的胖核心的架构来讲，其数据库多属于重量级数据库，借贷数据归属于同一个数据整体。它对数据库实例的要求更多的是偏向于服务器纵向处理能力的依赖，横向的扩展性基本上不具备，横向的高可用可能更多的是HA的模式，高可用能力非常有限。
2、如果在核心系统应用架构能够拆分，业务可以重新进行分析重组的前提条件之下，那么数据的访问也是可以重新再作切分，比如说联机和会计总账数据的适当切分，借贷数据的切分等。
3、由于银行的核心交易数据都是二维表结构化数据，最适合其处理的也是关系型数据库，我们不能将架构的扩展性寄希望于某些NOSQL分部式数据库的引入，这个不合理也不科学。在既有的关系型数据基础之上，我们要想提高数据库层面的架构扩展性只能通过分库分表的方式来降低数据的热点问题，从而将不同的业务访问分担到不同的数据库实例上，从而实现数据库架构的整体扩展性部署。
3.4 数据安全性设计3.4.1 基础架构层的数据保护技术选型
对于基础架构层的数据保护技术会有很多，有一些已经被金融行业采用多年。每一种技术都不是十全十美的，必然会有它的优缺点，如果我们能根据自己的环境需求来选择合适的数据保护技术，那么整体上就会实现对核心系统数据的一个完整性保护。
首先，我们基于常见的一些数据保护技术进行逐一优缺点分析：
1) 存储层同步异步复制技术。
2) 系统层或者存储网关层的卷镜像技术。
3) 数据库实例层的高可用技术。
4) 数据库应用层的数据复制技术。
对于存储层的同步异步复制技术，一般用于跨站点的容灾解决方案。其数据复制的性能要比其他的技术手段快，但是实现的架构相对比较固定单一。对于系统层或者存储网关层实现的卷镜像技术来讲，多用于跨设备跨楼层实现的存储高可用性保障，但是不适合远距离的容灾保护。以上这两种技术来讲，最大的缺陷在于对数据的逻辑保护缺失。而数据库实例层的高可用技术只能针对数据访问的连续性进行保护，不能对数据本身提供保护。数据库应用层的数据复制技术相对是一种数据库层比较安全的数据保护技术，但是其实现的仅仅是单纯的表数据层保护。
那么基于以上的分析，我们可以根据我们的具体核心系统基础架构数据保护的需求以及现有的环境状况来选择合适的技术手段组合形成我们的整体数据保护架构。比如说，对于核心系统的数据库本身，我们需要构建足够安全的数据保护基础，可以选择数据库层面的复制技术来实现；对于应用接口之间的缓存或者是队列类数据，我们可以采用系统层镜像技术来实现临时数据的访问连续性；对于数据库实例或者是应用实例层我们可以采用各自层面的负载均衡或是集群技术来支撑实例访问的连续性；对于某些修改非常少的历史数据库我们可以采用存储复制方式来实现其保护。
3.4.2 应用接口层的校验机制设计
应用的交易业务一般来讲都会有很复杂的流程，比如说一个支付业务可能会经历签约解约、支付、撤销和退款、预授权以及撤销、预授权交易、对账、查询等很多环节。这些环节可能会分布在不同的应用模块儿当中，分布于不同的物理资源节点之上，还有可能会经历互联网渠道、综合前置、其他交易系统、核心交易系统等才能完成整比交易。那么在整个过程中，应用层需要做好以下关于数据校验机制的设计：
1）交易状态的校验机制，所谓交易状态的校验就是在各个环节处理过程中如何去保障交易的唯一属性，从技术手段上来讲，这个已经有很成熟的开发解决方案，规划过程中我们需要注意的是将合适的解决方案引入到系统的设计当中。
2）交易完整性的校验机制，所谓交易完整性校验机制是指在整个交易过程中，对同一账户的多个交易处理不能因为交易的执行或者撤销交叉产生错误的账务问题。在集中式的架构部署过程中，传统的核心交易系统完全能够解决这个问题，我们需要注意的是在架构横向扩展之后依然能够保障这个特性。
3）并发交易对账户的最终校验机制，由于互联网渠道的不断延伸，越来越多的交易呈现出高并发的特点，在现有核心系统的运行机制过程当中，该问题的发生很容易导致系统交易处理性能剧减并导致交易挂起的问题发生。归根揭底来剖析这个问题，主要是两方面的设计不合理：一方面是对于流水号等特殊属性的锁机制存在缺陷，另外一方面就是对于账户一致性的保护措施依然停留在传统的实时一致性模式之下。这个问题会贯穿到互联网渠道交易的多个方面，要解决核心系统的整体扩展性问题，这需要一个统一合理的设计规则来支撑此类问题的处理。
4. 总结及展望
本文对银行核心系统的发展历史现状进行分析描述，并且提出银行核心系统架构面临的一些挑战和困惑，并且基于这些挑战提出了在银行的核心系统改造及建设过程中应该注意的一些问题以及应该遵循的一些解决思路。旨在提出共性问题及个人的思路，希望有更多的同行业者共同来探讨此类问题的分析和解决。将此文进行补充和完善以形成一些可以供同业者参考的经验和启示。
