本文来自twt企业IT社区，作者/赵海。
【摘要】从银行核心账务系统的业务特征分析来看，随着信息化的不断发展，从业务的灵活性、负载量、敏捷度等各个方面都对现有核心系统提出了严峻的挑战。作为业务系统的载体，基础架构本身必然需要根据业务的发展变化情况进行相应的自适应调整。
【作者】赵海，某金融系统高级主管
一、银行核心系统业务特征分析
伴随着信息技术的发展历程，国内的金融行业一直在经历着各种变革。众所周知在银行业内，核心系统对于银行具有重要意义，可以说核心系统的变迁代表着银行业整体信息技术体系的发展。总体来看国内银行业的核心系统发展经历了三个阶段：
第一阶段：七十年代末到八十年代中期，银行的储蓄业务以及对公业务逐渐以计算机代替手工操作，计算机是一个以网点为基础的分散式信息管理域。这个阶段谈不上信息化的变革，仅仅是电脑取代了手动操作，完全是一种分散式的管理模式。
第二阶段：八十年代中期到九十年代末期，这一阶段银行开始通过使用计算机网络技术实现银行部分业务的实时联机处理，并逐步实现了银行在一定区域范围内的数据集中及互联互通；区域集中让所辖银行得以共享数据资源，统一了科目设置，改进了业务流程。
第三阶段：二十世纪初至今，这一阶段即所谓的数据大集中阶段。全国性的银行数据通信网络框架基本建成，各银行的综合业务处理网络相继建成，一个多功能的、开放的银行信息化体系初步形成；核心系统由原来的网状架构统一成总线集成架构，系统间的接口规范以及报文格式等都形成了统一的行业标准，并且这些技术及标准也在不断的优化发展过程当中。
从银行的数据大集中到目前来讲，银行业务已经经历了将近20年的发展。在互联网和信息化没有爆发的年代，银行的业务类型相对固定，发展较为稳定。银行的核心系统大部分出于安全性、稳定性以及高效性的考虑形成了大核心或者胖核心的局面，也就是既有存贷产品服务功能，又有基础性的公共服务功能，还有银行的会计核算功能。
近些年来随着互联网以及信息化的爆发式推进，银行的业务受到了越来越大的冲击。利率的市场化发展要求银行的产品计算模式必须能够经得起灵活性的挑战；金融产品市场化竞争的激烈要求我们的产品及服务必须能够随时创新随时变化；互联网及移动信息化的发展要求银行的支付结算手段必须能够跟得上客户的环境变化；行业标准及国家政策的变化要求银行能够快速适应并变革。举例来说：为了争取客户，对于符合某些条件的客户的存款产品，我们需要定制特殊的利率或者算法，如果我们的核心系统并非基于面向对象或者服务的设计模式来实现的松耦合架构，那么可能会因为我们流程化的产品定义模型以及客户定义模型导致我们对核心系统内部进行较大的变更；比如说我们面临互联网的环境希望推出有特色的产品来吸引客户，很可能由于核心系统的接口模式固定化导致我们无法快速实现产品的创新和退出；比如说我们面临的营改增问题，如果账务核算和联机业务以及公共处理模块能够逻辑隔离，那么这类的问题就不会带给我们核心系统巨大的改动量，也不必为此承担巨大风险。诸如此类问题会有很多，所有的这些挑战都不是过去胖核心或者大核心环境能够解决的问题。这就要求银行的核心系统在应用系统层面必须实现对象化、服务化的松耦合模式。
二、银行核心系统数据管理要求
从银行核心账务系统的业务特征分析来看，随着信息化的不断发展，从业务的灵活性、负载量、敏捷度等各个方面都对现有核心系统提出了严峻的挑战。作为业务系统的载体，基础架构本身必然需要根据业务的发展变化情况进行相应的自适应调整。因此银行核心系统的数据管理方面也会面临系列挑战，需要根据应用的需求进行相应的变革，具体来说体现在如下几个方面。
2.1数据处理的高度灵活性
从业务层面革新需求来看，应用系统层面必须实现对象化、服务化的松耦合模式来应对银行业务模式的快速变化和迭代要求，同样应用系统需要数据处理的支撑，这对基础架构层的数据处理同样提出了高度灵活性的要求。主要体现在以下几个方面：
1）数据处理针对不同时间范围内的数据量级变化需要有超强适应能力。
2）数据处理针对不同业务模式的读写特征（随机、顺序...）需要有快速的转换能力和适应能力。
3）数据处理针对不同业务模式对性能要求具备细分和匹配能力。
2.2数据管理量级呈线性增长趋势
在互联网兴起之前，银行业的业务类型相对固定，发展也较为稳定。大型银行采用大型机架构支撑全国量级核心业务，中小银行采用中型/小型机来支撑局部地区的核心业务。近些年来随着互联网的爆发式发展，银行业务依托互联网从业务的多样化方面、客户量级方面、账户量级方面都进行了升级式的发展，因此核心系统需要管理的数据也呈线性增长趋势，这也必然带来大数据量级下的存储、读取、处理等各数据处理环节的量级变化。尤其是银行的账务处理系统，这些账务处理业务映射到基础架构层的数据处理主要是大量的顺序读写及内存的处理操作，小数据量情况下的跑批业务可能需要1-2个小时，但是面对表内数据量的倍数扩展，如果继续按照固有模式处理，可能需要几十小时甚至更多。
2.3数据读写性能要求不断细分且提高
银行的核心交易及账务类系统原本对数据处理的性能要求就比较苛刻，很多银行经过应用上的总账分离革新之后，针对联机业务和总账业务采取了不同的存储性能应对策略。那么伴随着互联网业务的接入以及互联网核心业务模式的凸显，互联网业务行为的不确定性以及差异性必然带来不同业务模式对数据读写性能的细分和更高指标要求，这就必然带来底层数据处理平台的松散化、细分化变革。
2.4数据安全管理方面不断提升至新的要求
金融行业是所有行业中对安全性要求相对较高的行业，从核心系统的客户及账务数据到渠道系统当中的流水和签约信息都是安全要求比较高的数据。但随着互联网业务模式的不断推陈出新，支付手段和渠道的不断变革，数据前、后、中台的不断创新，数据在不同系统之间以及云化资源池当中的流动范围、速度、量级都发生了前所未有的变化。因此在整个数据存储、流动、处理、读取的过程中会有更多安全方面的要求。
三、银行核心系统存储架构选型技术分析
3.1数据处理和存储资源的映射关系分析
前面我们讲到了银行核心业务系统针对数据处理，在灵活性、数据量、性能、安全性方面的几点挑战，那么针对这些新的挑战，要想在基础架构层完全应对，就必须做好从上到下的映射分析。业务变化影响应用系统变革，应用系统变革提出新的数据处理需求，新的数据处理需求要求存储架构做到相应支持。这就要求我们根据数据处理要求来对存储资源的架构、性能、容量等多方面进行细分匹配。比如说有些应用是计算密集型应用，有些应用是内存密集型应用，还有一些应用是存储密集型应用。但是对于资源实体，也就是我们的服务器或者是存储设备来讲，无法实现特定应用类型的资源配比，因此一定会造成某一方面或者某几方面的资源浪费而某一方面的资源紧缺。因此，在核心系统各种资源池化的整体思路框架之下，首先是要分析出核心系统各个业务模块，各个层面对资源的需求状况究竟是什么样的。例如，可能联机交易业务的处理更多的是内存资源的耗用，数据处理更多的是要求高效率的随机读写和并发读写，而批量业务的处理更多的是CPU资源的耗用，数据处理更多的是要求大批量数据的顺序读写。数据库内的数据处理更多的是I/O和内存资源的耗用。只有前期对于核心系统各个模块的资源耗用特点有一个清晰的把握，才能支撑我们后期对资源池的划分和虚拟资源的设计。
3.2分布式架构与集中式架构相结合
在面对存储架构的集中式和分布式，有人认为银行核心业务系统不同于互联网业务系统，只有集中式才能保障数据的强一致性，才最适合核心业务系统的互联网业务系统。有人认为互联网的分布式架构已经成为时代的新宠并代表存储架构发展的主流趋势，银行的核心业务系统存储架构也一定会走向分布式。
个人认为银行的核心业务系统有它区别于互联网业务的独特方面，但是随着互联网线上业务模式的发展，它也融入了太多的互联网因素。因此就核心业务系统本身而言，应用层面正在或者已经走向了松散组合的模式。也就是说有些业务处理模块还会延续传统交易模式，有些业务处理模块其实已经与很多互联网渠道系统形成了密不可分的关系。因此在前期对数据处理进行细分的前提之下，我们可以按照业务模块或者系统的颗粒度将不同存储产品映射到不同的应用上。
对于传统的核心交易类系统或者模块，我们依然会选择传统的集中式存储架构，但是在资源性能、容量、安全、功能方面提出更高的要求。对于与互联网渠道联系紧密并且像签约或者流水类过程数据的核心业务系统，我们可以尝试选择分布式存储架构，以此来应对数据处理在灵活性敏捷性方面的要求。对于因更多数据分析需求衍生出的数据前中后台类系统，我们可以考虑将一些具备大数据处理分析技术基因的存储产品纳入到选型的范围。
3.3以传统容灾为基础充分挖掘新的数据保护技术
前面分析过银行核心系统群在数据处理方面的安全性要求，在面对数据量级线性增长、数据流动范围需要扩展、数据处理多样化发展的趋势下，传统的数据保护技术也需做相应的升级。但是在升级的过程中，我们需要保持以下原则：
首先，以银行传统的容灾技术为基础进行拓展。银行业的数据，尤其是客户的账务数据，无论是人民银行还是银监局对它的安全性要求一直没有变，相对云环境下的一些新容灾模式，它还是最安全最成熟的数据保护手段，比如基于数据库的双活复制技术，基于存储的双活复制技术等等。
其次，在保持传统容灾手段的同时，探求对云环境下新型容灾技术以及基于备份技术衍生出的具有数据保护特性的应用。在拓展新技术的时候还是要以应用系统为颗粒度，针对业务保护以及数据恢复需求细分在存储层面采用一些新的数据保护特性。
四、结论及展望
存储架构作为基础架构中的核心元素，始终是作为数据的载体而存在的，因此它的选型必然要受到上层应用层面革新变化的影响，我们选型的基本思路也要遵循从上至下的基本原则。另外，存储架构选型的出发点不在于某种存储技术本身的先进性，而在于它与上层应用的匹配性。
