中小银行核心系统基础架构规划

中小银行核心系统基础架构规划目 录1. 中小银行核心系统基础架构现状42. 中小银行核心系统基础架构现有问题62.1 耦合性太高62.2 资源的物理格局限制62.3 基础架构扩展性存在短板72.4 数据安全技术局限性81） 基础架构层面82） 应用层面83. 中小银行核心系统基础架构的优化策略103.1 去耦化设计103.1.1业务模块的逻辑拆分103.1.2应用模块的分布式部署113.1.3基础架构的逻辑解耦113.2 资源池化设计123.2.1 应用和资源的映射关系分析123.2.2 虚拟化方案的设计121） 各个资源池的设计122） 虚拟服务器对资源的分配策略133） 资源的动态优化策略133.3 基础架构扩展性设计143.3.1前提条件143.3.2应用层的扩展性设计143.3.3数据层的扩展性设计153.4 数据安全性设计153.4.1 基础架构层的数据保护技术选型153.4.2 应用接口层的校验机制设计164. 总结及展望18随着全球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应用模块的分布式部署传统的核心系统，无论是联机应用还是批量应用基本的部署方