传统银行结构的变化
上世纪90年代初，国内银行业蓬勃发展。90年代初，所有分行都是手工记账，由省级分行定期向总行系统提交。随着国内经济的快速发展，银行的业务量也猛增。这种工作模式已经不能满足需求。因此，20世纪90年代初，四大国有银行加强了科技部的R&D投资，并开始参考美国和英国的银行体系建设经验，建设现代银行体系。其实那时候大家对电脑的印象还是很陌生的。每个柜台都安装了电脑。当时的计数器系统是统一的命令行模式，没有可视化界面。后台系统采用集中式架构，如下图所示:
当时的银行体系基本就是这样的集权结构，大型国有银行一般也是这样的简单结构。当时大部分行业的系统也是这样的结构。在这种架构下，柜台的前端和后端系统采用CS架构和胖客户端模式，每次客户端升级都需要提前一天将安装包发送到所有网点，这在现在看来是比较低的。银行后台是大核心模式，即核心系统承担主要功能，账户、存贷款、总账、对账、支付、收账等功能都在集中的大核心系统中，只有少数功能从核心系统剥离出来，属于外围系统。这些外围系统一般都是市场上一些软件公司提供的现成产品，只需要简单的二次开发就可以满足需求，一方面降低了开发成本，另一方面也加快了系统实现的进度。但是这种架构的系统承载能力还是比较有限的。随着交易量的快速增加，很快就无法满足需求了。听当年银行里的学长介绍的场景，他们的科技部每天都很忙，每个月的交易量都会大幅增加。每季度的计息日批和年终决算会让大家忙个通宵。这些记忆也成为了那个时代所有银行家的痛苦记忆。
集中式系统已经逐渐不能满足快速增长的业务需求，于是规模相对较大的国有银行开始考虑在各省级分行部署1套总行现有的集中式系统，然后每晚批量集中省级数据。这种架构可以最快的解决网上性能问题，但也会导致新的问题，即跨省转账交易无法实时到账，甚至同一家银行的跨省转账一般都做不到。因此，90年代中后期的系统架构图如下图所示:
看图可以发现，与之前架构的主要区别是将总公司的集中部署架构调整为各省的分布式架构，但这种分布式架构并不是我们现在讨论的互联网分布式架构，当时也没有成熟的分布式架构方案，所以当时的分布式架构实际上只是简单地在各省科技厅分别部署一套核心系统和配套的外围系统，独立运行维护。这就好像机构在整体行政关系上是一体的，但实际的科技系统是分离的，没有必然的联系。每天只进行数据交换，实现跨省转账、票据承兑等业务，所以很多银行业务效率比较低，很难满足一些紧急的客户需求。终于出现了一些现象。客户为了给跨省客户汇款，最快的办法就是先用自己本地的卡取现金，然后人肉到另一个地方。有朋友问他为什么不去当地。
随着2000年互联网的快速发展，近年来银行的科技水平也高速发展，各家银行的水平逐渐拉开。老省份分布式部署的业务问题逐渐凸显。工行率先从总行集合了之前分散的省行系统。收集系统没那么简单。为什么当年各省分开部署？正是因为集中式的系统架构已经无法承载每天业务量的高速发展。如果再收集一遍各省的数据，就意味着可能在核心批次用完，分发到外围系统的第二天就可以营业了。要做到这一点，科技部门的压力还是很大的，需要解决很多问题，主要包括以下问题:1)统一数据结构、数据映射、各省数据采集、数据迁移；2)新系统开发；3)系统采集对采集省份日常业务的影响；4)对分公司员工进行新系统培训；5)新旧系统的平滑迁移以及新旧系统之间的日常兼容性交互；6)总体生产迁移计划和撤退计划。我当时有幸在中国银行经历了这个过程。整个过程持续了差不多四年，从整体方案设计到系统实施再到后续的系统迁移和上线。这个过程很艰难，基本上加班成了常态，但我也在这个过程中学到了很多，也是快速成长的时期。整个改造的一个核心架构思路是对核心系统进行瘦身和简化，从而提高核心系统的业务处理吞吐量，购买最新的大型机保证处理性能和IO性能，将大部分业务从核心系统中分离出来。基本上，这种整体架构可以保证评估时未来65，438+00-20年的业务发展。下图是当时的整体架构，但是从这个架构中可以发现，整体架构的核心系统、外围系统、渠道系统都非常混乱，各个系统都是完全网状的，画面还没有完全画出来，因为画完之后基本看不出来，是一个非常复杂的蜘蛛网。因为有些系统是外包的，消息结构和其他系统不一样，所以一个系统一旦要和这些外来系统连接，就会遇到这样的问题，需要处理这些外来接口的所有消息，这就导致了大量的重复性工作。
大多数银行很快意识到了这种集中式网络架构的缺陷，而ESB总线架构恰好在当时流行，于是银行系统不可避免地纷纷实现了ESB总线。总线架构是在通道系统与核心和外围系统之间建立一个ESB总线桥。外围和核心系统的所有接口都在ESB总线上注册和发布，总线提供完全统一的接口标准协议，避免了每个系统访问同一套标准接口，不需要重复不同的消息协议。这种架构看起来很清爽，通道系统和外围系统调用各个系统的接口都很方便。这种架构在银行系统中已经实施了很长时间，包括现在大部分银行仍然采用这种架构模式。虽然现在看起来很普通，但在当时看来这种架构已经很完美了。而且这种结构即使现在也非常适合中小银行使用。
随着互联网的发展，网上银行、手机银行和直销银行成为新的渠道，人们开始快速接受这种新兴的互联网渠道。互联网总线架构和之前架构最大的区别在于安全架构，后面会单独写两篇关于安全的文章。架构其他方面基本不变，但是我们会发现一个现象，就是因为核心系统不增加大的功能，所以不断增加新的周边产品。当时中国银行有100多个外围系统，还不算一些即将下线的系统。随着业务量的不断增加，核心系统的业务量越来越大，总线的压力也在逐渐上升，总线机也在不断横向扩展。离开之前，总线集群已经扩展到100个节点。
2012之后，随着facebook和amazon开放平台的巨大成功，BAT逐渐开放自己的接口，实施开放平台生态系统战略，从而推动SOA服务更快的发展。银行之前一直在研究服务的实施方案。但是由于ESB bus架构运行非常稳定，没有问题，所以各家银行进行服务转型的动力不是很强，而且这种整体架构的调整涉及到非常大的部门和业务影响，即使是一般银行这样相对安全的公司也不敢有大动作。有幸在银行里赶上了中国银行的互联网金融试点，对新建的互联网金融系统实施了面向服务的架构。以下是当时中国银行的互联网金融服务架构，实际上是传统银行互联网金融的折中架构。
从架构图可以看出，左边是银行传统的集中式总线架构，右边是互联网服务架构，包括开放平台、服务注册和发现、服务产品体系。为什么要这样设计？这是因为传统银行的产品体系都是比较稳定的，所有进过银行体系的同学都知道，传统银行建立一个新的体系或者实现一个新的需求都需要很长的周期。传统银行都是瀑布式的开发方式，各种审核审批流程，导致从需求提出到功能上线基本都是三个月，效率还是挺低的。完全不能满足互联网金融快速迭代的需求，因为当时我们不仅试点了新的soa架构，还试点了迭代开发。因此，互联网金融产品是分开实施和部署的。如果产品系统涉及到调用传统银行产品接口，那么所有的传统银行产品系统接口都是通过ESB总线调用的。所有互联网金融产品系统都向服务注册中心注册了接口。当时我们所有的互联网金融产品系统都是基于阿里巴巴的dubbo开发的，所有的接口都注册到zookeeper。两个系统之间的直接服务交互采用RPC模式。通过开放平台提供接口暴露，可以发现这种架构既能保证传统银行系统的稳定性，又能满足互金需求的快速迭代实现，还能利用新兴的互联网分布式技术降低开发和运维成本。目前我知道的很多银行都在采用这种架构来实现互联网金融服务。
近两年，随着容器技术的不断发展，私有云平台和devops逐渐在银行系统试点。目前我所在的一家小型民营银行正在进行这项技术试点。docker用于底层的镜像管理、构建和发布，系统级采用全面向服务的架构。目前我们使用的是springcloud的整体解决方案。这种架构看起来也很清晰，扩展性很强，可以很好的满足未来业务发展的需求。随着docker技术的不断成熟，后续的devops将逐步取代大部分人工运维。我之前待过的一家互联网电商公司，80多个产品系统只有3个运维人员，日常监控和版本部署全部自动化，基本不需要人工干预。这种模式也是后续银行需要的开发和运维方式。
今天我只是简单介绍一下银行体系的历史变迁。真的只是很简单的介绍。其实每个建筑都有很多故事，我可以写很多。以后有时间我会写很多发生的细节:)