概述：

（ 一）分散式架构

1、手工时代（20世纪80年代以前）

在没有电子计算机的时代，当时银行叫做储蓄所，专门给储户办理存取款业务。在柜台前，由出纳和会计人员负责存取业务的现金收付、以及账本的登记，常常可以看到一堆摞的高高的账本，一个墨水瓶，一只填写凭证的蘸水笔，一把用来记账和轧账的算盘……

储蓄所职员完全是依靠手工操作办理业务，无论是客户业务办理，还是计息结账、内部往来对账、编制报表等都靠人工处理。比如营业时间的存取款，从收钱、点钞、登折再到另一个人的复核、签字、盖章、记账，最快也要二三十分钟；再如每天营业结束后的“扎账”，若总账和明细账没有扎平，就必须连夜加班查账找出原因，直至账目齐平。

图1-1 银行办理业务场景；储户的账本与账页

纯手工时代的银行业务办理不仅耗费大量人力、效率非常低、资金周转慢、信息不灵通，例如票据或者纸质凭证的传递与交互；而且风险控制也是一大难题，比如手工记账的误差在所难免、登记凭证或账本易丢失与污损，甚至是发生火灾等问题。

手工时代只解决了能够办理银行业务的问题，显然无法满足中国银行业发展的需要。随着电子计算机的出现，银行业进入了电子化的初期阶段，通过简单的模拟手工操作，主要解决了手工操作和业务处理的效率问题。

手工时代留下了很多的名词和概念，一直到现在，在系统中都还能看到历史的痕迹。

例如，“台账”、“登记簿”在手工时代就有相应台账的账本或登记簿去记录一些事情，在用计算机模拟手工时代的做法时，也就将相关概念都引入到系统了；再如“出纳”，手工时代区分出纳与会计，因此在系统打印的回单上，有时会出现“出纳会计”的字样；又如“储蓄天数算法”，手工时代为每一位储户计算利息很不方便，为简化操作和减轻银行工作人员的工作量，规定了不管大月、小月都是按30天，一年按360天计算利息的算法，在目前的系统当中还有使用。

2、PC单机（20世纪80年代前期）

七八十年代之前，在银行的柜台前，永远看到的是摞的高高的账本，银行工作人员基本用的是算盘和钢笔。别说异地取款，就算是汇款，那也要等上至少15-21天以上。相比于今天的秒到实施汇款转账，那是万万不可想象的。以一笔资金从甲行到乙行的处理过程为例：甲行需要手工填写一式三联的联行报单，自己留下一联，把剩下两联通过邮局寄给乙行（邮政的速度）。乙行核对无误收账后，再把其中一联寄给总行对账中心，总行把行号、金额等信息制作成卡片。超过对账期而资金还未到账，甲行就会发查询函、发电报甚至派人去查询（电话没那么普及）。当时，人民银行总行的联行对账每年结清一次，一般延迟四五个月，最长的一次对清达19个月。显然这样的效率是无法满足中国改革开放发展的需要。

其实早在上个世纪70年代，中国就开始部分银行电子化最早的尝试。1975年，第四机械工业部与中国人民银行联合下发了《关于下达大中城市银行核算网试点任务的通知》。试点工作的总体设计就是“三点两线”，三点是北京、西安、上海，在这三个点各布一套计算机，两线就是北京-上海、北京-西安两条线路。

这个时候国产计算机扮演了重要角色（下面给你分析原因）。北京试点采用了江苏无线电厂生产的C-4样机上会计核算系统。当时的C-4只是一个裸机，内存是磁芯的，外存配置的是磁鼓，速度很慢，占地却很大，占了一间二三十平米的屋子。C-4机还没有来得及配上高级编程语言，技术人员只能在C-4机上用机器码编程，非常艰苦。西北大学卞雷老师带领的应用软件开发人员依然在很短时间内完成了银行会计软件编制，在中国人民银行南礼士路分理处投入了实验。“三点两线”项目虽然中途下马，但它作为银行电子化第一战的历史意义不可磨灭。核心原因还是：产品根本没办法真正投入使用，又慢又大。

为什么国产扮演主要角色？在这个阶段，文革尚未结束，国际上还处于被孤立环境。扒一扒这个“巴统”：巴黎统筹委员会（Coordinating Committee for Export to Communist Countries），是对社会主义国家实行禁运和贸易限制的国际组织。正式名称输出管制统筹委员会。是第二次世界大战后西方发达工业国家在国际贸易领域中纠集起来的一个非官方的国际机构，其宗旨是限制成员国向社会主义国家出口战略物资和高技术（美国对华为禁售，这个事是有历史传统的）。列入禁运清单的有军事武器装备、尖端技术产品和稀有物资等三大类上万种产品。服务器计算机就在其中。正是由于这个巴统委员会，我们的两弹一星都是用算盘打出来的！

由于中美之间的破冰建交，逐渐放开了部分计算机的进口。后来“巴统”退位了，但是生出来一个儿子叫“瓦森纳协定”登基，至今照样在半导体、光刻机、高精密机床领域卡住咱们的脖子。说到底，这个世界国与国之间没有对错的公平准则，只有利弊的价值交换。

1978年，银行迎来了改革开放的春风。中行广州分行、青岛分行、人行陕西省分行等纷纷酝酿引进意大利A-4、日本理光-8等国外先进的电子记账机进行试点，能够自动记账、计息和打印账页。这个时候时候还不能称为真正的电子化，只能称为专用记账机。因为这样的产品，无法按照客户的业务需求编程，也仅仅完成银行业务中的一部分自动化而已。历史看来任何行业都是从：人工->自动化->电子化->网络化->智能化一步步发展而来。

直到1979年，邓小平同志指示，“要把银行办成真正的银行”，改革的春风和中美关系回暖把中国银行业吹进了新发展阶段。考虑到银行业务的重要性，中央大力支持银行业应用计算机。

国务院批准银行业可以引进外国计算机进行试点。国内一没半导体、二没有集成电路技术。国产计算机市场化产品几乎不可能制造出来。当时中国银行和中国人民保险公司也归中国人民银行管（所以说银保监会合并是有历史惯例的），人民银行总行启动了YBS（银行保险系统）项目。YBS项目分两部分：

一部分是引进IBM 360系统，解决香港13家中资银行的电子化。

另一部分，1979年，日本首相大平正芳继田中角荣之后访问中国，并开始向中国提供政府开发援助（ODA英语：Official Development Assistance，缩写为ODA；又称政府发展援助、官方发展援助），对中国的经济建设起到了积极的推动作用。那时候是中日关系开始回暖的美好时代，ODA项目资助另一部分在北京、上海、天津、西安、南京、广州6城市引进日立M-150中型机，在杭州、青岛、安康等城市引进日立L-320小型机，开发银行会计联机实时处理系统和联行对账系统。YBS项目在1980年陆续上线，使中国银行的电子化圆满完成了起步。

日立M-150中型机

当日本人援助中国计算机系统的时候，美国人自然不能闲着。怎么能让日本人的系统和软件占领中国的核心金融应用呢？另外参考这篇文章《以史为鉴：美日贸易战往事》，那个时候正是美国要敲打火箭速度上升的日本的时候。美国人要影响中国的核心金融应用，必须走美国的技术体系。

1987-1988年，符合中国国情的SAFEII（IBM定制化的）第一版在工行网点大量上线，于此同时，中行的SAFEII上线几乎与工行同步，而建行的SAFE应用在随后两年也上线，在当时多数银行业务还依靠‘流水账式’手工操作的业务模式下，中国银行业几乎没见过真正的银行核心应用是什么，透过SAFEII，银行才有了对系统的认识，也开启了信息科技的发展之路，各家银行都借助IT之力开始规模扩张。

由于IBM当初给银行客户提供一个完整的商业应用SAFEII，并且对SAFE源代码开放并帮助客户改造应用，铸就了其后三十年主机在中国银行业的“霸主”地位，时至今日四大行的核心系统还都跑在其上。谈及主机，银行是又爱又恨。爱的是只要你肯花钱，IBM就手把手全教你，24小时全方位服务。恨的是，这么多年了。你教我的武功，只能在你这个台子上练，上台费太贵了，一年十几亿的花销。于是便有了后来的主机降级为小机，小机转X86 PC Server，以及近几年的去IOE风向。（“国产替代”改名“安可”项目，是中国各个央企的一把手项目）

政治经济，中国一直都是这一条主线。香港作为世界窗口的桥头堡，选用国际主流产品；中国内陆在摸着石头过河，有ODA援助，同时鸡蛋不能放在一个篮子。那时候的中国和世界发达国家的差距，是让人崩溃的。市场换技术，也是当时我们中国的无奈之举。

在引入计算机之后，即20世纪80年代前期出现了PC单机时代，也称为“会计电算化”，就是把一部分柜员手工记录的内容，特别是会计账簿和记账传票，使用计算机来实现数据的登记和保存。从而减轻人工登记和处理的负担，加快业务办理速度，提高工作效率。

通常每个储蓄所或营业所会配一个PC单机，柜台人员会将手工登记的信息录入到计算机系统中保存，从而实现银行每个营业网点单独一套“电子的账本”，形成了非纸质记账的方式。

由于还没有互联网，每个网点安装的计算机设备都没联网，拥有各自独立的系统，各个网点分别处理自己的账务信息，所以没有通存通兑功能。基本上都是以网点为单位，在哪里办理的开户，就只能在哪里办理业务。跨储蓄所的交互，还是和手工时代一样走纸质票据或纸质凭证的传递，总的来说，是解放了一部分的手工操作，解除了原先很多在纸质上面的记录。

图1-2 银行储蓄宣传&柜员桌上配置了电脑

当日本人援助中国计算机系统的时候，美国人自然不能闲着。怎么能让日本人的系统和软件占领中国的核心金融应用呢？另外参考这篇文章《以史为鉴：美日贸易战往事》，那个时候正是美国要敲打火箭速度上升的日本的时候。美国人要影响中国的核心金融应用，必须走美国的技术体系。

1987-1988年，符合中国国情的SAFEII（IBM定制化的）第一版在工行网点大量上线，于此同时，中行的SAFEII上线几乎与工行同步，而建行的SAFE应用在随后两年也上线，在当时多数银行业务还依靠‘流水账式’手工操作的业务模式下，中国银行业几乎没见过真正的银行核心应用是什么，透过SAFEII，银行才有了对系统的认识，也开启了信息科技的发展之路，各家银行都借助IT之力开始规模扩张。

由于IBM当初给银行客户提供一个完整的商业应用SAFEII，并且对SAFE源代码开放并帮助客户改造应用，铸就了其后三十年主机在中国银行业的“霸主”地位，时至今日四大行的核心系统还都跑在其上。谈及主机，银行是又爱又恨。爱的是只要你肯花钱，IBM就手把手全教你，24小时全方位服务。恨的是，这么多年了。你教我的武功，只能在你这个台子上练，上台费太贵了，一年十几亿的花销。于是便有了后来的主机降级为小机，小机转X86 PC Server，以及近几年的去IOE风向。（“国产替代”改名“安可”项目，是中国各个央企的一把手项目）

政治经济，中国一直都是这一条主线。香港作为世界窗口的桥头堡，选用国际主流产品；中国内陆在摸着石头过河，有ODA援助，同时鸡蛋不能放在一个篮子。那时候的中国和世界发达国家的差距，是让人崩溃的。市场换技术，也是当时我们中国的无奈之举。

其实在这一阶段已经出现核心系统的雏形，简单说就是一个后台会计的登记系统，主要功能有账务的处理、数据的记录，以及配套的柜员操作页面（即字符终端）与主机连接在一起，没有计算能力，只是一个显示屏幕，通过键盘传送输入要素并显示输出。

核心的主要设计思想是以“账户为中心”的金融服务体系，就是以账本为分户账来作为整个系统的一个中心或面对的一个对象，因此，账户在核心系统当中是唯一的关联标识，是将所有业务操作和记录串接在一起的关键要素。

由于每个储蓄所或网点都是单机，所以每个系统都是一个个信息孤岛，互相之间不能互联互通。

比如一个人在同一家银行有5个账户，5个账户可能是不同网点办理的，那银行的各网点就不能够总揽地了解客户，无法针对客户的财务状况和实际需求提供有针对性的服务。但同时，也为大规模引入全国联网的系统和业务流程再造打下了基础。

之后，国内开始建设网络基础设施，将各网点连起来实现业务联网区域的通存通兑，甚至发展到以省市级主机为中心，向省外网络连接实现省级互联互通……这就引出了下一个发展阶段——联网联机的时代。

3、联网联机（20世纪80年代末至90年代初）

存贷汇是银行的基本业务，跨网点通存通兑最常见，此前跨网点办理业务会用到票据（如本票、汇票），需要等待银行之间的票据交换，若干天后才能完成业务的办理，对客户来说时效性和安全性比较差，当引入计算机网络后提升了数据实时传送的能力。

基于该背景下建设了计算机网络，各个银行之间不再需要使用纸质的传递方式，就能够通过网络将不同的网点和不同的系统，借助通信设备和线路建立连接，实现了各地区、各部门、各应用系统之间的数据实时传输、交换、资源共享，实现了联机业务处理和异地跨行通兑。

比如2小时汇款到账、甚至实时汇款到账，极大地提升了客户体验。在发展到后期，有些地市借助网络更进一步，产生了区域性数据集中一种做法。

相当于网络建立起来后在某个地区设置一个区域性主机，让区域性主机提供统一的核心系统后台服务，网点仅保留柜面操作的模式，因此顺势出现了核心系统和柜面系统的分离。

图1-3 那时的ATM界面；新版计算机

与此同时，自动柜员机（ATM）开始大量出现，主要用于办理存入、支取或查询交易的业务。在国家的指导下，成立了以计算机、通信等现代科技为基础和银行卡等为介质的“金卡工程”并开始实施，通过计算机网络系统，用电子信息转账的形式实现货币流通。金卡工程首批12个试点省、市全部实现了同城跨行ATM/POS联网运行和信用卡业务联营，自93年金卡工程发起到97年底，已发行了5万多张卡。

对银行来说，主要是出现了一种叫银行卡的交易介质，不仅针对某一家银行可以使用，而是能全国通用。这一转变将银行服务网点做了很大的拓宽，原先的储蓄所变化为在人流量较多的地段设ATM机，甚至借用其他银行的ATM机也可以提供相应的服务。

由此，银行开始陆续出现除柜面之外的电子渠道，银行核心系统的设计理念也发生了变化。在银行业飞速发展的进程中，随着我国经济建设发展、改革开放的不断深入和即将加入的世贸组织，进一步加快了商业银行电子化建设的步伐。

从1979年到1984年，市场上相继出现了中国农业银行、中国银行、中国建设银行和中国工商银行，银行内和银行间的资金流动日益频繁，走邮政的手工联行效率低和差错多的问题也日渐突出，到了难以承受的地步。

手工处理阶段最大的难题，就是点多面大，效率非常低。“当时人民银行覆盖全国2500多个县，加上城市网点有3000多个。像上海南京路上的营业部，每天的联行业务就有几千笔。联行报单靠人工去比对，全国每个点都要设对账岗位，需要成千上万的人，效率很低。”有些事情，靠堆人，是永远不够的。

当时，国内银行基本都是一个庞大的、按行政区划设立机构的垂直经营管理系统，从上至下依次是总行、省分行、地区中心支行、县支行、分理处、中心储蓄所、储蓄所。网络化时代最大的变化，就是将一个地区原来孤立的点连接起来，从覆盖一个城市到多个城市连成片，最终使得全国大集中成为可能。

4、全国大集中（20世纪90年代末至2008年左右）

1987年，中国人民银行总行批准陕西、广东两个分行进行省辖联行网络化试点。1989年，启动了全国电子联行（EIS）项目（1989-2005）。这一系统采用了陕西试点成果，利用VSAT卫星通讯技术建立人民银行专用的卫星通讯网，连结各分/支行的基于PC机的小站，构建成了我国第一个全国大集中的处理系统。

没有电子联行的时候，一个企业要从工行汇款到另外一个农行，工行就要到邮电局去拍电报，一份给开给人民银行，一个分开给工商。然后由人民银行做清算。除了拍电报这个事走无线电，其他都是手工处理。也许这两个企业就是墙之隔，但我要给你一笔货款，却要银行系统内走半个月。大量现金被冻结成“在途资金”。

全国电子联行其实是照搬当年苏联的方法。但是我国的通信和信息技术又跟不上。举个例子，当时的通信有多差：从北京打个电话到齐齐哈尔，好歹齐齐哈尔算是大城市（黑龙江老二）。普通的民用线路，摇电话要摇3-4个小时。通信领域的基础设施一直困扰我们太多年了。可喜的是，正如1920年的美国靠电报和铁路建立起来庞大的帝国经济，在2020年的今天5G和高铁肯定会助力中国进入下一个全盛时代。

后来由人行时任副行长陈元（陈云长子）牵头向国务院申请卫星专网（很多事必须有东方红色神秘力量，你才能办成）。国务院批了，一口气一年建了200多个卫星小锅。这样才把中国主要的城市的银行联起来。当时地面没有光纤，有线线路基础设施不到位；卫星是国际标准技术，因此只能选择这样一个方法把大部分银行连成一张网。

EIS设计了全新的星型体系模型和配套的联行制度。银行每天业务终了立即通过网络系统完成对账，逐日结清。这是中国人民银行在支付系统现代化建设中的一次重要的里程碑，改变了以往由于纸票据传递迟缓和清算流程过分烦琐造成的大量资金在途现象，从而加速资金周转，减少支付风险。

EIS也并不完美，那时候有一个说法，叫做“天上三秒、天下三天”，人民银行通过卫星通讯网络几秒钟就处理完的业务，却因为人民银行给商业银行的接口慢，一笔款项要好几天才能到账。“天上三秒、天下三天”主要的原因就是商行营业网点与EIS没有实现网络连接，依旧要通过同城交换转送一次。假如一个人从北京的工商银行给上海工商银行某账户汇100元，北京的工商银行支行先要把数据提交给人民银行北京分行，等待一天只有2～3次的同城交换（注意，当时卫星覆盖有限，不是实时的哦），如果正好错过了当天的同城交换，只能等到第二天，这就耽误了一天。同理，人民银行上海分行把数据传递给上海工行分行又要耽搁一会儿，这就是所谓的3天了。

本质上，这张网还是区域自治、逐层上报的网，缺点明显。人民银行的领导们很快发现这个问题：需要建立一张全国的大网。来来来，各路财神都接入我，我坐庄，一个人做统一的支付和清算。就这样CNAPS中国现代化支付系统横空出世。

为迎接加入世贸组织的挑战与机遇，提升数据和技术力量的分散、业务处理缺乏标准规范、软硬件资源不共享、管理水平不平衡等问题导致的负面影响；加上计算机的硬件设备能力在不断提高、网络质量越来越好、网速越来越快等原因，数据大集中应运而生。

简单的说就是原先区域性的数据集中，但对客户来说，同一家银行是一个整体，任意网点都应享受同样的金融服务；对银行来说，将客户在各网点的信息汇总起来用于风险评估或评级，不仅能节省银行的管理成本，而且有利于对客户有更全面的了解后提供更好的金融服务。

数据大集中是各银行根据自身情况对数据和业务进行不同程度的集中处理。例如，将分散的省级数据中心的数据和业务集中到国家级的数据中心，实现系统基础架构、物理服务器、数据和应用建设的集中。

数据大集中使总行能够集中全部研发力量，从而避免低水平的重复开发，节约系统管理、软件维护及升级的费用；使总行能够得到准确、实时的数据，全面地了解到各分行的工作进展情况，以免增加不必要的后继沟通成本；使总行能够通过分析交易数据与交易行为，提升整体服务水平，减少因信息不对称而导致的银行风险管理失控或业务机遇丧失。

因此，国内商业银行开始重视规模化经营，掀起了一场以数据大集中为主线的技术革命和业务变革。同时也造成核心系统的数据量呈指数级增长，原先是一个地区或单网点的数据，经全国大集中之后数据量翻了10倍，甚至100倍并在一个系统中承担，而且系统可能要使用十年左右时间，对当时的系统设计来说是一个极大的挑战。

故各家银行引入IOE（IBM、 Oracle、EMC）模式，以总行业务集中化、流程规范化为目标持续改进。尽可能多地将业务纳入核心系统的统一管控并兼顾各地方特色，同时综合柜员制被普遍采用，打破了记账到出纳的原有业务办理模式。

图1-4 营业厅实行高柜与低柜；电脑在普遍使用

1999年9月1日，工商银行提出了以“9991”工程命名的大集中工程，用了3年时间将全国各地36个计算中心合并，建立了两大数据中心，即在北京上海建立了两大互相备份的数据中心，是我国数据大集中的里程碑工程。

2004年9月25日，工商银行通过数据中心整合工程的实施，将北京数据中心主机生产系统顺利迁移至上海，全行业务集中到上海数据中心处理。还完成了澳门、新加坡、东京、汉城、香港等亚洲地区省外分支机构数据的集中处理。

2002年7月1日，建设银行启动了为期3年的数据集中工程（DCC）项目，按期完成全行38个一级分行和总行营业部的全面上线，并在业务发展方面统一了全行会计核算和柜面业务应用版本，提高了跨区域交易和清算的服务质量，加速了全行的头寸管理和资金调度，实现了支持后台集中运行的业务模式。

截至“十一五”末，各大商业银行、全国性股份制银行、省级农信等经过了大约十年的时间，全国性的各家银行几乎都完成了省级集中或是全国数据大集中，将分散于各分行的业务数据集中至数据处理中心。

随后，银行业开始高速扩张物理网点和开始新一代渠道的建设，在代销基金、保险、代收代缴等业务开拓方面加大投入力度。特别是网络银行、电话银行、自助银行、移动银行等方面形成了新突破，不再是以各渠道相对独立的思想来建设。

随着渠道多样化的发展，市场对银行业务办理支持7*24小时不间断处理提出了更高的要求，因此7*24小时在当时的系统设计中是一个热点。

同时数据集中化在不断发展，客户信息都集中到了总行，系统中可以看到客户的全貌，并对客户进行数据分析，所以“以客户为中心”的新概念伴随着业务转型而陆续出现。

5、瘦核心（2008年至2015年）

经过全国大集中的建设，伴随着系统长期运行，逐渐暴露了一些问题。主要是核心系统越来越庞大，因为全国大集中后，核心系统纳入了各地区的共有功能之外，还包含了每地区的特色功能，导致系统耦合严重，形成了所谓的“胖核心”。

不仅限制了业务发展，还增加了建设和运营成本，每次修改都感觉牵一发而动全身，而且开发新功能时会发现改动与评估内容很多，开发耗时越来越长，无法做到快速的响应业务变化。

例如，无法快速推出有特色的产品响应市场需求来吸引客户；再如，因系统内部改动较大而无法给优质客户提供个性化利率；又如，因营改增的业务需求而导致记账规则的调整，需要在核心系统内部做手术，不仅需要投入大量的人力物力，而且风险很大，如果账务核算是一个相对独立的系统，那么就不会带来核心系统巨大的改动量，也不必为此承担大的风险。

究其根源，该阶段的银行核心系统其实也叫“综合业务系统”，不管是什么业务，都放在这系统中实现，只是将渠道端单独分隔开，但后台的处理功能全部综合在一起，用一个系统去完成银行的各种业务，这就必然导致成为大而全的系统，难以维护。

为了解决系统庞大耦合的问题，业内一致开展了核心系统瘦身的运动，喊出了“瘦核心、大外围”的口号，驱动了将核心系统的辅助功能都剥离到外围系统。

图1-5 叫号系统被广泛使用；智能设备遍布网点

从系统结构上来说，首先从核心系统中拆分的有管理类功能，建立各类管理系统。比如信贷管理系统、财务管理系统、柜员管理系统、额度系统，将办理业务前需要做的评级与审批类的管理性工作，拆离核心作为管理功能，也就是在完成各种管理性质的动作并通过后才说明能够办理该业务。所以可以拆离核心，只留下一个小而精的核心系统来处理核心业务、内容单一，核心系统通过接口与各管理系统连接，传递信息或进行相应的管理控制。

其次，从核心系统中拆分的有统计分析类功能，建立数据仓库。因为系统对数据进行分析与加工很消耗系统资源，而且也并非交易过程中急需使用的内容，可以在交易结束、获取数据之后再进行分析，通过数仓去解决耗资源的问题，不要让其影响整个业务系统的运转。例如，通过数据分析给客户打标签，标记普通客户、优质客户、VIP客户等。

还有，需从核心系统中拆分出报表功能。数据经过统计分析之后，需要给监管报送或给行内出具各种报表，既然统计分析类功能已剥离核心，那对于报表也要建立单独的报表系统进行加工与报送。

最后，还有第三方对接类的功能也要从核心系统中剥离。早期银行只会办理自身支持的业务，但随着网络的发展，银行与第三方的连接或是与第三方实时交互的功能越来越多，比如代缴水电费。

为提升系统间的交互效率，就出现了连接第三方的各类前置系统，以及专门做中间业务拓展的中间业务系统，使得行内能建立统一的交互管理标准。例如，建立了ESB服务总线、建立了ECIF全行级客户信息系统实现行内客户信息统一共享等。

甚至一些激进的银行，将核心系统中的账务内容也相应分开，比如建立贷款系统、存款系统、或是互联网核心系统等，并配套总账系统来汇总处理各账务系统的会计流水。因此，在核心系统瘦身阶段后期，逐渐出现了“大总账”的概念。

除功能瘦身外，核心系统的整体设计理念也全面转向“以客户为中心”。例如，指定编码规则生成系统唯一的客户号，再通过客户号管理同一客户下的所有账号，建立统一的客户信息视图，打破原有客户群各自封闭的情况。并将客户之间的关系进行归集（比如针对集团客户可归集其下辖各子公司的账户），实现客户与账户的多层级管理，掌握客户每笔交易的资金动态和流向等。

以客户为中心（复杂的关联关系），如下表： 

图1-6 复杂的关联关系

除了“以客户为中心”之外，还引入了产品工厂、定价模型等参数化、配置化的设计思想，大大提升了银行核心系统的灵活程度与健壮性。

通过系统参数的灵活配置实现产品特色化，通过对客户需求的聚焦，进而对指定客户群或是个别优质的客户提供有针对性的服务，比如提供利率、费率及汇率的差异化定价，在吸引新客户和留住老客户的同时，也为今后业务的发展奠定了坚实的基础。

此时的银行核心系统仍处于全国大集中的阶段，在2015年后，业内才逐渐进入了分布式微服务时代，采用了新的互联网思路去构建银行核心系统。

6、分布式微服务（2015年至今）

2015年作为民营银行元年，网商银行于2015年6月、微众银行于2015年9月正式开业。拥有互联网基因的民营银行，与原先以大型主机为主的全国大集中时的系统建设模式不同，采用了去IOE的分布式微服务架构来建设核心系统，给行业提供了一种新的设计思路，同时对传统银行也产生了较大的触动。

其次是近年来，在监管要求和鼓励国产化的大力推进下，如2017年中国人民银行发布了《中国金融业信息技术“十三五”发展规划》，明确提出“以安全、可靠、高效、弹性为重点目标实施架构转型，探索分布式架构和成熟开源技术应用，逐步减少或摆脱对单一技术产品的依赖”，因为国产化在大型主机为主的方向上有所缺乏，所以在寻求新的建设方向上多了一个选择，分布式核心系统出镜率越来越高。

分布式核心系统与集中式核心系统是相对的，有好几种组建模式，接下来逐一阐述，还包括分布式微服务的核心与以往传统核心系统的区别。特别值得注意的是，分布式和微服务两个词经常是同时出现，但却是两个不同的概念，不能混为一谈。

分布式是指核心系统对存储数据使用多机进行分片（即数据库的处理）,原先的单机系统或上一代的核心系统，对于数据来说是存储在一个数据库上，单机系统的存储空间受限于硬盘或上限，若要支持海量存储则价格非常昂贵且存储性能也有一定上限。

其次，CUP和IO也受限于单机系统本身的资源限制，若是用多机分片就可以将单机器的工作分散在多台机器上，那就可以根据数据量的规模做横向的扩展，使用计算能力稍微差一点的机器通过拼数量的方式做到海量数据的及时处理；还需避免单点故障，或者说机器突然之间变成不可用，那会影响整个系统的所有用户、客户及账户等。

因此，分布式目的有两个：一是突破单机系统的数据存储和数据处理能力上限，使得数据量规模可以横向扩展；二是分片后减小单台机器设备突发故障的影响面，使得一个故障只影响一个分片的机器，而其他分片可以照常处理。这样就不算系统整体中断服务。

分布式银行核心的功能主要是针对于数据存储，提高了银行系统运转的健壮性或可用性。而微服务是另一个着眼点，抽象地说是指核心系统应用程序的一个部署与拆分的模式。

具体的说是指核心系统按照功能模块进行服务拆分，原先可能是将各个模块的所有程序全部打包在一起，作为一个整体去运转，再按照微服务拆分之后，只需要按模块进行相应的服务拆分，拆成一块块小的包，然后对每一块做单独的打包并部署在不同机器上，目的是解决模块间的耦合问题，用来降低系统修改时的影响范围和难度。

从银行核心系统的数据库方面看，分布式的发展经历了以下几个模式：

1）应用数据库一体化模式

应用数据库一体化是核心系统最早期的模式，如PC单机和最早期大集中阶段，核心系统的应用程序作为一个整体部署和运行，与数据存储（即主机的文件系统或开放平台的数据库）合在一台高性能机器上。

因为应用和数据库在同一台机上运行，所以应用模块之间的调用，属于程序内的函数调用，应用进行数据库操作属于本机访问。

在该模式下，本地调用消耗最少、单笔交易的处理耗时也非常短、交易响应速度很快，当然，对高性能机器的压力也相当大，既要处理数据库文件也要处理应用程序的逻辑计算，若是在机器性能不太够的情况下或交易量提升后，容易形成资源争抢。

IBM大型主机即此类模式，优点是应用与数据文件一体化，应用直接操作底层的数据文件，数据隔离层数越少那么访问效率越高，因此单机处理可以达到很高的性能。

图1-8 应用数据库一体化模式

2）应用集群、数据库集中模式

基于模式一资源受限的背景下，诞生出了应用集群、数据库集中的新模式。简单的说，就是应用与数据库分离成不同机器部署，数据库仍用一台高性能的机器，应用程序作为一个整体在其他机器部署运行。

由于应用程序不带有任何状态，因此可以一模一样的复制多台机器，尽管应用程序有可能会并发量很大，但可以堆小的机器来实现负载均衡。因为对于一笔交易来说，不管路由到哪台机器上执行应用程序，最后都会落到数据库上，最终交易的执行效果都一样。

此模式下，由于将数据库与应用分离，降低了数据库机器资源的争抢，从而提升了单机处理数据库的能力；而应用集群部署，提升了应用的横向扩展接入能力，解决了应用的单点故障，因为一台应用程序的机器出现故障，会路由到其他应用程序上继续执行交易，所以对整体系统来说没什么影响。

但由于应用程序跟数据库拆分之后，会使得应用每一次访问数据库都会变成一次跨机器的网络访问，那么单个交易访问数据库次数越多，耗时延长状况就会越严重。

对一笔普通的账务交易而言，确实存在操作几十上百次数据库，所以汇总起来的消耗相当大，在业内通用的处理方式是：尽可能在银行内建设万兆网络，用高速的网络减少网络的消耗，其次是尽可能地想办法减少应用程序访问数据的次数，比如在应用程序端引入缓存，那对于相同的数据就无需多次访问数据库获取数据了。

图1-9 应用集群、数据库集中模式

接下来我们继续看下一个模式：应用集群、分布式数据库的模式，这时出现了分布式数据库。

3）应用集群、分布式数据库模式

前两种模式的数据库都是单机的，那么资源会存在上限，为了解决数据库资源上限的问题，就需要将数据库拆成多个机器来处理，那就出现了分布式数据库。

接下来继续看第三模式：应用集群、分布式数据库，即数据库与应用分离成不同机器部署。就是说采用分布式数据库，应用程序搭建集群在其他机器部署运行。

图1-10 应用集群、分布式数据库模式

如上图，分布式数据库可以对数据库划分若干分片、内部是由多台机器组成的，但对应用程序而言（即对外展示）是一个整体，表现和单个数据库一样。因此分布式数据库作为一个数据库软件来说，自身保证了内部的事务的一致性和可见性，且作为一个整体，也做到了数据库内部的整体备份和恢复。

在此模式下，使用分布式数据库解决了模式2的数据库横向扩展和单点故障问题，对应用程序来说，与模式2相同，改动也是相对来说比较小的一种模式。

截至目前，国内银行核心系统当中采用分布式数据库，已经有些实际的案例了。早期在项目实施过程中比较担心的就是分布式数据库概念太新，能否运用在实际工作中，或是到底好用不好用等。

银行核心系统使用国产数据库案例，如下：

图1-11 银行核心系统使用国产数据库案例

作为分布式数据库的方案来说，也有一个成熟的过程，在使用的越来越多、解决问题也会越来越多的情况下，会逐渐逐渐的变得更加成熟起来。因此该模式从理论上来看，确实是一个可选方案，也是一个相对来说比较好的方案。

4）单元化模式

在上一模式中介绍的分布式数据库模式，是由分布式数据库内部做切片，而单元化模式的数据库与应用分离成不同机器部署，是从系统规划上入手，采用普通数据库按照hash或者range切片的方式将数据库切分成表结构完全相同的若干份，每一份都是一个普通的数据库，那应用程序要和数据库分片做相应的绑定。

也就是说，每一份都有应用集群与之对应，可以理解为都是一个完整的核心系统，只是数据库分散的是一部分数据。

图1-12 单元化模式

如果一笔交易当中要处理多个分片的数据怎么办？

那这时就要采用跨机器的网络外调方式，在应用程序之间进行相应的交易或程序的调度，同时对应用系统提出了更高的要求，需要应用层要实现分布式事务的管理，达到一致性的要求。

原先是一个数据库连接里面所有的操作都是由数据库保证它的一致性，但在单元化的模式下数据库无法实现一致性的要求，因为有很多个跨应用程序的调用，所以只能应用层实现。

另外，在该模式下无法做到像原先单机数据库一样指定时间点对所有的数据（含已完成或已提交的交易）做完整的备份或恢复，因为单元化模式下每个切片都是一个相互独立的数据库，所以做不到整个核心系统数据同一时点的一致性备份和恢复。

下面就进入微服务部分，微服务的概念是互联网公司提出并发展起来的。互联网和银行早期一样，初期规模较小时，业务单一就一个系统，随着逐渐发展，业务越来越多，因此系统就发展成类似银行综合业务系统一样大而全的系统，也同样遇到了银行数据大集中时期相同的问题。但互联网有一个特点，就是IT系统都是自主开发，没有外购。

于是，综合业务系统的拆分，就形成了微服务的框架模式，即使用相同的技术栈，去建设一个个独立的子系统，运行于同一套框架体系内。这样更有利于公司内部人员的复用、以及基础平台的复用。

而银行瘦核心，其实做也是做的同样的事情，只不过银行选的路线是从各个厂商外购成熟产品再进行客户化开发，因此也就很难以一套应用框架去要求各家厂商，因此银行形成的是SOA系统互联的体系。

接下来就从核心系统的应用部署的角度看，微服务的结构经历了以下几个模式：

5）应用整体打包模式

首先介绍最早期的核心系统应用整体打包模式，如下图可以看到核心系统的应用程序，虽然分了很多模块，但是最终编译打包成一个可执行程序运行。

启动应用程序时，所有程序就都启动了，当一笔交易当中发生跨模块调用时，都是在可执行程序内发生函数调用去执行的，因此模块之间没有任何边界，可以直接调用。

图1-13 应用整体打包模式

在此模式下，模块边界比较模糊，程序跨模块使用也没有阻碍，特别是维护阶段时间长了，非常容易逐渐形成系统耦合。

6）应用模块打包整体运行模式

为减少应用模块之间的耦合，从而做到模块间边界清晰，因此产生了新的模式，要求各模块分开编译打包，不允许跨模块直接调用，若要跨模块访问必须使用外部函数接口声明的方式明确程序功能的所属模块，也更容易梳理各模块的内部功能与对外需提供的服务，及程序之间的调用关系和定位；

其次是通过模块分别打包编译的强约束，来解决这个耦合性的问题。

图1-14 应用模块打包整体运行模式

在该模式下，模块边界清晰，代码不可能混入其他模块，模块间调用需要使用外部函数接口声明。通常编译时是打成一个个不同的包或一个个不同的库，但最终在一个主框架内加载所有模块运行，模块间调用仍属于进程内部调用，因此调用效率很高，可以让数据库连接、分布式事务等全局部分在各模块共享使用。

7）应用微服务模式

最后一种是业内最近常见的应用微服务模式，可以理解为是将银行核心系统的应用程序按照模块分别编译、打包，打包成这种可执行程序然后每个模块分别部署运行。

需要注意的是，数据库与应用程序一一对应，各模块分别部署时所访问的数据库也会相应地拆分出来。

图1-15 应用微服务模式

如上图，黄框代表一个一个单元或微服务的机器，每个框都是一个整体，比如应用模块1对应着模块1数据库、应用模块2对应着模块2数据库。若一笔交易通常会涉及到多个微服务调用时，那就需要在微服务框架内进行跨模块的远程调用，并由应用实现分布式事务来保证一致性，与单元化类似。同样，也做不到整个核心系统数据同一时点的一致性备份和恢复。以微服务为核心的分布式技术在银行业运用已逐步趋于成熟。在分布式架构转型进程中，银行系统建设以微服务为核心，采用“开源+自研”的开放式架构，不断拓展周边生态。

值得注意的是，微服务的分布式事务一致性，目前在业内通常使用的有SAGA回冲模式和TCC回冲模式。

SAGA回冲模式是指挨个模块逐一调用，若调用有问题或失败则调用冲正，比如先调第一个、再调第二个、再调第三个...如果第3个出现问题或调用失败时，则反向回冲，即调用第二个冲正、再调第一个冲正等。TCC回冲模式是指不是将整个交易做完，而是先做预处理，先做模块1的预处理、再做模块2的预处理、再做模块3的预处理...如果全部都成功后，再依次做模块三的确认、模块二的确认、模块一的确认，如果当中出现问题或失败，则做模块三的取消、模块二的取消、模块一的取消等。

SAGA和TCC两种回冲模式均为最终一致性，即整个业务处理完成后才能保证整个是一致的。对数据库事务而言，每一步的事务都会先做提交，等到后面出现异常再做回冲或取消，那多个并发时，可能出现读取到其他并发才处理了一半，最终不一定成功的数据。

比如说执行流程有步骤1、步骤2和步骤3，当系统执行到步骤2，此时步骤1已提交。但是其他并发读数据时会发现，读到的是步骤1处理过的数据，但实际上，前面的步骤1最终的结果不一定是成功的，因为还有后续步骤未执行完，如果后续步骤失败之后则被回冲掉。所以并发读到的是一个不准确的数据。该场景在早前的单机数据库中叫读未提交，就是还未提交最终提交的数据会被读到，在银行核心系统中是不允许出现的，因为会造成业务逻辑判断的失误。

因此使用此种模式要小心，需编排交易流程步骤，在交易层调度各微服务，并精心组织调用顺序，以保障银行业务安全的顺序执行。

比如先做对银行安全的步骤再做对银行不安全的步骤，要尽可能让别人读到的是对银行安全的数据，就好比原先支付系统跟核心系统的交互，通过先核心记账再付款的方式。

另外，要特别避免带事务的深层次嵌套微服务调用。