银行柜面系统架构优化
本篇文章给大家谈谈《银行柜面系统架构优化》对应的知识点，希望对各位有所帮助。
本文目录一览：
银行系统的体系结构是什么
一般都是总行-分行（省分行、省辖分行）-支行结构。总行和分行下还有机关部室，公司部，个金部，会计部等等，各银行具体设置不一。
核心银行系统 之二 企业架构与核心建设
企业架构与核心建设
在读这章之前需要补充一些银行管理的知识，推荐可以参考《商业银行管理》。
从第一章核心系统的发展历史可以看出，银行的核心系统都是经历几代的“换心之旅”才成为现在的模样。
在中国加入WTO后，银行的管理模式和战略都发生了变化，面对业务转型对核心系统提出了更多元化的要求。不但要从面向账户为主的传统记账型核心变成面向客户为中心的账户管理模式，还要应对银行作为企业进行经营管理的内部需要，承担最重要的核算功能。
核心银行系统是银行对外提供金融服务的平台,也是银行内部账务处理的中心。在银行的整体业务系统架构中,核心银行系统处在中央枢纽的关键位置。核心银行系统的重要性决定了其生命周期通常在5-10年以上,也就是说, 核心银行系统的选择会影响银行未来5-10年的业务发展。因此,在银行准备更换核心银行系统之前,必须从银行长远战略的角度,对更换核心系统所需达到的目标、核心系统更换与银行整体业务战略和IT规划之间的关系等方面进行认真和细致的研究。
企业架构 (EA) 是一个用于管理和融合企业IT资产、员工以及业务活动的综合的框架，具有可操作性。EA是用来确定信息和信息技术如何支持业务活动并为企业带来业务效益的管理工具，它不仅是IT与业务融合的理论基础，而且更是一种有效且实用的方法。
1.企业业务架构 (EBA)
企业业务架构是企亚关键业务战略以及他们对业务功能和流程的影响的表达。通常包含业务功能、流程和信息价值链的当前和将来的状态模型，通过信息架构、技术架构以及应用投资组合来进行实施，可定义为支撑竟争优势的业务设计。
2.企业信息架构 (EIA):
企业信息架构是一个由EBA驱动的模型集来描述企业信息价值链，主要包括建立关键信息流模型，描述业务事件的关键输出信息，扩展组织边界到外部信息来源和流向，使企业能快速进行业务决策和信息共享。
3.企业范围内的技术架构(EWTA):
企业范围内的技术架构是一个逻辑一致的技术原理集合; 指导组织信息系统和技术基础结构的工程化。EWTA是对整个IT战略的表达。
4.软件架构：
在IT 行业架构的一个更早更普遍的概念应用是“软件或应用程序的架构”。软件架构起源于软件工程，是关于软件系统的有机组织的决策集合、结构化元索的选择以及元素之间的接口，通过这些接口以及元元素的协作构成软件系统。
业务架构描述了各业务之间相互作用的关系结构，业务架构以业务战略为指针，以各主营业务为主线，以各辅助业务为支撑，以人流、物流、资金流、信息流等联络各业务线，构成贯彻业务战略的基本业务运作模式。银行业务价值链上的核心产品包括储蓄、信贷、支付、结算、国际业务、中间业务等，资金运作、营销和服务也是国内银行机构的基本业务职能。在管理层面，包含人力资源、财务、风险、科技管理等。股东、银监会、人民银行则对金融机构进行决策、监管和指导。
业务价值链
按照企业架构的分析方法，将银行的业务价值链抽象为: 市场规划 、产品研发、营销、销售、产品运行、服务、财务核算、风险管控、决策支持、内部管理等。
银行的企业架构按照纵向划分成了五大领域 而IT架构则按照EA 方法论，横向划分成了四大架构。业务架构和IT架构的关系，呈现一个纵横交错的矩阵式结构。
二者之间的关系表现为: 第一 ，业务架构和IT架构是互动的、紧密耦合的、相互促进的，业务和技术部门在新一代核心银行系统建设中必须密切配合。第二，业务架构沿五大领域纵向展开，分别确保各领域的业务规划和需求整合，IT四大架构横向贯穿于业务架构的五大领域，发挥核心银行系统建设的整合与统筹作用。
企业架构是研发领域规划中的重要工作，是能够精确联接企业战略和具体项目技术方案的核心纽带。它阐述了企业级的业务架构 并以此为依据，建设企业级的应用架构，确保企业级的应用架构能够充分而又必要地支撑业务架构。所以应用架构必须依托于业务架构来建设，反之应用架构的规划实施也将有利于促进业务架构的优化和完善。
按照企业架构的理论框架，把银行业务架构按照业务布局、结构 流程、运营和管理组织维度分为不同的应用领域来分别开展工作 这五大业务应用领域具体如下：
(1) 产品与服务领域:
完善基础产品服务平台，落实服务业务战略规划，积极拓展新兴业务、金融市场业务以及各类具有高附加值的业务领域 ，形成更加丰富灵活的产品服务体系。
(2)营销支持领域:
通过建设企业级客户信息系统，提升客户识别与评价能力，增强对客户经理的营销支持，完善客户与客户经理的考核评价体系。在此基础上，实施网点转型，不断加大电子银行服务渠道创新步伐：实现客户在不同渠道上的一致性体现，形成以客户为中心的营销体系。
(3) 风险管控领域:
对信贷管理、内部评级等进行全面优化升级，提升银行信用风险 、操作风险、市场风险的识别和管理能力 ，有效提高风治理和防范水平，形成建全的风险管控体系 。
(4) 业务运营领域:
构建后台业务集中处理支持平台，对财务会计、运营支持等系统进行重新建设和优化，使具有资源集中性特点的业务由银行后台集中运作，提升银行的运营效率和成本控制能力，形成有效的营运体系。
(5 ) 信息披露及决策分析领域 :
完善基础数据管理和分析，实现业务经营信息、会计核算信息、内部管理信息、组织机构和人员信息有机融合，构成银行的统一数据视图，并以各种分析模型为指导，为银行对外信息被露建立统一出口，形成一个可信的风险报告和信息披露体系。
银行应用架构建设模型：
银行新一代核心银行系统的应用架构建设以全面逻辑集中为设计目标，引入前中后台的流程银行理念，采用了面向服务的分层设计思想，将应用架构分为“操作环境/渠道层” 、“集成层”、“客户层” 、“产品/交易层”、“核算层”、“管理报告与决策支持层”六个层次。
操作环境/渠道层的作用是为核心银行的业务办理者 (客户、前台的营销与客户服务人员、后台的业务集中办理人员)提供操作界面和交互控制，处理这些用户发起的操作事件，采集他们输入的信息，调用相关的后端服务来处理他们的请求，并向他们展现处理结果。
集成层的作用是做好核心银行系统在接入和处理的良好衔接，是业务接受和业务处理的中间桥梁，要处理好进行业务处理过程中所需的各种后端服务，即各类资源 (客户、产品、合约以及各种企业内部资源等等) 的管理与访问服务，以及基于这些资源提供的交易服务和其他服务。这就需要依托企业数据总线，实现流程调度 完成功能的完美集成。
客户层的作用是整合核心银行系统所需的客户资源，提供统一的客户信息视图和操作型的客户关系管理，在建立起统一的客户视图基础上，完成客户的识别、开发与维护，能够有效地支持以客户类型 (个人 、公司) 为主线组建营销支持与服务体系的业务战略 。
产品层的作用是为整个核心银行系统提供强大的产品支撑功能，确保银行能够快速地构建新产品，能够灵活地应对汇率、利率和定价的变动，以及基于己有产品进行组合，并在此基础上在此基础上拓展各类延伸及新兴业务 。
风险管控层的作用是对核心银行业务处理的全过程进行监督，在此基础上实现健全的风险管理和控制体系，风险管控贯穿我行前中后台所有业务流程，消除风险控制空白，提高风险管理水平。
核算、管理报告与决策支持层的作用是对核心银行业务办理的结果进行数据加工和统计分析，基于新会计准则，建立完善的财务会计、管理会计应用体系，实现多维核算和多维数据积累，并依托数据仓库技术，完成多维数据加工、挖掘和分析，为银行经营战略决策提供科学依据。
以提升信息资产价值为目标，在银行业务战略和IT战略指引下， 对数据的产生、处理、传递、应用等过程进行规划、梳理和完善 ，全面提升数据质量，保障信息安全，为银行经营管理提供全面有效的信息支持，实现信息资源的效益最大化。
银行数据架构建设模型：
(2) 信息资源管控体系规划
主要是解决信息资源管理管什么、如何管、由谁管的问题。针对信息资源的管理的三个主要方面 (数据生命周期管理、数据质量管理、数据安全管理) 以数据生命周期的各个过程(产生、加工、传
输、应用、归档等)为主线，确定各环节的管理内容、工作流程、部门分工、职能责任等。形成比较完善的管理机制，保证数据的完善、安全与高效。
2 、治理层面
主要包括数据质量管理、数据标准建设 、管控体系建设和信息系统建设等四个方面，工作范畴属于对信息资源管理规划的具体实施及完善深化 。
(1) 数据质量管理
数据质量管理就在统一的信息规划和数据标准下，对系统中的数据质量完善程度进行监控和管理，既包括对历史数据的清理与修 正，也包括对当前数据的合规管理。数据质量的衡量标准是数据的完整性、规范性和准确性。例如: 系统的数据设计是否符合规划 、系统中的数据标准是否符合规范、数据维护是否存在违规操作、各类信息数据是否规范准确等。数据质量管理是一项全行性的长期工作，涉及几乎所有业务部门的参与，因此，需要有合理的部门分工、职责划分，并且有严格的检查、评价及考核机制予以保障。
(2) 数据标准建设
数据标准简而言之就是对各类数据概念的标准化定义 ，主要描述业务数据概念中包含哪些信息，以及这些信息的特性，分为业务数据标准 (如: 基础数据业务标准、复合数据业务标准、数据实例业务标准) 和技术数据标准。数据标准建设，就是在数据标准体系框架下，对业务处理流程中所涉及的各个数据概念进行标准化的定义，并确定与之对应的结构。数据标准建设的成效，一方面取决于数据标准制定的合理性，另一方面取决于统一实施的程度。由于制定数据标准的专业性很强，而推广应用存在较强的主观性， 通常经验是成立专门的标准委员会，对数据标准的制定进行评审，并建立配套的把关机制，保证在新系统开发和老系统改造时，对统一数据标准的实施应用。
(3) 管控体系建设
主要是落实信息资源管控体系的规划，进行相应的组织机构建设，按照规划中的明确职责分工和工作流程，制定相关规章制度和管理办法，建立督导检查和考核机制，保证信息资源管控体系的高效和规范，确保数据生命周期管理、数据安全管理、数据质量管理的有效性。
(4) 信息系统建设
信息系统是信息数据录入、存储、加工、传输的载体。信息资源规划、数据标准建设的成果，需要落实到信息系统建设中，才能发挥出实际效益。数据治理中的信息系统建设，一方面管理信息系统的开发建设，主要包括全行性的用于数据管理的信息化基础设施类项目，如: 基础数据平台建设、数据仓库建设、数据总线建设等，以及全行性的综合分析与报表类的项目，如:综合报表系统 、综合信息分析系统等;另一方面建设是其它信息系统遵循数据治理的规划，统一执行数据标准的工作。信息系统的建设与完善是个长期的过程，需要在数据架构规划下，结合银行实际情况视条件逐步实施，例如，数据仓库的建设前提，是数据源头系统中基础数据的相对完善。
基础架构建设主要研究解决如何建设信息技术基础性资源的问题 银行的基础架构建设模型:
IT 治理架构建设主要解决如何建立一个科学有效的IT组织架构，理顺关系、防控风险、提高效率。
IT治理，是一个由关系和过程所构成的体制，用于指导和控制企业，通过增加价值，同时平衡信息技术及其流程的风险与收益，来确保实现企业的目标。IT治理是公司治理必不可少的一部分，它负责有效、高效地实现相关企业流程的重大改进。IT 治理为IT 过程、IT 资源、信息与企业战略、企业目标的连结提供了一种体制。IT治理将IT任务的规划与组织、获取与实施、交付与支持、监控的最佳实践整合起来，并加以制度化，从而保证企业的信息与相关信息技术对企业业务目标的支持。这样，IT治理使得企业能够充分发挥其信息优势，实现利润最大化，抓住机遇进行投资，赢得竞争优势。
在不同层级上建立IT与业务协调的决策机制，确保信息科技工作符合全行业务发展的要求，规范决策流程，提高决策效率。
(1) 战略层: 建立高层组织负责对信息化战略规划、重大政策与重大项目建设进行决策与协调，实现规范、高效的高层管控，确保信息化战略规划与全行业务发展战略规划的一致性。
(2) 管理层:科技专职管理部门负责建立应用架构、基础架构、数据架构、资源配置的统筹与决策机制，保证应用架构、基础架构、数据架构与业务架构一致，保证信息化资源配置符合业务发展需要。
(3) 实施层:强化项目管理、业务需求、软件开发、软件测试、生产运行等具体工作的组织、实施与管理，保证信息科技具体工作成果与业务目标的一致性，保证项目技术方案与信息化整体架构的一致性。
首先，是银行的战略目标：
目标的运营模式：未来银行的业务基础
目标的组织架构：业务将如何被组织
目标的业务与技术需求：产品、服务的技术需求
一、运营模式：
例如：
平衡的业务组合，对公和零售业务（包括：互联网），以分散经济周期对收入带来的影响
协同营销与交叉销售，每个客户账户有多个产品类别在其中
开放的业务平台，除了银行本身的传统存、贷业务，还支持第三方产品，中间业务、人民币业务、外汇业务
差异化与客户集中，针对细分市场对客户进行差异化服务（例如，大数据营销、智能投顾等）
整合渠道营销与管理，网银、电子银行、手机银行、电话银行、网点等，各个渠道对客户整合划一
现状与差距分析：
例如：
与业务战略的一致性：
一些银行正在业务转型，对公为主转型平衡业务组合
客户信息分散无法集中分析：
各产品、业务线、产品组合盈利分析能力不足
各组织单元间的协调：
总行、分、支行等，系统外挂、应用不一致，支撑组织结构能力不足
流程效率：
柜面处理流程繁琐、效率低，无法满足客户需求
风险管理：
反欺诈、反洗钱、大数据风控等不够成熟
二、组织结构满足业务战略目标的需要，战略选择的不同，直接影响组织结构、业务管理流程的不同，从而对核心系统的要求不同
例如：产品管理
三、总体的改造计划
对核心模块的改造实施影响评估，优先度矩阵
核心业务系统
产品结构
附：当时民生银行的系统架构（改造前）
接下来就是确定需求和组织实施，挑选供应商
系统应用架构
根据上海农商银行的现状,结合金融信息化的发展趋势,银行不再仅仅需要一个统一的会计核算的系统,而是通过核心业务系统的建设,实现前、中、后台各个业务系统的贯通和整合,通过信息技术使从渠道和支付,到产品和服务,再到经营分析、监管上报各个层面的银行业务协调一致、互相支持,形成统一的整体。这就是核心业务系统整体解决方案的主要目标。
为实现这一目标,融合其国内外的成熟产品,结合多年IT规划的实践经验,为上海农商银行设计了核心业务系统的整体解决方案,提供包括综合柜员系统、核心业务系统、企业服务总线、数据整合平台等在内的一系列产品和平台,初步构建了一个真正整合一体,达到国际先进水平的IT体系,未将来进一步的扩展打下坚实的基础。
为了实现这一目标,架构设计原则是
以客户为中心,根据业务需求规划架构和产品;
结构层次灵活、开放、可扩展;
实现服务、数据的共享、集成。
数据移植
第一,确认核心业务系统项目方案涉及的数据移植范围:原综合业务系统向新核心业务系统的移植,综合前置各渠道系统、中间业务的数据移植,以及其他外围系统的数据移植。
第二,收集和对比新旧系统的数据关系,完成数据映射,给出新旧系统的数据差异和数据补缺方法,完成数据移植详细设计和数据映射词典;
第三,在完成数据移植详细设计后,开发数据导出程序、数据补缺程序、数据转换程序和数据导入程序,开发数据校验和帐务校验程序;
第四,对数据移植程序和移植的结果进行正确性验证。在完成数据移植程序开发后,选定典型日期进行移植并验证数据移植结果,进行移植并验证数据移植结果。
第五,为UAT用户测试提供数据。
传统银行架构变迁
银行属于传统的金融行业，银行业随着科技的不断进步和客户需求的不断提升，对银行科技系统的要求也是逐渐提高，而且随着近几年互联网金融的快速发展，传统银行业系统的发展也是非常迅速，本人08、09年最早在外企从事北美银行网银和手机银行的产品开发工作，后来从10年一直到16年一直在大型国有银行从事软件开发和架构设计的工作，16年中从国有银行离开加入互联网电商，做了不到一年因为种种非技术问题离开又回归了银行系统，目前在一家微型民营银行从事产品设计、架构设计的工作。总的来说还是经历了这几年银行系统快速发展的时期，也涉及了大型架构的变迁，今天就给大家介绍下银行的架构变迁，如有不对的地方还请专家指正。
90年代初期国内银行业蓬勃发展，早期各个分行都是人工记账，定期由省分行统一报送总行系统，随着国内经济的快速发展，银行的业务量也随之暴涨这样的工作模式已经无法满足需求了，所以90年代初4大国有银行都纷纷加强科技部的研发投入，参考美国、英国银行系统建设经验开始建设现代化银行系统，其实在那个年代大家对计算机的印象还非常陌生，在每个柜面都架设计算机，当时的柜面系统都是统一的命令行模式，没有可视化界面，后台系统采用的是集中式的架构，如下图所示：
当时的银行系统基本都是这样的集中式架构，大型国有银行一般也都是这种简单架构，当时大部分行业的系统也都是这样的架构。在这样的架构下柜面前端和后端系统采用的是CS架构，胖客户端的模式，每次客户端升级都需要将安装包提前一天下发给各个网点，现在看起来还是比较low的。银行后端是大核心的模式，即核心系统承担了主要的功能，账户、存贷款、总账、对账、支付、来账等功能都在集中式的大核心系统中，只有很少的一部分功能被剥离出核心系统，归属于外围系统。这些外围系统一般都是市面上有一些软件公司提供了现成的产品，只需要简单的二次开发就可以满足需求，这样一方面降低了开发成本，另一方面也加快的系统实施的进度。但是这种架构的系统承载能力还是比较有限的，随着交易量的快速上升很快就满足不了需求了，听行里的前辈介绍当年的场景，就是他们科技部每天都很忙，交易量每个月都会有大幅增长，每个季度的计息日批量和年底的年终决算都会让所有人忙通宵，这些记忆也成为了所有那个年代银行人痛苦的回忆。
集中式的系统已经逐渐满足不了高速增长的业务需求了，所以规模比较大的国有银行就开始考虑将现有的总行集中式系统分别在各个省分行分别都部署一套，每天晚上再通过批量的方式将各省数据进行集中，这种架构的方式能够最快的解决联机性能问题，但是又会引发新的问题，那就是跨省转账交易无法实时到账，就算是同一家银行的跨省转账一般也无法做到。所以90年代中后期的系统架构图如下图所示：
看图就可以发现，和之前的架构区别主要就是将总行集中式的部署架构调整为了各省分布式的架构，但是这种分布式架构并不是我们现在讨论的互联网分布式架构，当年还没有比较成熟的分布式架构方案，所以当时的分布式其实只是简单的将原先总行部署的一套核心系统和配套的外围系统分别在各省科技部分别部署，分别独立运维，就好像机构在整体行政关系上是一体的，但是实际科技系统是分开的，没有必然的联系，只是每天会进行数据交换来实现跨省转账、票据承兑等业务，所以很多银行业务的效率比较低，很难满足一些比较急迫的客户需求，最后出现了一些现象就是一个客户为了给一个跨省的客户汇款，最快的手段是先用自己本地的卡取现金，再人肉带到异地，有朋友要问了为什么不到当地再取，因为那个年代跨省取现不但取现时间、金额受限制还有高额的手续费。
2000年互联网高速发展，银行的科技水平也在这几年中高速发展，各家行的水平也逐渐拉开了差距，之前老的各省分布式部署的业务问题也渐渐凸显，由工行率先将之前分布式部署的省行系统进行总行上收，系统上收可不是那么简单，当年为什么要各省分别部署？就是因为集中式系统架构已经无法承载每天高速发展的业务量，如果再将各省的数据上收，那就意味着可能每天核心批量还没跑完还没来得及分发给外围系统就已经到第二天开门营业时间了。这么做科技部门需要承担的压力还是非常大的，需要解决很多问题，主要有以下问题：1）数据结构统一，数据映射，各省数据上收，数据迁移；2）新系统开发工作；3）系统上收对上收省份日常业务的影响；4）分行员工新系统的培训工作；5）新旧系统的平滑迁移，新旧系统的日常兼容性交互；6）整体的投产迁移方案、回退方案。我当时在中国银行也有幸经历了这一过程，整个过程持续了快4年，从整体的方案设计到系统的实施再到后面的系统迁移上线等等一系列工作，这个过程是艰难的，基本上加班成为常态，但是在这个过程中也学到了很多东西，也是成长比较快的一个时期。整个改造的一个核心架构思路就是对核心系统进行瘦身，将核心系统精简化，以此来提高核心系统的业务处理吞吐量，并采购最新的大型机来保证处理性能和IO性能，将大部分的业务都单建系统拆离出核心系统，基本上这样的整体架构在当时评估的时候能保证未来10－20年的业务发展量。下图为当时的整体架构图，但是从这个架构图中可以发现，整体架构核心系统和外围系统，再和渠道系统之间都是非常混乱的，系统间是完全的网状结构，图里还没有完全画完，因为画完以后基本是没办法看的，非常复杂的蜘蛛网。有个别系统因为是外包采购的系统的报文结构和其他系统都是不一样的，这样一旦某个系统要和这些奇葩系统进行对接就会遇到这样的问题，需要把这些奇葩接口的报文全部处理一遍，这就导致了很多重复的工作。
大部分银行很快就意识到这种集中式网状架构的缺陷，当时也正好流行ESB总线架构，所以银行系统也不免俗的纷纷去实现ESB总线。总线架构就是在渠道系统和核心、外围系统之间建立了一个ESB总线桥梁，所有的外围和核心系统的接口都注册发布到ESB总线上，由总线对外提供完全统一的接口标准协议，这样就避免了每个系统接入都是同一套标准接口，不用重复去实现不同的报文协议。这样的架构看起来就非常清爽了，不管是渠道系统还是外围系统调用各个系统的接口的时候都比较方便。这样的架构在银行系统中实施了很长时间，包括目前大部分的银行还都是采用这种架构模式，虽然现在看起来非常普通，但是当时看起来此种架构还是非常完美的。而且这种架构对于中小银行就算现在使用起来也是非常合适的。
随着互联网的发展网上银行、手机银行、直销银行纷纷成为新的渠道，人们也开始快速接受这种新兴的互联网渠道，互联网总线架构和之前架构的最大差别在于安全架构，后面会再单独写两篇关于安全的文章。其他方面的架构基本没什么变化，但是会发现一种现象就是，因为核心系统不新增大功能的情况下，不断新增外围新产品，当时中国银行一共有一百多个外围系统，还没算一些快下线的系统。随着业务量的不断上升，核心系统的业务量不断上升，总线的压力也逐渐上升，总线机器不断的横向水平扩展，在走之前总线的集群就扩展到了100个节点。
到了2012年以后随着facebook、amazon开放平台获得的巨大成功，BAT都逐步将自己的接口开放出来，都实施了开放平台生态圈战略，从而推动了SOA服务化的更快速发展。银行之前也一直在研究服务化的实施方案，但是由于ESB总线架构运转的非常稳定，也没出什么问题，所以导致各个行进行服务化改造的动力不是很强，而且这种整体架构的调整涉及到的部门和业务影响都是非常大的，一般银行这样比较稳妥的公司也都不敢有大的动作。我也是有幸在银行赶上了中国银行试点互联网金融，对新建的互联网金融系统实施服务化架构，下面就是当时中国银行的互联网金融服务架构，这个架构其实是一个传统银行互联网金融的一个妥协架构。
从架构图中可以看到，左边是之前的传统银行集中式总线架构，右边是互联网服务化架构，包含了开放平台、服务注册和发现、服务化产品系统。为什么这样设计，这是因为传统银行的各个产品系统是比较稳定的，而且在银行系统待过的同学都知道传统银行要新建一个系统或者新实施一个需求都是要经过很长的周期，传统银行都是瀑布式开发方式，各种评审、审批流程，导致从需求提出到功能上线基本上3个月过去了，效率还是挺低下的。根本满足不了互联网金融快速迭代的需求，因为当时我们不但试点新的soa架构，同时也在试点迭代开发，所以将互联网金融产品单独排期实施，单独部署，产品系统如果涉及到调用传统银行产品接口的地方全部通过ESB总线来调用传统银行产品系统接口。所有的互联网金融产品系统全部将接口服务化注册到服务注册中心，当时我们所有的互联网金融产品系统全部基于阿里的dubbo开发，系统将接口都注册到zookeeper上，两个系统直接的服务交互采用RPC模式；通过开放平台对外提供接口暴露，可以发现这种架构在保障传统银行系统稳定性的同时也可以满足互金需求的快速迭代实施，并且也使用了新兴的互联网分布式技术，来降低开发和运维的成本，目前我了解到的很多银行都在采用这种架构在实施互联网金融业务。
最近两年随着容器技术的不断发展，私有云平台、devops也逐渐在银行系统中进行试点，目前我所在的一家小型民营银行正在进行这方面的技术试点，底层采用docker进行镜像管理、构建、发布，在系统层面全部采用服务化架构，目前我们使用的是springcloud整体的解决方案。这样的架构看起来也是比较清晰，而且扩展性也很强，能够很好的满足未来业务发展的需求，随着docker技术的不断成熟，后续的devops也是逐渐会替代大部分的人工运维，之前我待过的一家互联网电商，80多个产品系统只有3个运维人员，所有的日常监控、版本部署都是自动化的，基本不需要人工干预，这种模式也是后续银行需要的一种开发和运维的方式。
今天只是大概介绍了下银行系统的历史变迁，真的只是非常简单的介绍，其实每个架构都有很多故事，都可以写很多，等到后续有时间会再把其中发生的很多细节写给大家看：）
农商银行图形柜面系统是什么意思
农商银行图形柜面系统的意思：
图形柜面系统实现了银行核心的图形化，为客户提供更加友好的交互界面，同时结合了金融企业信息化发展的趋势。
整体解决方案如下：一是实现C/S向B/S模式转化。模式的转化不仅仅是提高了客户的体验，同时也对金融企业的数据大集中提供了良好的环境，为后续的数据分析、领导决策作下铺垫；二是便于应用集群，缓解服务器压力。金融企业业务日益增多，IT基础设施的瓶颈突显，为了提高应用性能，集群是一种投资少见效快的方式；三是基于先进的架构进行设计。系统整体采用三层结构，以Spring为底层架构，以IOC容器管理业务对象，引入SOA作为系统集成方法，保障了后续业务的可扩展性、系统的可维护性；四是改进业务流程，提高办公效率。以公司自主研发的柔性工作流平台为基础，可随时定制业务流程，通过简单配置可实现流程更新，能够很好的适应业务的变化。
三大银行，新it架构是啥样
银行IT系统 -整体架构
--银行系统整体架构及发展方向：
1.网络结构：
1.1 中国国家金融通讯网（China National Financial NetWork）:该系统使中央银行、各商业银行及其他金融机构连接在一起
。
1.2 CNFN三层网络结构：
1.一级节点：国家处理中心（National Processing Center，NPC）
2.二级节点：城市处理中心（City Processing Center，CPC）
3.三级节点：人行县支行处理中心（Country Level Bank，CLB）
2.硬件结构:
2.1 服务器：UNIX/LINUX中继器
2.2 网络设备：
组网设备：网卡、传输介质
互联设备：中继器、网桥、路由器、网关、集线器、交换机、调制解调器
2.3 存储设备：磁带机 磁带库
2.4 自助设备：ATM CDM POS 打印机（包括打印存折、回单）
3.软件系统
3.1 中央银行系统
北京：
中国现代支付系统（CNAPS）
中央银行会计集中核算系统（ABS）
中央银行国库业务处理系统（TBS）
中央债券综合业务系统
上海：
全国银行间外汇交易系统
全国银行间同业拆借系统
全国城市商业银行汇票处理系统
中国银联系统
3.2商业银行系统
综合业务系统
综合前置系统
中间业务系统
电子银行系统（网上银行，电话银行，手机银行，自助银行，其他电子银行，未来电子商务）
灾难备份系统
银行其他系统
4.发展方向：
4.1 数据集中化
4.2 数据标准化
4.3 业务多样化
4.4 渠道多元化
--必须掌握的技术
1.编程语言
1.1 c/c++,java
1.2 编译器原理
1.3 使用vi/vim
1.4 使用Makefile
1.5 调试工具gdb/dbx等
2.操作系统
2.1 Linux/Unix原理
2.2 系统命令
2.3 shell编程
2.4 系统管理
3.数据库
3.1 SQL语言
3.2 Oracle/DB2/Informix/MySql/Sybase等数据库原理
3.3 数据库编程
3.4 数据挖掘/数据分析
3.5 数据库管理(DBA)
4.网络通讯
4.1 中间件通讯(Tuxedo/MQ/CICS/Weblogci(Java))
4.2 进程间通讯IPC
4.3 跨主机通讯TCP/IP
4.4 中间件管理
5.系统架构
5.1 了解银行硬件(IBM)
5.2 熟悉B/S体系结构和C/S三层体系结构
5.3 熟悉银行整个网络系统结构
5.4 网络系统管理
--必须掌握的业务
1. 银行会计
1.1 会计科目
按照会计科目反映的经济内容分类：
1.资产类
2.负债类
3.所有者权益类
4.共同类
5.损益类
按照会计科目反映的经济内容分类
1.表内科目
2.表外科目
1.2 记账原则
1.同向相加，异向相减
2.有借必有贷，借贷必相等
2. 银
行核心业务
2.1 资产类：1作为首位科目代号，1011表示现金
1.银行贷款：信用贷款、担保贷款、票据贴现
2.现金管理，金库管理
3.系统：信贷管理系统
2.2 负债类：2作为首位科目号，2011表示对公存款
1.单位存款：活期存款，协定存款，定期存款，通知存款，保证金存款
2.个人存款：活期存款，定活两便，整存整取，零存整取（教育储蓄），通知存款，整存零取，存本取息
3.定期计提，活期结息
4.票据结算类业务：银行汇票，商业汇票（商业承兑汇票，银行承兑汇票），银行本票，支票
5.系统：同城清算系统，现代化支付系统，票据影像交换系统（小额）
2.3 所有者权益类：3作为科目号，312表示利润分配
1.日常业务
2.年终结算业务
2.4 共同类：资产负债共同类，通常表示往来账户，4作为科目号，4070104表示准备金存款
1.业务：金融机构往来，资金拆借/资金划拨，票据结算类业务
2.系统：同城清算系统，现代化支付系统，票据影像交换系统（小额）
2.5 损益类：5作为首位科目号，501，表示利息收入
1.收入类业务
2.支出类业务
3.年终结算业务：成本和费用核算，利润及利润分配
2.6 表外科目：或有资产负债类科目，6作为首位科目号，601表示承兑汇票
1.业务：凭证管理业务（有价单证，主要空白凭证，凭证出售等），贷款业务转表外等
3. 银行外围业务
3.1 中间业务
1.代收代付业务
2.代理证券业务
3.代理保险业务
4.代理国债业务
5.代理财税库银
3.2 外汇业务
1.外汇买卖业务
2.外汇存款业务
3.外汇贷款业务
3.3 信用卡业务
3.4 银联卡业务
1.本代他/他代本存取款
2.本代他/他带本跨行转账
3.Pos消费，Pos退货
4.预授权、预授权完成、预授权撤销、预授权完成撤销
5.商户划账
3.5 IC卡业务（城市一卡通）
1.IC复合卡：使IC卡和磁条合二为一
2.小额消费支付：支付水电煤费用
3.公共交通支付：公交，出租
4.公共设施收费：汽车加油，停车
5.其他便民服务：餐饮超市，数字电视
3.6 现代化支付系统
1.大额支付系统
2.小额支付系统
3.票据影像交换系统
3.7 理财类业务：基金保险
3.8 其他业务：反洗钱，企业征信系统，个人征信系统
--如何学习银行系统
--软件工程
--银行会计科目使用说明
--综合业务系统
--大额支付系统
--小额支付系统
--综合前置系统
--中间业务系统
--进程控制shell脚本
--如何保障运营维护
--如何和客户谈需求
关于《银行柜面系统架构优化》的介绍到此就结束了。
