网站建设培训东莞,dedecms中英文网站开发,市场调研模板,手机模拟器概述#xff1a; 从 20 世纪 80 年代开始至今#xff0c;我国银行业信息化历程已 有四十年历史。虽然相对于发达国家来讲#xff0c;我国银行业务信 息化起步较晚#xff0c;但发展速度很快#xff0c; 目前我国一些大型商业银行的信息化程度已经处于全球领先水平。 “银行…概述 从 20 世纪 80 年代开始至今我国银行业信息化历程已 有四十年历史。虽然相对于发达国家来讲我国银行业务信 息化起步较晚但发展速度很快 目前我国一些大型商业银行的信息化程度已经处于全球领先水平。 “银行信息系统”是指银行为实现银行业务处理自动 化、银行服务电子化、银行管理信息化和银行决策科学化 通过采用计算机技术、通信技术、网络技术等现代化技术手 段改造银行业传统的作业方式建立起集业务处理、信息 管理和经营决策为一体的银行 IT 系统。银行业 IT 的发展是 整个信息技术领域发展的一个缩影纵观四十年发展史我国银行信息系统发展的技术架构大致经历了三次变迁图1。 图 1我国银行信息系统架构演进 一分散式架构 20 世纪 80 年代国有四大银行由于银行内和银行间资 金流动的日益频繁手工联行效率低和差错多的问题也日渐 突出。而电子计算机设备在西方国家的出现和应用打破了 银行当时面临的效率瓶颈。为改变当时手工业务处理模式 各大银行相继引进了日本 M-150、美国 IBM 公司 436l、4381 型主机系统建立各类柜面业务处理系统实现业务处理电 子化并在此基础上各行分别建立了自己的联网系统实现 同城各专业银行自身间的活期储蓄通存通兑并基本实现各专业行、营业网点之间业务的联网处理。 这个时期的银行信息系统按照业务功能模块划分各系 统的接入渠道、核心账务处理、数据存储等方面都相互独立 且归属于银行不同的业务主管部门管辖。在部署方式上银 行内各省行分散部署系统并通过网络实现各系统间相互连 接和数据交换。 以工商银行为例在 1995 年已建成了以省 级分行为主的 30 余个计算机中心形成了覆盖和连通全国 所有一级分行、二级分行的计算机网络电子化网点覆盖率达到 75%柜面 80%的业务量通过计算机处理。 二集中式架构 20 世纪 90 年代后期国外现代化商业银行开始走数据 集中的道路数据中心合并或再整合成为各大金融机构电子体系建设的基本模式。而我国银行业经过“七五”和“八五”时期的电子化建设各大行的大机中心建设已经初具规模具备了采用大型机集中管理和应用的条件。 面对国有银行改革大背景和银行内部经营压力1999 年 9 月工商银行提出了以 “ 9991”命名的大集中工程用了 3 年时间将全国各地 36 个计算中心合并建立了两大数据中 心即北京上海两大互相备份的数据中心是我国数据大集 中的里程碑工程。之后全国各大小金融机构纷纷仿效建 设银行与交通银行于 2005 年 9 月完成了数据大集中农业 银行于 2006 年底完成了数据集中中国银行则于 2011 年 11 月完成了大中心的建设工程其他全国性股份制商业银行 例如光大、 民生、兴业、华夏等银行也纷纷走上了 “数据大集中” 的道路。通过数据大集中我国银行信息系统完成了从 “各省行 分散部署”到 “全国性数据中心” 的演进基本形成了大型 机部署核心银行系统的 “集中式”架构体系实现了我国银行业的数据集中化、运营集约化、管理现代化和服务电子化。 三分布式集中式的双核架构 从 2011 年至今新一轮信息技术革命席卷全球尤其 是移动互联网、大数据、人工智能、分布式和云计算等技术的逐步成熟银行业务在渠道、产品、营销、运营和风控等方面都开始发生深刻的变革产品迭代的速度越来越快。随 着银行内应用规模的不断扩大基于大机技术构建的集中式 架构已无法满足弹性扩展、灵活创新的需要最直观地体现在无法适应业务的快速调整和市场的快速变化。从技术成熟度与发展趋势看要解决面临的这些问题运用分布式、微服务和云计算技术是业内主流方法,因此各 银行积极开展基于开放平台的分布式转型的探索通过搭建 高效弹性、开放灵活、安全可靠的分布式基础架构、以及“多 中心多活” 的部署架构推进银行信息系统技术架构由单一 集中模式向双核异构混合模式转型增强业务支撑能力满 足敏捷研发和应用扩展的需要以适应业务的快速调整和市 场的快速变化。例如工商银行 2018 年率先建成了基于云计 算的企业级分布式技术体系形成 “主机分布式开放平台” 的双核 IT 架构在原主机核心系统的基础上初步构建起 包括核心业务基础支撑、账户体系、重点产品服务在内的较 为完整的开放平台核心银行系统实现大型商业银行 IT 架构的历史性突破。 在上述我国银行信息系统整体发展历程下各家银行由 于系统建设起点、业务规模、技术能力等方面存在差异导 致在具体路径选择上又各有差异。早期国有商业银行和大型 股份制银行基本都经历了完整的三个阶段而一些成立时间较晚的中小银行如上海银行往往直接从第二阶段起步建立起以主机为核心的集中式系统。一些具备互联网技术背 景的银行 比如网商银行、微众银行、百信银行等在建设之初就直接基于分布式架构建设相关系统。 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年符合中国国情的SAFEIIIBM定制化的第一版在工行网点大量上线于此同时中行的SAFEII上线几乎与工行同步而建行的SAFE应用在随后两年也上线在当时多数银行业务还依靠‘流水账式’手工操作的业务模式下中国银行业几乎没见过真正的银行核心应用是什么透过SAFEII银行才有了对系统的认识也开启了信息科技的发展之路各家银行都借助IT之力开始规模扩张。
由于IBM当初给银行客户提供一个完整的商业应用SAFEII并且对SAFE源代码开放并帮助客户改造应用铸就了其后三十年主机在中国银行业的“霸主”地位时至今日四大行的核心系统还都跑在其上。谈及主机银行是又爱又恨。爱的是只要你肯花钱IBM就手把手全教你24小时全方位服务。恨的是这么多年了。你教我的武功只能在你这个台子上练上台费太贵了一年十几亿的花销。于是便有了后来的主机降级为小机小机转X86 PC Server以及近几年的去IOE风向。“国产替代”改名“安可”项目是中国各个央企的一把手项目
政治经济中国一直都是这一条主线。香港作为世界窗口的桥头堡选用国际主流产品中国内陆在摸着石头过河有ODA援助同时鸡蛋不能放在一个篮子。那时候的中国和世界发达国家的差距是让人崩溃的。市场换技术也是当时我们中国的无奈之举。
在引入计算机之后即20世纪80年代前期出现了PC单机时代也称为“会计电算化”就是把一部分柜员手工记录的内容特别是会计账簿和记账传票使用计算机来实现数据的登记和保存。从而减轻人工登记和处理的负担加快业务办理速度提高工作效率。
通常每个储蓄所或营业所会配一个PC单机柜台人员会将手工登记的信息录入到计算机系统中保存从而实现银行每个营业网点单独一套“电子的账本”形成了非纸质记账的方式。
由于还没有互联网每个网点安装的计算机设备都没联网拥有各自独立的系统各个网点分别处理自己的账务信息所以没有通存通兑功能。基本上都是以网点为单位在哪里办理的开户就只能在哪里办理业务。跨储蓄所的交互还是和手工时代一样走纸质票据或纸质凭证的传递总的来说是解放了一部分的手工操作解除了原先很多在纸质上面的记录。 图1-2 银行储蓄宣传柜员桌上配置了电脑
当日本人援助中国计算机系统的时候美国人自然不能闲着。怎么能让日本人的系统和软件占领中国的核心金融应用呢另外参考这篇文章《以史为鉴美日贸易战往事》那个时候正是美国要敲打火箭速度上升的日本的时候。美国人要影响中国的核心金融应用必须走美国的技术体系。
1987-1988年符合中国国情的SAFEIIIBM定制化的第一版在工行网点大量上线于此同时中行的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元北京的工商银行支行先要把数据提交给人民银行北京分行等待一天只有23次的同城交换注意当时卫星覆盖有限不是实时的哦如果正好错过了当天的同城交换只能等到第二天这就耽误了一天。同理人民银行上海分行把数据传递给上海工行分行又要耽搁一会儿这就是所谓的3天了。
本质上这张网还是区域自治、逐层上报的网缺点明显。人民银行的领导们很快发现这个问题需要建立一张全国的大网。来来来各路财神都接入我我坐庄一个人做统一的支付和清算。就这样CNAPS中国现代化支付系统横空出世。
为迎接加入世贸组织的挑战与机遇提升数据和技术力量的分散、业务处理缺乏标准规范、软硬件资源不共享、管理水平不平衡等问题导致的负面影响加上计算机的硬件设备能力在不断提高、网络质量越来越好、网速越来越快等原因数据大集中应运而生。
简单的说就是原先区域性的数据集中但对客户来说同一家银行是一个整体任意网点都应享受同样的金融服务对银行来说将客户在各网点的信息汇总起来用于风险评估或评级不仅能节省银行的管理成本而且有利于对客户有更全面的了解后提供更好的金融服务。
数据大集中是各银行根据自身情况对数据和业务进行不同程度的集中处理。例如将分散的省级数据中心的数据和业务集中到国家级的数据中心实现系统基础架构、物理服务器、数据和应用建设的集中。
数据大集中使总行能够集中全部研发力量从而避免低水平的重复开发节约系统管理、软件维护及升级的费用使总行能够得到准确、实时的数据全面地了解到各分行的工作进展情况以免增加不必要的后继沟通成本使总行能够通过分析交易数据与交易行为提升整体服务水平减少因信息不对称而导致的银行风险管理失控或业务机遇丧失。
因此国内商业银行开始重视规模化经营掀起了一场以数据大集中为主线的技术革命和业务变革。同时也造成核心系统的数据量呈指数级增长原先是一个地区或单网点的数据经全国大集中之后数据量翻了10倍甚至100倍并在一个系统中承担而且系统可能要使用十年左右时间对当时的系统设计来说是一个极大的挑战。
故各家银行引入IOEIBM、 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最终的结果不一定是成功的因为还有后续步骤未执行完如果后续步骤失败之后则被回冲掉。所以并发读到的是一个不准确的数据。该场景在早前的单机数据库中叫读未提交就是还未提交最终提交的数据会被读到在银行核心系统中是不允许出现的因为会造成业务逻辑判断的失误。
因此使用此种模式要小心需编排交易流程步骤在交易层调度各微服务并精心组织调用顺序以保障银行业务安全的顺序执行。
比如先做对银行安全的步骤再做对银行不安全的步骤要尽可能让别人读到的是对银行安全的数据就好比原先支付系统跟核心系统的交互通过先核心记账再付款的方式。
另外要特别避免带事务的深层次嵌套微服务调用。
