本文将介绍银行IT系统的主流架构，了解完，能对系统有个整体的认识，避免因专注于具体工作而对系统的整体认识较弱，缺乏大局观，沟通成本大。因小编水平有限，文章不足和错误之处，欢迎指正！

   如果你有任何疑惑，欢迎关注微信公众号：小代嘚吧嘚（ID：xiaodaitalkshow），加入我们的银行核心系统大本营，一起学习、交流探讨、共同进步！

目录：

一、集中式架构

（1）概念及特点

（2）在银行业中的运用

（3）从主从架构到集群架构

二、分布式架构的演进

（1）分布式出现的背景

（2）从集中式到分布式架构

（3）不同模式下的优缺点分析

一、集中式架构

集中式架构是由<u>大型主机</u>的到来而兴起的，此后IT系统快速进入了集中式处理阶段，国内商业银行的核心系统多数采用基于IOE（IBM、 Oracle、EMC）技术的集中式架构，主机资源集中在大型主机或小型机上。

集中式架构在服务器的部署上有两种方式：

· 单机式，指所有的业务集中至一套服务，部署服务在一台服务器上，所有的请求业务都由这台服务器处理。

· 集群式，可以理解为单机的多实例，是在不同的服务器上部署同一套服务对外访问，实现服务的负载均衡。（负载均衡：协调集群里的每个服务器均衡地接受业务请求）

两种方式在扩展性、耦合性、资源利用等方面各有利弊。一般来说，如果单机性能足够，那部署服务到一台服务器显然是最高效的。

但现在考虑去IOE，单机性能恐怕不足，可以将联机交易的应用分开部署。

（1）.概念及特点

集中式是指由一台或多台主计算机组成的中心节点，数据集中存储于这个中心节点中，并且整个系统的所有业务单元都集中部署在这个中心节点上，系统的所有功能均由其集中处理。

也就是说，在集中式系统中，每个终端或客户端机器仅仅负责数据的录入和输出，而数据的存储与控制处理完全交由主机来完成。

集中式最大的特点是部署结构简单，由于集中式系统往往基于底层性能卓越的大型主机，因此，无需考虑如何对服务进行多个节点的部署，也就不用考虑负载均衡问题。

但缺点也明显，比如集中式架构在设计上是一个单点，且单服务器的造价昂贵，所以系统横向扩展性差；再如，发生单点故障（单机不可用即全部不可用）会导致系统停机，且维护时要暂停业务，对银行的运营影响严重。

（2）.在银行业中的应用

从90年代初开始至今，国内银行业信息化建设已经走过近30个年头，在这个过程中，出现了多种建设模式。

四大国有商业银行都选择了几乎全部自主开发的模式。整体来看，发展历程大致分四个阶段，如图：

[图片上传失败...(image-46dc28-1578981889619)]

第一阶段：从90年代初到96、97年，分别建立了对私、对公和联行汇兑等独立的业务系统，采用PC机+终端，数据分散存储的架构。

第二阶段：从96、97年到02、03年，引入小型机（有一些AS400，某些发达地区甚至还运用了ES9000），按照C/S架构、或者三层架构构建城域和省域数据集中的综合业务（包括了主要的、标准化的业务）系统。

第三阶段：从02、03年09年，普遍运用大型机，以全国数据大集中和建设几乎囊括银行所有应用、功能极为全面的核心银行系统（基于一套统一的平台或框架的超级大核心）为标志。

第四阶段：至09年之后，随着Java在外围系统和管理系统广泛应用，国内银行也开始逐渐接受基于Java的银行核心系统产品，往后出现了分布式架构。

从这个发展历程可以看出（除第四阶段外），大型银行的业务系统一代比一代集中、一代比一代综合。

这也意味着银行系统已经从单机式组件完成像集群式系统的转化。这种集中、综合的架构好处显然易见：

1）.开发的角度

如果各应用系统能够综合在一起，构建在一个统一的框架或平台上，那么，它们之间的交互和应用集成（EAI）就非常方便，应用运行起来非常可靠，性能指标也最高。

比如，一个应用调用一个记账的接口，是以函数调用或者类似函数调用的方式进行，相关逻辑往往都在一个线程内执行，这使得数据交换（函数传参）非常高效、可靠，在数据库事务机制的支持下，也不存在数据一致性问题。

相反，如果产品应用和帐务管理应用是独立、分布的系统，那么，这种调用就必须基于系统间通信进行，开发不方便，数据交换低效、不可靠，并且会产生严重的数据一致性问题。

2）.运维的角度

对于整个IT系统而言，这样的架构能够以最低的成本做到极高的可靠性——只需要针对核心银行系统部署时几个关键的逻辑节点制订一套高可靠性部署方案（集群、灾备等等），并配以相应的运维保障团队，那么，整个IT系统运行的可靠性问题就基本解决了。

相反，独立、分布的系统往往由于技术架构不统一，质量良莠不齐，制订高可靠性部署方案并配备相应的运维保障团队代价巨大，加之未来的应用环境中，这些系统相互间存在大量的调用，可靠性相互依赖。

因此，站在全局的层面看，其整体可靠性不如集中、综合的系统。

（3）.从主从架构到集群架构

1）.主从架构（单机式）

银行核心系统建设初期，好比团队初创期，资源有限，人力不足，为了快速开发一个产品，或上线一个网站，单机+备份机系统架构往往是一个不错的选择。

以热备用方式为例，一旦生产主机发生故障，便会自动切换到另一台备用主机接替服务。

如下图：

[图片上传失败...(image-75b708-1578981889619)]

主从架构是集中式的实际结构之一，即单机式，简单的说就是应用程序和数据库绑定在一起，本地访问。

这种结构在10年前建成的核心系统采用的较多，那时的银行核心系统开发基本使用C语言和COBOL语言。

2）.集群架构（集群式）

随着Java的广泛应用，国内银行开始逐渐接受基于Java的应用（如外围系统、管理系统），往后兴起了java版的银行核心系统产品。

即便不是基于Java的银行核心系统产品，大多数也实现了服务化设计的架构思想、具备各模块的集群部署及灾备等一套高可靠性部署方案。

如下图：

[图片上传失败...(image-5451c4-1578981889619)]

由上图可以看到，不同的服务器上部署同一套服务（即应用系统）对外访问，采用并置式集群部署，形成了标准的松耦合架构，当单套服务故障时，只影响全部客户的部分业务。

在数据库层面也大多采用集群部署（如ORACLE RAC），应用系统对数据层面的依赖性低，且无须考虑各套服务之间的数据同步问题，通过负载均衡处理，在一定程度上提升了不同业务之间的数据库的并行处理能力，以及避免了服务器资源的冗余。

从整体上来看，集群架构（集群式）具有诸多优势，比如在解决性能可伸缩性的同时，技术复杂度并没有显著增加，降低了单点故障的影响力。

对于该模式，建议将每次交易请求处理链上的各模块、及各业务处理逻辑，在实践上放在一个服务器本地完成。

从而保证交易实时一致性的严格要求，避免在部署大量应用服务器的同时，出现各服务器之间的业务之间高度关联，从而导致事物不一致问题，甚至是全局故障。

★****引申阅读（数据库集中式部署）

根据某行上线系统及重要改造系统的功能定位，并结合行内现有资源现状，采用配置较高的硬件设备来集中化承载各系统的数据库。

在同城主数据中心内，由2台小型机作为物理运行平台，在同城备份数据中心有1台小型机做灾备机。主数据通信与备份数据中心之间采用裸光纤网络连通，RPO≈0。

主数据中心DB在部署方式上采用Oracle RAC方式，实现数据库集群，避免数据库的单点故障。具体实施如下图：

[图片上传失败...(image-3632a0-1578981889609)]

二、分布式架构的演进

（1）.分布式出现的背景

2016年7月15日银监会在官网发布的《中国银行业信息科技“十三五”发展规划监管指导意见》中也提到要“积极开展云计算架构规划，制定云计算标准，联合建立行业云平台，主动实施架构转型，稳步实施架构迁移，到“十三五”末期，面向互联网场景的主要信息系统尽可能迁移至云计算架构平台”。

加上近年来以阿里为代表的互联网企业提出的“去IOE”，希望打破国外技术垄断的局面，以及移动互联网、大数据、云计算等新兴技术的迅速大致和广泛应用、业务量的迅速提升，当前IT技术架构面临极大压力和风险，在这种背景下，分布式架构受到越来越多的关注，应用范围逐步扩大。

由此，计算机系统正在经历着一场前所未有的从集中式向分布式架构的变革。

（2）.从集中式到分布式架构

分布式系统的定义在《分布式系统概念与设计中》是这么说的，“是一个硬件或软件组件分布在不同的网络计算机上，彼此之间仅仅通过消息传递进行通信和协调的系统”。

这个定义几乎覆盖了所有网络化计算机的系统。

在银行核心系统中，分布式架构可以理解为是对核心的应用系统进一步层次化、细粒化，然后按层次、模块分别打包成独立的小应用，每一小应用作为一个独立的部署单元，分离后的小应用之间可通过远程请求方式或共享服务组件方式完成跨应用调用。

分布式架构主要着力于服务分层、服务分区、关联服务调用解耦以及数据库分库分表等方面，也就是常提的微服务，即一部分应用部署在不同机器上，也可能分布在不同的机房中，甚至在不同的城市。一般来说，非同一机房的网络条件下，跨机房访问不是好的方法。

如果应用分离，数据库分布式的话，有两种模式（但分布式做法是只访问一个分片）。

两种模式如下：

1）.一个应用可以访问所有数据库(分库)

[图片上传失败...(image-f518f5-1578981889609)]

2）.一个应用只访问一分片数据库(分表)

[图片上传失败...(image-e02642-1578981889609)]

不难看出，核心系统内部服务走向微粒化、单一化、标准化，并根据粒度进行分层，上层完成对下层的服务组合。

在设计服务时，不需关注所依赖的服务是否在本地，统一通过注册中心（或多级注册中心）完成服务寻址并调用。当然，也不是应用并发越多越好，因为并发越多，调度也就越多。

但，银行真的有这么大的有效数据量吗？

真正有用的账户，单机承载不了吗？

站在发展的眼光看，客户和交易量的上升，是没有摩尔定律那么快。（摩尔定律：当价格不变时，集成电路上可容纳的元器件的数目，约每隔18-24个月便会增加一倍，性能也将提升一倍。 ）

因此在项目实施时，银行自身的访问并不需要复杂的多级、多片式服务分布部署，加上网络传输消耗，以及分布式对未来的短板依赖很大，未来的长处反而被规避掉了等问题，使得分布式系统平台回到最初了。

即，具备分组服务控制能力的集群应用架构。

（3）.不同模式下的优缺点分析

总的来说，银行核心系统进行分布式改造没有太大必要，当数据或交易量到达一定程度才需要考虑系统架构，量小的话可以增加内存、CPU、机器等方式来解决问题。

不过金融科技是趋势，对IT管理者而言，最看重的是低成本、运行的稳定性、高效运维、复用、技术的前瞻性与可控性。从长远的角度来看，传统银行的研发模式一定会拖后腿，是危机也是机会。

集中式与分布式优缺点对比，如下图：

[图片上传失败...(image-6817c1-1578981889609)]

综合而言，新一代银行核心系统建设需要先认清自身IT架构和业务构成的设计目标（如要求性能更多，还是要求降低机器压力更多）。然后积极的拥抱变化，再结合使用场景进行理性的选择、谨慎地规划，发挥价值。

完

参考或引用文献：

1.马智涛,卢道和,李靖.《新一代银行IT架构》,2019年

2.王汉明.《银行信息系统架构》,2015年

3.张国建.《中小银行核心系统分布式架构思考》,2017年

4.efsca.《2个架构路线，我们该如何抉择》,2013年

5.网络.《城商银行新一代核心基础平台高可用架构建设经验分享》

下一篇，我们聊古建筑的技术架构与今天的金融科技的技术架构。如果你感兴趣，请转发为我点个赞，同时也欢迎和我联系。

[图片上传失败...(image-3b9545-1578981889609)]

��E�'�