中小型商业银行的信息系统架构

中小型银行数量众多，以城市商业银行、农村信用社、村镇银行为重要组成部分。大部分中小型银行都属于区域性金融机构。从应用系统的组成结构、分类和技术架构角度来看，中小型银行具有“麻雀虽小，五脏俱全”的特点。虽然中小型银行部署的应用系统数量和规模不如大型银行，但是在技术架构设计中所遵循的原则是一致的，只是基于可获得的应用软件、自身技术能力、投资成本等因素作了一些取舍，并无本质的不同。下面将结合某银行的案例向大家介绍银行典型技术架构的设计思路和考量。

某银行是前身是省级的金融合作机构，后经法人重组改制成为商业银行。改制之前，每个地市级分行都有自己的应用系统和数据中心，业务分散处理。为了配合业务发展的需要，某银行决定建立总行大集中的综合业务系统平台。通过统一的基础架构平台，统一的应用系统等，实现全行业务的集中处理。系统架构设计人员需要考虑下列要求。

1）为了快速具备先进、完善的业务处理能力，某银行决定引进某国际知名开发商的核心银行系统，并进行客户化开发，与现有周边系统进行融合。

2）业务部门预估大集中后，未来3～5年业务量会出现每年超过40%的增长。并且随着城乡医保、网银等总行级业务的上线，5年后业务量高峰将实现5～10倍的增长，达到账户总数8000万户，日交易峰值2000万笔交易/天的规模。

3）由于某银行的前身是金融合作机构，技术力量相对薄弱，特别是地市级的技术人员能力参差不齐，需要从技术层面确保系统的稳定运行。

4）为了切实保证业务处理的稳定运行，必须建立有效的灾难备份环境，能够在出现灾难的情况下，对核心和关键新业务进行应用级接管。

5）未来几年中会上线大量的新业务及应用系统，需要提供灵活高效的开发测试环境。

6）需要避免以前分散式业务处理架构中，各系统之间资源相互独立，不能共享，系统资源分配和部署时间长的问题。

某银行基础架构设计团队与核心应用软件开发商、网络/服务器/存储厂商、系统集成商进行了广泛的讨论，并着重对以下的问题进行了深入的研究：

1）搜集和整理业务部门对于基础架构业务支撑能力的要求。

2）核心银行系统应用部署架构及其对基础架构的要求。

3）梳理各种外围应用系统的应用部署架构及其对基础架构的要求。

4）可供参考的银行基础架构参考模型和案例分析。

5）各硬件厂商和集成商对本项目建议方案的对比分析。(www.xing528.com)

6）针对关键应用和设备功能的性能和验证性测试。

在完成以上的过程之后，架构设计团队综合各种因素、业务和技术要求，设计出如下的基础架构方案。下面对此架构进行详细说明，以帮助大家理解相关的方案和设计思路。某中小型银行新一代技术架构如图5-69所示。

方案概述：

第一类应用系统：各系统的服务器架构分别采用两台采用高端UNIX小型机构成双机高可用性集群。基础软件采用了AIX操作系统和DB2数据库。存储方面也采用了核心生产存储和核心备份存储双冗余镜像的高可用性设计，为核心及关键业务系统提供服务保障。

第二类应用系统：数据库服务器采用中高端UNIX小型机加虚拟化分区的方式进行整合，根据不同应用系统数据库的实际需要分配资源并进行动态调整。各数据库服务器的通过HA软件或数据库集群构建高可用性。由于非核心应用数量众多，采用了多种系统软件，包括AIX、Linux、Windows操作系统，数据库使用了Oracle、DB2等。应用服务器采用了刀片服务器进行承载，并通过软件集群的水平扩展方式构建应用服务器集群。在存储方面，采用了多台中端存储服务器为不同的应用系统提供服务，未来如果中端存储数量过多，可以考虑通过存储虚拟化功能或高端存储服务器进行整合。

SAN网络设计：生产SAN网络划分成第一类系统SAN网络、第二类系统SAN网络和备份SAN网络（含容灾复制链接）三个部分，实现了第一类系统与第二类系统交易处理与数据备份/容灾SAN网络的分离，构建了独立开发测试SAN网络，避免开发测试环境与生产环境的交叉；构建了独立的容灾中心SAN网络。

统一备份平台：使用配置多个驱动器的高端物理带库作为数据库的主要备份手段。使用虚拟带库作为小文件的主要备份手段，然后再转存到物理带库中。同时，为了减少传统备份方式在备份时对数据库操作产生的影响，在核心数据库的备份上采用了存储快照技术。即先对核心数据库做快照，再通过快照复制进行数据备份，避免了直接对核心数据库进行备份的操作。所有的备份操作和备份策略的执行，统一由备份管理软件执行，避免了人为操作带来的备份操作方式和备份策略差异。

图5-69 某中小型银行新一代技术架构

地市级数据中心：在服务器方面，考虑到地市级的业务处理量、数据量，以及人员操作技能的水平。在地市级普遍采用刀片服务器部署数据库和应用服务器，通过HA软件或软件集群构建高可用性。配置和管理难度更适合于地市级的技术水平，但是会牺牲一定的资源分配灵活性。基础软件采用了AIX和Linux操作系统，数据库使用了Oracle和DB2。在存储方面，中端存储完全能够满足地市级处理的需要，并具备一定的高可用性和容灾能力。

灾备中心：考虑到出现灾难时，很多中间业务不需要开展。为减少资源闲置，本地灾备中心的服务器处理能力按照生产环境70%进行配置。服务器数量仅覆盖第一类应用系统，并且不考虑高可用性问题。在存储方面，本地应用级灾备中心配置灾备存储服务器，通过磁盘同步镜像的方法将生产数据从核心生产存储复制到灾备存储服务器之上。在网络环境上，应具备发生灾难时灾备中心网络环境接管生产环境IP，并能将各种交易请求路由转发到灾备中心的能力。某银行定期举行灾备切换演练，考察灾备切换时，网络、服务器、存储及应用对生产环境的接管能力，确保常备不懈。另外，灾备中心应定期对灾备数据和环境进行验证，确保其真实可用。未来，将通过虚拟化技术利用平时闲置的服务器资源和灾备数据运行部分非核心业务系统，以提高资源利用率。

开发测试云：为了满足大量新的应用系统开发上线的需求，构建了开发测试云环境。开发测试云平台构建了小型机资源池、x86服务器资源池、存储资源池和统一的云管理平台。用户可以通过云管理平台和虚拟化技术，对小型机服务器、x86服务器、存储服务器的资源进行统一分配和管理。基础软件涵盖了生产环境所使用的所有操作系统、数据库、中间件产品。通过开发测试云环境，某银行对虚拟化和云计算技术进一步熟悉，积累了大量的使用经验，未来会逐步地把虚拟化和云管理技术推广到生产环境之中。