在这里，特别要感谢张广老师，对我国银行核心系统的发展历程部分进行了完善和补充，特别是关于目前业内流行的分布式微服务组建模式，学到很多。希望后续有更多的小伙伴来分享自己的见解或想法，一起思维碰撞，探索更多可能……

此文分为以下五部分：

银行核心系统（Core Banking System）是以处理银行最基本的存款、贷款业务为主的IT系统，作为支撑业务营运的关键系统和银行信息化的重要组成部分，被称作银行IT系统的“心脏”。我们去银行网点或线上办理的存贷款业务都是在银行核心系统中完成的，除此可能还包含客户、会计、公共等功能。

银行核心系统在整个银行IT系统架构中是其他业务子系统的基础，也与其他系统保持着密切的关系，作为重要的业务处理系统，在整个银行IT系统中处于承上启下的关键位置。

核心系统在金融服务能力、处理性能等方面，对银行日常经营的业务与流程优化、提升客户体验度、推动业务改革或创新等方面起着决定性作用。

银行IT系统功能边界的定义，对于系统的分析与设计非常重要。需要结合银行自身发展情况与发展战略进行整体规划，当有了明确的边界就清楚了系统分析和设计的范围，就有了工作的目标和任务。

因此，边界的定义是明确责任和控制成本的基础，有助于精细管理，能避免浪费无效的工作时间和精力。试想要是工作没有边界，是一件多么可怕的事情，可能会违背自己的本意做一些职责范围之外的事，甚至出现扯皮推诿的情况。

在银行新核心系统设计时也一样。

因为银行核心系统会与几十个、甚至成百上千个其他关联系统有进行交互，所以分析边界要先梳理核心系统包含哪些内容，不包含哪些内容，然后再结合银行IT系统的整体规划，尽量做到只处理最基本的核心业务，即单纯的交易处理系统。从而保证核心系统的稳定与高效，这不仅增强了系统的灵活性和扩展性，而且还能适应外围系统的快速扩展。

在科技飞速发展下，银行核心系统在不同时期面对的挑战与机遇各不相同，在调整核心系统的定位并设计最优解的同时，经历着一代又一代的发展与变革。

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

储蓄所职员完全是依靠手工操作办理业务，无论是客户业务办理，还是计息结账、内部往来对账、编制报表等都靠人工处理。

比如营业时间的存取款，从收钱、点钞、登折再到另一个人的复核、签字、盖章、记账，最快也要二三十分钟；再如每天营业结束后的“扎账”，若总账和明细账没有扎平，就必须连夜加班查账找出原因，直至账目齐平。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

因此，国内商业银行开始重视规模化经营，掀起了一场以数据大集中为主线的技术革命和业务变革。同时也造成核心系统的数据量呈指数级增长，原先是一个地区或单网点的数据，经全国大集中之后数据量翻了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小时在当时的系统设计中是一个热点。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

图1-6 复杂的关联关系

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

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

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

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

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

图1-7 网商银行；微众银行

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

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

其次，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最终的结果不一定是成功的，因为还有后续步骤未执行完，如果后续步骤失败之后则被回冲掉。所以并发读到的是一个不准确的数据。该场景在早前的单机数据库中叫读未提交，就是还未提交最终提交的数据会被读到，在银行核心系统中是不允许出现的，因为会造成业务逻辑判断的失误。

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

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

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

银行的金融交易涉及到客户资金运转，在国民经济发展中处于特殊重要地位。所以银行的业务特性决定了银行对交易和数据的及时性与一致性要求非常高，必须准确、不可丢失，安全性、可用性、可追溯，更是互联网金融企业无法比拟的。

例如，对于外汇业务，利率的实施变化决定了相关业务要实时相应，如果时效性、准确性达不到要求，就会给客户或银行带来损失。再如，在证券行情实时变化时，银证转账如果不能满足要求，可能会给客户带来巨额损失；一些大额的转账或汇兑如无法满足时效性及一致性，可能给客户的资金使用带来风险。当然，互联网企业的优势（如海量服务能力、注重客户体验、大数据服务能力等）也是传统商业银行转型必须具备的。

及时性是指要及时响应客户的交易行为，避免可能带来的损失。因为银行系统的处理能力与银行规模和科技投入有关，所以主要从银行核心系统的几个关键指标来了解自身发展情况和目标，如响应时长、每秒事务处理数、每秒请求数等。

在分布式银行核心系统中，一致性是指数据在多个副本之间能否保持一致的特性。在一致性的需求下，当一个系统在数据一致性的状态下执行更新操作后，应保证系统的数据仍然处于一致。提到一致性就离不开分布式事务、缓存等，就不逐一展开了。

安全性是指通过信息安全建设和管理，有效控制和防范信息安全风险，确保企业与客户的信息及资金安全。主要包括机房、网络、数据、系统、制度等安全方面进行保障。

高可用是指系统提供的服务必须一直处于可用的状态，所有处理环节避免单点故障，当故障发生时可以快速恢复，如果在故障发生时具备故障隔离或备灾备容错能力，如多活并行处理、两地三中心等，RPO（Recovery Point Objective，恢复点目标）、RTO（Recovery Time Objective，恢复时间目标）等指标无限趋近于零。

如下表：

图1-17 不同灾难恢复能力等级下的RPO和RTO

图1-18 可用性及衡量标准

可用水平（%），通常都包含了信息系统计划停机的时间，即为了系统维护、新版本投产等原因，人为主动的让系统停止对外提供服务。因此，要提高可用水平，需要减少系统的计划停机时间。

可追溯是指金融交易的所有业务操作都要保留日志数据，做到信息流的可查、可追溯、可审计，也是监管的要求。

在银行IT系统中，银行核心系统建设是整体支出占比最大、最为复杂，对于技术要求最高的工程，需要持续投入非常多的资金与人力资源，而且还涉及到全行各关联系统的配合或同步改造，项目建设周期往往少则一年，多则两三年。

采取什么样的模式来建设新核心系统，如何在本行能够承受的前提下投入财力和人力，使系统建设既能对标同业又要符合实际发展情况，并能够满足未来银行业务快速发展的需要，一直是一个困扰许多银行决策层的难点问题。

银行新核心系统的建设模式大致可分为五种，分别是外购或外包产品、完全自主研发、主导研发、项目研发外包和应用系统托管。对于采取哪种研发模式，需要综合考虑诸多因素择优选择，切不能一概而论。在规划中要提前明确和定位建设模式、合作伙伴以及维护方式等。

通常是银行自身IT有强大的技术能力的大行，研发团队越成熟，越应该走自主研发的道路。反之，中小型银行的自身IT规划能力及建设能力不太强，并要支持下一步的业务创新及快速实现业务需求有一定难度，采取外购外包模式，与合作伙伴共同实施核心系统建设是一个更好的选择。不仅银行可以用更低的成本获得更好的技术和服务，并可以使自身在人员缺乏的情况下，将更多精力集中在需求分析设计、项目规划与服务监控上，从而更好地推进核心项目的建设。

另外，银行核心系统产品从纵向解剖，自底而上通常可以分解为基础设施、技术平台、应用模块三大部分，越是基础的越能通用，越靠近应用越要定制，否则做出来效果不好，并且结合外包、自主研发多维度统筹考虑。

对于科技力量薄弱、自身研发能力不足，业务规模在一两年内甚至几年内预估不会爆发增长的小银行，采取外购或外包产品的模式更加合适。它们没有多少IT人员，忙于日常如协助各个部门查数据、打印报表或结单、分析生产问题，或承接以运维类、报表类等低价值开发工作为主，没有多少剩余时间进行研发与创新、甚至是学习或吃透其服务商产品的做法或优点。

除了外购产品更成熟或先进之外，银行核心系统上线或更换速度更快，比如偏互联网银行基本保持在半年内，主要还是相关项目由于是新做，没有负担，所以周期短。

还见过银行直接外购整个银行IT系统，拆除科技部，直接将信息科技的运维都外包给相关的机构，也是一种更经济的可选择的方式，或者一种过渡的方式。

当然，有利必有弊，该模式需认真分析以下三点：

1）是否适合国情、行情

银行核心系统是一家银行的引擎、发动机，也是一家银行科技实力的重要体现，同时也服务于银行的战略、业务和组织架构、以及监管政策和法律法规。而不同国家、不同银行有非常不同的目标、形式和历史原因。例如，国内外的核心系统差异巨大，直接拿来使用可能会水土不服。

2）差异化开发及维护成本

外购的产品通常要适合本行特色业务，从而进行差异化开发或修改，差异化需求越大越多，修改和测试的工作量就越大，可能会影响上线期限。当系统上线进入了维护阶段，服务商会有半年到一年的免费维保期，但对新增需求的分析、设计、开发等方面要单独算费用，因为过渡依赖存在不确定风险，故议价能力很弱。基本上是，维护成本占了系统建设整个生命周期所需费用的大头。

3）系统间整合

指的是系统之间没有统一的数据标准，使得银行的数据信息零乱分布，既有冗余又有缺失，或数据更新不同步，数据一致性无保障。比如有些银行将核心系统进行拆分，单独外购贷款系统或分散外购，不同的厂商框架或标准不一样，若没有统一标准或长远规划，不可能提供高质量的信息服务。

该模式适用的银行范围有：部分中小城商/农商、民营银行、外资银行，而且部分银行会要求产品能简单部署在云平台上，在自主可控方面陆续要求集成国产数据库。当然，有相当研发能力的金融机构也不是绝对不能外购。

项目研发外包模式使用较多，是指“外购产品+改造实施”的方式建设新核心，也可称为项目外包，即在服务商的业务与技术人员入场前，确定好外包范围和外包金额，银行方不再太关注外包公司实际投入资源，而是重点关注项目质量和进度。

在项目实施过程中，银行会根据里程碑计划的执行情况和行内自主掌控要求，选派不同程度的人员参与需求分析和设计及评审或部分开发工作，具体的研发还是以服务商为主。

服务商目标和责任明确，银行方投入精力小，有利于银行拥有自主知识产权或者是共有知识产权。缺点是立项采购拉长了项目实施周期、银行自有研发规范较难落实、项目质量受制于服务商实施团队的能力，多家外包伙伴时沟通成本较大。

随着银行规模增大，可能还会衍生出多家服务商合作外包的方式做项目，降低对单个服务商的依赖，将可能造成的损失降到最低。

在项目前期，通常还会增加咨询公司对本行的业务进行梳理和优化。银行对自身业务把握清晰，但对未来发展和业界的领先实践无法与咨询公司相提并论，只有通过专业的理念和服务将业务分析透彻，才能很好指导后期的系统设计与开发工作。

其次，核心系统项目建设牵涉到银行很多部门和组织，难免会有利益冲突与工作的协调配合，借助第三方专业的视角和可观的角度能更高效的协调和解决问题。

该模式适用的银行范围有：部分中大小城商/农商，其主要诉求是替代掉原有的老旧核心系统，建立起产品的业务模型和架构建设，在自主可控方面部分银行会要求集成国产数据库。

对于大型金融机构来说，银行IT在逐步去外包化，尽管还存在外购系统的情况，但更多的是希望能掌控系统从而解决外购系统的重重束缚，或是完全自主研发代替外购或外包产品。为积极响应国家对金融核心领域技术自主可控的要求，银行IT走自主研发的道路是必经之路。

不仅能完全使用本行的战略、业务和组织架构，而且国内金融IT厂商技术力量相对薄弱，很多高水平毕业生不做外包，当行里研发队伍的规模和素质达到一定程度，系统上线周期会快于外购系统。

算上研发人力费用、固定资产折旧、办公费用、系统维护成本等，从整个产品生命周期看，自主研发总成本通常要低于外购产品。

该模式适用的银行范围有：国有大行、股份制、大农信、部分中大城商/农商行，大多数原有核心采用AS400或大机的银行希望采用重构的方式完成核心下移，部分银行会要求基于云平台进行核心系统重构，在重构的规划或过程中强调自主控。

除了大型商业银行，其他银行规模相对比较大，研发团队有较强的研发能力，但不具备完全的自主研发能力。那么，可以采取介于完全外购外包与自主研发之间的近自主研发的系统建设模式。

主导研发包括自主定义系统的架构、数据标准、接口标准、数据交换规范，以及系统设计、数据库设计、流程设计等，项目与技术经理要由银行研发人员担当，便于日后能主导所有系统维护工作。

银行进行外包采购的是“人力外包（俗称买人头）”。人力外包是以人力劳动时间为主要目标的外包方式。一般以开发工时为结算依据，银行负责选人、分派任务、结果验收。

其优点是项目可快速进入实施阶段、使用人工灵活，有利于自主掌控，研发规范管理更好，知识传承和连续性保障较好。缺点是银行的管理难度高，外包人员流动性较大、缺乏对团队的归属感和认同感。此外，如何客观评价外包人员的劳动效率也是一个难题。

在人力外包的情况下，衍生出了新的形式用于严格规范对人力外包的管理，防止外包人力工作量不饱和。

比如以任务单的形式实施小微型项目外包，便于对人力外包的事前控制，要求从外包资源池中申请外包人力时，必须提出具体的工作内容和预估工作时长，并形成研发任务单。同时，管理难度有增加，需要明确评估每一个任务的工作量。

上述提到的四种核心系统建设模式，基本都是一个银行拥有一个自己的系统。还有一种模式是“应用系统托管”，可以理解为多法人机构共享的核心系统。

对于中小型金融机构或新成立的银行，要新建一个仅供自己银行使用的核心系统并进行日常的运维不容易，所谓麻雀虽小，五脏俱全，总体投入成本较大。

因此，2009年左右出现了银行间共享合作平台，各参与行共同建设，从调研论证、项目立项、需求分析、开发、测试到上线后的运维，成员行公共参与并实践，因此减少了研发过程中的重复开发，节省掉研发费用后均摊成本，将用户利益做到最大化，最终为金融机构提供各种所谓金融服务。

随着涉及金融云服务的快速发展，云服务企业已成熟，如山东城商行联盟、兴业银银平台、神码金融云等，其应用系统托管的模式帮助中小城商行、民营银行解决了发展过程中各种各样的难题。

关于我国银行核心系统定义、边界与位置，我国银行核心系统整个发展历程、更换核心系统的原因和原则，以及新核心的建设五大模式就介绍完了。

相信对于初学者来说，已经逐渐建立起了对银行核心系统领域的整体认知、搭建起了属于自己的第一层级知识树。对行业同仁来说，对目前银行核心系统发展到分布式微服务的模式有了更深的理解，当然很多实现的模式所带来的问题与机会需要继续思考，也包括业内各大服务商正研发的云原生核心系统等，都还需要在实践与使用的过程中不断研究与探索，从而更好地权衡利弊、更进一步地追寻方案最优解。