银行新核心基础架构方案设计技术手册

银行新核心基础架构方案设计技术手册目 录1. 分析篇41.1 银行核心基础架构的现状41.2 银行核心基础架构面临问题51.2.1 耦合性问题51.2.2 资源格局限制51.2.3 扩展性短板61.2.4 数据安全局限性61.3 银行核心基础架构重构必要性61.3.1 三步走战略分析71.3.2 面对 FinTech 时代的机遇与挑战71.3.3 集中式与分布式91.3.4 微服务与巨石101.4 银行核心基础架构重构难点分析111.4.1 交易和核算的分离问题111.4.2 系统去耦问题111.4.3 思维转型121.4.4 思维转型132. 规划篇132.1 银行核心系统去耦设计132.1.1 业务模块的逻辑拆分132.1.2 应用模块的分布式部署142.1.3 基础架构的逻辑解耦142.2 资源池化方法142.2.1 应用和资源的映射关系分析152.2.2 虚拟化方案的设计15一、各个资源池的设计15二、虚拟服务器对资源的分配策略15三、资源的动态优化策略152.3 基础架构扩展性方法162.3.1 前提条件163.3.2 应用层的扩展性设计163.3.3 数据层的扩展性设计162.4 互联网模式发展方法172.4.1 定位互联网模式的位置172.4.2 互联网模式发展思路173. 设计实施篇183.1 银行核心系统存储解决方案183.2 银行核心系统数据库解决方案193.2.1 架构规划设计原则193.2.2 数据库性能影响203.2.3 Power 虚拟化架构设计要点203.2.4 同时满足 IOPS 和吞吐量213.2.5 数据库集群的心跳网络设计21一、硬件及参数21二、网卡绑定21三、SCAN IP22四、网络参数223.2.6 虚拟化与物理机混合部署23文档介绍目标人群本文章适合银行从事 IT 建设的架构师、工程师以及主导核心系统基础架构及应用系统建设或者改造项目的项目经理等人群，可以帮助大家对项目或者技术选型及定位有一些相对 比较清晰的认识，从而指导其相关的技术工作。写作目标本文从分析角度、规划角度以及设计实施角度来诠释银行的核心交易系统建设所需注意 的一些细节问题。从基础架构的现状、发展历程以及在当今互联网普及的这个环境下金融行 业的核心交易系统面临的问题：系统敏捷性的问题、架构扩展性的问题、架构耦合性的问题 等等。对于每一个问题，不同的专家从不同的角度都做了详细的诠释，包括对问题的看法以 及解决问题的思路等等。在规划篇当中，分别对系统建设的过程中涉及到的业务层、应用层 以及基础架构层等各个方面进行了详细的方法论介绍。在设计实施篇中分别对银行核心系统 的存储层和数据库层的关键技术和实施点进行了案例性的讲解。希望通过各个层面的诠释能 给读者对银行核心交易系统的建设带来一个详细完整的解释。1. 分析篇1.1 银行核心基础架构的现状伴随着信息技术的发展历程，国内的金融行业一直在经历着各种变革。众所周知在银行 业内，其核心系统对于银行的重要意义，可以说核心系统的变迁代表着银行业整体信息技术 体系的发展。总的来看国内银行业的核心系统发展经历了三个阶段：第一阶段：七十年代末到八十年代中期，银行的储蓄业务以及对公业务逐渐以计算机代 替手工操作，计算机是一个以网点为基础的分散式信息管理域。这个阶段谈不上信息化的变 革，仅仅是电脑取代了手动操作，完全是一种分散式的管理模式。第二阶段：八十年代中期到九十年代末期，这一阶段银行开始通过使用计算机网络技术 实现银行部分业务的实时联机处理，并逐步实现了银行在一定区域范围内的数据集中及互联 互通；区域集中让所辖银行得以共享数据资源，统一了科目设置，改进了业务流程。第三阶段：二十世纪初至今，这一阶段即所谓的数据大集中阶段。全国性的银行数据通信网络框架基本建成，各银行的综合业务处理网络相继建成，一个多功能的、开放的银行信息化体系初步形成；核心系统由原来的网状架构统一成总线集成架构，系统间的接口规范以及报文格式等都形成了统一的行业标准，并且这些技术及标准在不断的优化发展过程当中。 国内大部分城市商业银行，中小股份制银行等都是在第三个阶段直接发展起来的。其核心系统的建设也是直接套用既有标准规范进行实施的。应用架构基本遵循着总线架构模式，业务处理层面既承担了后台联机业务处理又承担了银行账务处理；基础架构层面根据具体的业务负载不同基本会采用 IBM 的大型机、中型机、小型机等物理机模式；数据库层面基本采用的比较成熟的关系型数据库例如 DB2、Oracle、Infomix 等；高可用架构多数采用的是前一个时代的操作系统层面的双机热备软件实现的主备模式。当前，金融脱媒提速，金融监管日趋严格，对商业银行自身的发展提出了更高的要求， 商业银行要想取得持续稳定的发展需要进行架构转型。架构转型是一个复杂的过程，中小银行应基于自身的特点，更不能脱离自身情况，盲目跟进，而是应该采取循序渐进的实施策略， 合理规划，有序推进。商业银行面对的竞争空前激烈，金融脱媒提速，金融监管日趋严格， 对商业银行自身的发展提出了更高的要求。与此同时，云计算、大数据、区块链、移动互联、 人工智能等一系列的新一代信息技术的发展和应用，正式宣告了 FinTech 时代的来临，在为银行的发展带来了全新发展机遇的同时，也对银行信息化建设提出了更多的挑战。在这其中，IT 架构的搭建是银行信息化建设的顶层设计中最为关键的一环，也是根本性的提升信息化能力的有利手段，它向上承载了企业愿景及顶层战略，向下指导着各信息系统的定位和功能，发挥着无可替代的中坚作用。相对于大型银行和全国性股份制银行来说，中小商业银行面临着科技人员储备不足，信 息技术基础薄弱，IT 架构规划能力不足等方面的问题。原有的 IT 架构多呈现“自由生长” 的状态，且难以满足业务高速发展的要求，IT 架构转型势在必行。架构转型是一个复杂的过程，中小银行应基于自身的特点，更不能脱离自身情况，盲目跟进，而是应该采取循序渐进的实施策略，合理规划，有序推进。1.2 银行核心基础架构面临问题1.2.1 耦合性问题从银行的数据大集中到目前来讲，银行业务已经经历了将近 20 年的发展。在互联网和信息化没有爆发的年代，银行的业务类型相对固定，发展较为稳定。银行的核心系统大部分 处于安全性、稳定性以及高效性的考虑形成了大核心或者旁核心的局面，也就是既有存贷产 品服务功能又有基础性的公共服务功能还有银行的会计核算功能。近些年来随着互联网以及 信息化的爆发式推进，银行的业务受到了越来越大的冲击。利率的市场化发展要求银行的产品计算模式必须能够经得起灵活性的挑战；金融产品市场化竞争的激烈要求我们的产品及服务必须能够随时创新随时变化；互联网及移动信息化的发展要求银行的支付结算手段必须能够跟得上客户的环境变化；行业标准及国家政策的变化要求银行能够快速适应并变革。我们举几个简单的例子：比如说为了争取客户，对于符合某些条件的客户的存款产品，我们需要定制特殊的利率或者算法，如果我们的核心系统并非基于面向对象或者服务的设计模式来实现的松耦合架构，那么可能会因为我们流程化的产品定义模型以及客户定义模型导致我们对核心系统内部进行较为大的变更；比如说我们面临互利网的环境希望推出有特色的产品来吸引客户，很可能由于核心系统的接口模式固定化导致我们无法快速实现产品的创新和退出；比如说我们面临的营改增问题，如果账务核算和联机业务以及公共处理模块儿能够逻辑隔离，那么这类的问题就不会带给我们核心系统巨大的改动量， 也不必为此承担巨大风险。诸如此类问题会有很多，所有的这些挑战都不是过去那个胖核心或者大核心环境能够解决的问题。这就要求银行的核心系统在应用系统层面必须实现对象化服务化的松耦合模式。1.2.2 资源格局限制从系统的基础架构来讲，由于过去那个大而全的开发模式导致核心系统本身的体量非常 大。在一个物理计算节点上需要支撑多个相互复杂调用的应用服务。这也就形成了过去的大 型机、中型机、小型机的物理格局现状。从单个业务或者交易的处理上来讲，这种架构一定 是稳定的、高效的、安全的。随着信息技术的发展，我相信今天各家银行的大部分系统都已经实现了资源的虚拟化级池化，最起码在应用节点的部署上基本都实现了。至于资源池虚拟化的好处就不用多说了， 但是为什么核心系统迟迟没有实现呢？原因有两点：首先是核心系统的体量太大，如果不是新建，很难把握核心系统内部的逻辑关系实现架构的调整。再有就是由于核心系统的体量太大，那么它对资源的需求量也是非常大的，不是单个虚拟资源能够解决的问题。我们暂不从架构本身的先进性来谈这个问题，我们从服务的角度来考虑考虑。相信核心 系统本身承载的几个模块儿：存贷产品、公共服务、客户信息、账务核算。过去这几个模块 儿可能相对提供服务的负载相对比较固定，所以一直安全稳定运行了这么多年。但是今天在 渠道整合以及渠道创新的冲击下，相信它们各自在日常的运行当中提供服务的频率以及他们 需要的负载是存在巨大差异的，而且是在不断变化的，在这种场景下如果继续保持物理资源的独立格局限制，那么必然带来的是应用上和业务上的僵硬。1.2.3 扩展性短板其基础架构扩展性瓶颈主要集中在两个方面，第一个方面就是支撑银行核心系统平台层的扩展性瓶颈，另外一个方面就是核心系统应用层本身扩展性的瓶颈。从平台层本身来讲， 由于传统模式下的核心系统的高负载高压力的特点，大多数银行都是采用小型机、中型机、 大型机等集中式物理架构。那么今天互联网业务的膨胀式发展必然会引发核心系统基础架构处理能力本身的扩展性要求，主要表现为处理并发以及处理复杂业务逻辑上的需求。这种基础架构本身是不具备灵活扩展能力的。另外一方面由于互联网渠道业务的扩展，金融管理制度的快速改革，金融账户属性本身的多样化发展等因素造成的应用层面本身的变更也变得比以往任何一个时期都会频繁，但是我们传统的核心系统都是会计、产品、总账、联机等模块儿相对比较聚合的状态，任何一个小的改动都可能影响到所有的模块儿，再有就是传统核心系统业务逻辑似乎都有一个通病，就是对并发处理设计的考虑很少，这些因素都会限制我们核心系统应用层的扩展性。1.2.4 数据安全局限性所谓数据安全性主要是指在面临设备物理故障或者是逻辑错误的时候，核心系统数据本 身的容错能力。这个容错能力一方面来自于基础架构本身的数据高可用能力以及数据的容灾 架构设计，另外一方面来源于应用层对于数据在整个流动过程中的校验保护机制。传统核心系统的数据保护从基础架构层主要有几种方式：其一是基于传统块儿存储做的数据复制架构，例如 HP 的 CA 技术、IBM 的 PPRC 技术，EMC 的 SRDF 技术等；其二是基于操作系统卷管理器层面做的逻辑镜像技术，例如 LVM 的镜像技术、VxVM 的镜像技术等；其三是基于数据库层面的复制技术，例如 Oracle 的 DG 技术，DB2 的 HADR 技术等； 其四是为了避免数据逻辑错误而采用的传统备份技术。这些技术往往各有优缺点，单一的技术体系或者是把不合适的技术手段运用到核心系统数据保护上，在真正发生问题的时候，后果往往是灾难性的。近些年来一些现实的案例也充分说明了这一点，例如本来的双机高可用技术由于设备参数的错误设置导致脑裂问题，由于物理的复制缺乏逻辑校验