银行信息系统架构设计方案

1.第三类系统计算架构设计原则

银行的传统应用系统大多是属于交易处理（OLTP）类的，少部分的分析类处理（OLAP）也多是附加在交易处理类应用中的功能模块，功能单一且灵活性差。随着业务创新和流程创新的步伐不断发展，大量的新型应用负载被引入到银行技术架构当中，如商业分析与优化、大数据分析平台、非结构化数据管理等。这些应用负载在数据类型、处理能力要求等方面与传统应用负载有着很大的区别：

1）数据量大，来源多种多样，既包括银行内部数据，也包括外部数据。

2）数据类型丰富，非结构化数据占比高。

3）数据时效性强，但数据回溯量低，一段时间之后就不会再被访问。

4）通常采用分布式处理，计算/存储密集型、海量文件管理需求并存。

5）对数据一致性、可靠性和可用性等方面的要求没有传统交易类应用突出。

由于各种新型应用负载的系统架构、处理能力需求各异，很难抽象出统一的计算架构设计模式。因此，这些新型应用负载的计算架构基本都是按照具体项目的要求单独设计的。各银行通常将这部分的应用系统归为第三类应用系统。对于第三类应用系统的计算架构设计，应该遵循以下的原则：

架构设计人员必须紧密的依照特定应用负载的特性，选择相应的计算架构，如分布式、大数据处理、海量文件系统支持等。最大限度的满足特定应用负载的计算资源要求，而不必考虑与其他项目共享。

在应用开发阶段，计算和存储架构设计人员就应该与应用架构设计人员一起考虑上线时的业务量、应用部署和扩展、数据归档备份工作如何进行。而不能等到应用开发好之后，再被动的论证验证计算及存储技术是否能够支持。如：内容管理平台每天可能产生近千万个文件，这样海量规模的文件，什么样的文件系统才能支持？是否要用分级存储和归档？应用数据分类和摆放策略是否能够支持快速的增量备份？

新型应用负载的上线往往伴随着新的技术实现方式，如Hadoop大数据分析、内存数据库、内容管理平台等。对于这些新技术的采用，要通过大量的、全方位的功能性和非功能性测试来验证其功能和效率。架构设计人员要不断地跟踪新技术的发展，了解新应用模式和架构，利用各种新的技术和思路，不断地进行架构设计优化。

下面介绍一下几种典型第三类应用系统的计算架构设计，供读者参考。

2.典型第三类应用系统计算架构设计

（1）商业智能分析类应用计算架构设计考量 商业智能应用中的数据仓库管理了大量的数据，要求在一个数据库中集成整个企业的数据，一般数据量基本上是以TB级来衡量，有些企业的数据仓库甚至达到了PB级的水准，因此数据量的大小直接影响到数据仓库技术的各个方面。数据仓库的建立是为了支持整个企业的运营决策的，企业的各个部门的运营分析及决策人员会大量并发的访问数据仓库。因此，数据仓库的业务逻辑是典型的OLAP操作，对磁盘存储系统的I/O性能要求非常高。

在构建数据仓库系统时要充分考虑系统的性能，做到处理器、内存磁盘I/O、网络带宽之间的平衡才能充分发挥各个硬件的最佳性能，提高整个数据仓库系统的吞吐量。同时数据仓库引擎的体系结构是否支持大数据量并发操作，能否实现线性扩展也是影响数据仓库性能的重要因素。与企业中其他数据量相对较小的交易类应用不同，数据仓库的数据量很大，而且针对大量数据的并发查询操作较多。因此，基于分区的、非共享或者并行处理架构的数据库更适合数据仓库类的应用。这种架构减少了对共享硬件资源的访问冲突，提高了并行度，并且使数据库分区内并行和分区间并行完美结合，而对于用户和应用而言是透明的，一旦物理数据建立起来，用户和应用不会意识到是在访问多分区数据库。

在数据仓库中，随着多分区数据库概念的引入，各分区间的资源配置相对独立，把处理器，内存，存储和数据库分区、配置参数等合在一起，可以作为一个可扩展的数据仓库基本配置单元BCU（Balanced Configuration Unit），然后通过多个BCU单元组成大型的数据仓库系统。BCU是最小的、可复制的硬件和软件的组合。BCU模型保证了BI系统在基础构架上的扩展性，提供了磁盘IO、内存、处理器、网络的均衡扩展能力。BCU的硬件组成部分可以通过对客户现有的BI系统配置经验、平均负荷分析，以及组成BCU的各部分的专家通过考虑各部分之间的平衡得出，同时也考虑一定的性价比等因素。这样形成的BCU在保证性能的前提下，提供了较好的性价比。图5-37为BCU参考架构模型示意图。

另外，通过BCU和多分区数据库来构建企业数据仓库不只是提供了针对数据仓库的高性能、高扩展性（包括水平扩展和垂直扩展）能力，它的最大意义是使得数据仓库的基本设计和实施都可以标准化。(www.xing528.com)

（2）大数据分析类应用计算架构设计考量 目前，大数据系统多采用分布式服务器集群来支撑。例如，目前比较典型的有Hadoop、Spark和Storm等分布式计算系统。针对大数据系统技术架构层的服务器集群，建议从以下三个方面加以考量：

①大数据集群节点组成。大数据集群节点可分成两类：一类是管理节点（或称为控制节点）；另一类是数据节点（或称为计算节点）。由于大数据系统采用的分布式架构通常具有良好的可伸缩性，所以，在大数据系统集群设计时，通常建议系统的起始节点数目可以采用满足一个阶段性目标即可，待系统整体数据量达到一定规模后再进行有计划的系统扩容或节点增加。

图5-37 BCU参考架构模型

②大数据集群节点处理能力。管理节点，由于这类节点位于整个分布式系统的中心，网络能力需满足现在和未来的系统需求，同时建议选用可靠性较高的服务器，同时系统上做必要的高可用和冗余设计，在CPU和内存方面通常建议采用中档的硬件配置或与数据结点一致即可。

数据节点，数据节点按应用类型细分为两种：一种是计算密集型；另一种是数据密集型。对于计算密集型，数据节点服务器选型时应侧重于CPU和内存方面的考量，通常建议可在CPU和内存方面采用中高档的硬件配置，网络和存储方面满足需求即可；对于数据密集型，在CPU和内存方面通常采用中低档的硬件配置即可，选型时建议侧重于网络和存储方面的考量，通常建议在网络方面可采用多个网卡绑定或万兆网卡等，甚至未来可能会逐步采用RDMA等新技术，在存储方面，对存储容量和扩展能力方面有较高要求，通常建议数据节点需能够配置16块或更多的大容量内置硬盘。

③大数据软件。操作系统：目前大数据软件多与开源软件有千丝万缕的联系，所以操作系统以Linux类操作系统为主。大数据平台软件：大数据处理主要使用开源的Hadoop/Spark软件。考虑到开源软件的技术支持、版本兼容性、稳定性和处理效率等问题，目前市场上出现了很多基于开源技术的商业大数据平台软件。这些商业化大数据软件基本都是各软件厂商在开源技术上进行了技术优化、组件替换、补充功能开发（如增加可靠性设计、SQL引擎、实时数据分析支持、开发工具等）之后完成的，有助于解决银行用户更好的使用大数据处理技术。大数据应用软件：基于大数据平台软件可以开发出相对应的大数据应用，如历史数据查询、银行反欺诈分析、金融产品营销分析等。

（3）非结构化数据管理类计算架构设计考量 非结构化数据通常包括图片、音频和视频文件、文档等数据，又称为“内容（Content）”。由于非结构化数据的存储、获取等有效管理，不方便用数据库二维逻辑表来表现，同时往往由于其容量巨大，增长迅速，因此，通常采用文件系统存放，并利用非结构化数据管理平台，即现在普遍称为的“内容管理平台（Content Manager，CM）”来进行有效管理。一个典型的内容管理平台通常包括数据库服务器、应用服务器及相应的文件系统。

目前，内容管理已经逐步扩展到整个企业，从初期的非结构化数据的存储与维护等，扩展到案例的协作、内容、流程、分析等。现在我们统称之为“企业内容管理平台（Enterprise ContentManager，ECM）”，如图5-38所示。

图5-38 企业内容管理平台

内容管理平台的内容实际存储多采用文件服务器，以文件系统的方式存放非结构化的内容数据，而不是关系型数据库。目前比较常用的文件服务器系统，一般为NAS存储或并行文件系统。因此，在设计或部署内容管理平台的计算架构时，重点是关注如何考虑文件服务器及数据存储，主要有如下几个方面：

1）容量及性能的评估：评估需要存放或管理的目前活动的数据容量与文件数量，以及将来数据的增长。例如，目前已经存在的文档及图片大约10TB，未来三年里每年会以30%的速度增长。同时，需要考虑文件服务器前端的并发连接数与所需的I/O带宽。通过性能评估结合容量评估，能够了解到文件系统的规模、服务器的数量与配置。

2）数据存放的策略：考虑内容的保留或过期策略，这需要依赖业务需求或合规要求，通常很重要。对于技术架构来说，需要根据数据存放的策略，合理规划好在线和离线数据的容量。一般来说，可以通过专门的备份和归档服务器来实现。如采用并行文件系统作为文件服务器解决方案，有的并行文件系统已经集成了数据生命周期的管理策略。当然，目前的一些ECM解决方案有些已经集成了备份和归档的功能，可根据实际情况具体设计。

3）高可用与容灾：对于本地高可用，应用服务器通常采用硬件负载均衡方式部署或者中间件软件集群方式，数据库层通常采用关系型数据库的集群或高可用解决方案。如采用并行文件系统作为文件服务器，并行文件的I/O节点可以组成并行文件系统集群，提供前端高可用的文件服务。如采用NAS解决方案，则需要考虑存储系统的高可用设计，这里不做阐述。对于容灾的考虑，在传统DR方案的基础上，需要额外考虑文件服务器的容灾设计，以保证内容数据的容灾，例如并行文件系统可以支持远程数据的复制功能。