近日，神州信息旗下企业神州数码融信软件有限公司（简称：神州数码融信）主办的“求新思变，智在互联——2016年中国银行业创新发展大会”在溧阳顺利举行。现场，神州数码融信首席SOA专家唐智峰分享了《商业银行SOA架构演进》，讲述SOA2.0时代的巨变。

神州数码融信首席SOA专家 唐智峰

演讲摘录

尊敬的各位领导、来宾，大家下午好。下面由我跟大家分享一下神州数码融信在银行IT整体架构建设方面的一些探索实践和经验。

我的题目叫做《商业银行SOA架构演进》。谈到架构，按照标准的定义，架构是指一个大的软件系统，从最顶层开始，采用从宏观到微观、从整体到部分、从复杂到简单的设计和分解方法，并基于这个方法相配套的流程，以及由方法流程演化设计所得的标准模型。SOA的架构思想从1996年Gartner提出相应的概念以后，经过了近二十年的发展，已经非常成熟，并且在众多行业落地应用。在过去的十多年间，神州数码融信基于SOA架构思想构建了整体银行IT系统架构，以及各种业务应用系统。

首先，回顾一下银行IT架构发展的历程

从八十年代的中后期开始，中国银行业开始进行电子化建设。在2000年左右，从手工记账开始向IT切换，根据各个业务部门的需求，构建了类似储蓄、对公、卡、ATM等相对独立的IT系统。在这个阶段，不同的 IT系统互相之间没有太多的关联关系，形成了针对每一个业务应用的信息孤岛，孤岛系统之间没有太多的联系。在那个年代，受限于硬件、网络、软件规模等原因，没有太多的IT架构问题，更多还是以满足业务需求为主。

2000年以后，国内金融行业进入了一个快速发展的阶段。从四大行开始进行IT系统的全国大集中工程，在总行层面进行IT系统重构，开始了以核心系统（或当时叫综合业务系统）为主的新一代IT系统建设，通过核心系统解决了银行70%以上的业务需求，然后围绕着核心系统，建设了国际结算、信贷系统、基金、理财等一系列的专业应用系统。

同时，从2000年开始，互联网大热，从个人应用走向企业应用。随着互联网应用越来越丰富，整体网络基础设施进入了宽带网时代，给商业银行带来了越来越多的电子渠道应用，包括网银、电话银行、Callcenter、短信银行等一系列的新兴电子渠道。电子渠道和专业应用系统，都对核心系统提出了各种各样的接口需求。随着系统建设的逐步推进，整体IT系统慢慢演变成一个类似蜘蛛网的紧耦合架构，这个紧耦合架构图里面，存在几个方面的问题：

• 缺乏顶层的宏观设计，系统架构图里每一个连接线都面临着不同的技术协议。

• 在这些连接点上所提出的访问接口冗余度非常高，比如核心系统提供对外转账接口，给到不同的电子渠道如网银、ATM等，各不一样。这样紧耦合的架构带来了系统的可维护性越来越差，而随着市场竞争持续加剧，新业务需求不断出现，核心系统所承载的需求实现和业务满足程度方面的压力越来越重，非常难以维护。

2006年以后，国内银行业开始引入面向服务即SOA架构思想，站在业务的视角来看待银行IT系统建设，从宏观的银行业务战略出发，根据业务发展规划的重点，梳理出银行面向客户提供的产品和服务；根据梳理出来的产品和服务，归集为不同的产品条线，再把产品条线下的服务进行服务治理、规划和定义，然后将服务进行分组，并归集到各个专业化的应用系统进行服务的落地交付。通过自顶向下的系统架构设计思路解决银行系统规划的问题。这就是当前阶段的SOA架构，或者说面向服务的应用架构体系。

在谈论SOA架构之前，我想分享一下应从哪几个维度来评估新的IT应用架构：

1第一个维度是新的架构思想和架构模型能否带来整体IT生产力的大幅提升。如果仅仅是为了引入某种新技术，或者是新的产品，但是并不能为整体的IT系统生产力带来大幅提升，这些新的技术架构不会给银行带来太多的业务价值。

2 第二个评估的维度是所引入的新IT架构的设计思想和设计理念，能否融入到整体IT价值链条中，为银行的业务战略服务。具体来看，从IT部门的治理，到每一个项目的规划、需求、设计、开发、测试、上线、运行、维护等，所引入的IT架构标准，能否融合到整体业务和IT价值链条中，为价值链的每个环节提供应有的标准和指引。

3 第三个维度，对于新引入的IT架构，系统的整体建设是否围绕着所引入的这个IT架构和IT思想进行相应的分工和协作，包括各个业务部门及IT部门等在内的企业内外部各单元间的分工合作。在引入新架构的同时，银行内部必须明确定义出一套指引整个银行IT系统建设的方法论、流程以及IT治理办法。只有这些方法论、流程和治理办法在银行内部得到各个部门的高度认同并形成共识，其所确定下来的IT架构思想才能得到有效贯彻。

基于这三个评价维度，我们再来看SOA的思想和理念在银行的应用情况

首先，引述一段中国银行业信息科技十三五发展规划监管指导意见：“改进科技规划管理模式，持续优化和完善信息系统架构；推动架构规划方式方法的变革，构建灵活、高效的规划工作机制，积极适应业务转型、产品创新、管理变革对规划调整速度的需求。提升技术架构的精细化水平，基于开放性强、透明度高、适用面广的信息技术提升架构设计和管控能力，鼓励合规使用开源技术和正版软件，鼓励使用创新的分布式架构。积极开展云计算架构规划，制定云计算标准，联合建立行业云平台，主动实施架构转型”。

由此看到，从国家和监管的层面，提出了推动架构规划方式方法的变革要求。从银监会的十三五规划的指引思想来看，商业银行未来五年的架构升级转型方向是清楚的：

1 向云计算转型

对商业银行来说，通过实施云计算，可有效的提升银行IT效率，加速业务敏捷，类似双十一这样的高并发需求，在传统的集中式部署架构下是非常难以适应的。只有主动使用云计算技术，才能较好的解决业务发展对IT提出的挑战。

2 分布式去中心化的部署架构

在传统的以核心系统为中心节点的部署架构中，所有需求围绕着核心系统展开，在目前的市场竞争态势下，银行需要不断的推陈出新，现在互联网金融是热点，明天可能混业经营……这些新的业务需求在传统集中式应用架构下，对中心节点的压力会越来越大。要解决这种问题，必须把压力分散出去，建设可激活系统架构中的每个点的发展潜力的分布式去中心化架构。互联网就是一种典型的分布式架构。互联网之所以能够发展这么迅速，对全人类的历史进程产生这么巨大的影响，其根本原因在于互联网天生就是去中心化的均衡发展架构，它鼓励每一个参与到这个架构体系建设的每个人、每个部门、每个企业，都能够有效地发挥自己的主观能动性，激活每个参与者的潜力，从而到达系统整体效能最大化。

谈到分布式，我们站在一个更宏观的视角来看，从整个IT架构建设的视角，怎样进行的分布式能力建设。业界有几种主流的分布式实现方案，每种方案都有适用的业务场景，各有优缺点。从银行整体层面来看，神州数码融信希望从整体架构方面支持各种不同的分布式实现方案的落地。通过应用架构设计，使这些不同的分布式方案融合在一个大的体系里面，共同并存，协作解决各自面对的技术和业务问题。

3 “互联网+”

“互联网+”作为国家战略，银行未来一定是要把自己的产品和能力向互联网开放，同时，通过互联网把外部世界的能力融合到银行来，实现双向开放融合，用最快的速度实现银行的产品创新。

4 集装箱式微服务架构

《经济学家》曾有一篇文章，说“没有集装箱，就没有全球化”。这里谈集装箱式微服务架构，是SOA架构在当前一个新的发展途径。站在业务的视角进行业务梳理和业务分解，进行完善的服务治理，定义发布出相应的微服务。对一个标准的银行体系来说，有一千多个这样的标准的微服务，才能体现出银行作为一个金融企业所必须具备的产品和能力，这是银行运营基础。有了微服务之后，主要的业务需求将通过集装箱式服务装配的思路来解决。这意味着我们要把这些微服务进行相应的服务流程编排和组合、整合，整合成能够面向最终用户、最终客户进行销售的产品和服务，从而极大提升业务敏捷性。

在SOA架构下，系统由一群组服务组成，每一个专业系统提供专业化的产品和服务能力，同时通过调用其他服务能力，实现完整的业务价值。在这种架构体系之下，需要一个基础的支撑平台，支撑所定义好的服务的调度和使用。

SOA基础支撑平台有两种主要的演进模式，第一种是集中式的实体总线，即“ESB企业服务总线”，第二种是现在开始很多新的银行，或者说更加互联网化的线上银行探索建设的分布式虚拟总线，神州数码融信叫“ESC企业服务云”。

ESB和ESC各有适应的场景：

1 ESB

ESB对于存量系统比较多、历史沿革比较长的银行非常适用，因为大量的存量系统是宝贵的IT资产，SOA架构更多的强调存量资产的重构和保护，继续使用、继续拉长系统的生命周期。在存在较多存量系统的IT体系之下，非常适用集中式的实体总线。通过构建一个逻辑上统一的总线系统来解决所有系统间的服务定义、发布、调用、管控等问题。同时，通过服务治理，建立起全局统一的技术规范和服务规范体系。

2 ESC

第二种模式即去中心化分布式的体系架构ESC，对于如果没有太多的存量系统，系统以新建为主，并明确建立起了一套完整的统一技术规范和服务规范体系的银行，适合构建分布式虚拟总线，即ESC。在ESC架构下，每一个节点都是对等的，互相的服务访问不需要经过服务中介，而是经过已治理好的服务规范和服务访问方法来进行。服务提供者对自己的产品和服务进行明确的定义，然后在注册中心进行注册；服务消费方需要访问服务的时候，先到注册中心访问该服务的服务标准、服务定义和服务地址等，获取这些信息以后，服务消费方与服务提供方直接建立连接进行服务调用。实施分布式架构体系的一个前提是需要建立起统一的技术规范和服务规范体系，如果没有明确建立起统一的技术规范和服务规范，系统往后演进的过程就会回到历史上出现过的紧耦合式结构，这是我们不希望看到的。分布式架构的优点是非常灵活，弹性非常强，而且性能远比集中式的架构高出很多。

这两种SOA演进的模式，都是当前SOA架构发展非常迅速的方向，对于不同的银行，需要根据现状和未来的发展规划，进行相应的评估，确定哪一种方案更适应银行发展的需要。两种不同的演进模式，虽然在部署架构有差别，在其最根本的地方，即对于银行IT治理特别是服务治理的要求是相同的，银行需要建立统一的IT治理体系，以及在治理体系里面至关重要的服务治理和服务体系的落地。

基于此，来看我们所提供的SOA服务治理方法和相应提供的模型

服务治理工作是IT治理主要的组成部分，IT治理又是全行的企业级治理组成部分。服务治理首先要建立起在对IT相关的组织保障和规范流程，明确每一个参与的部门和成员在这个体系里面所承担的角色和责任。有了共识以后，一系列的规范流程才会得以有效的落地。基于这个组织保障和规范流程的基础上，对业务需求进行分析和定义，最终形成全行的金融服务库。

MBSD是神州数码融信自主知识产权的一套面向商业银行服务治理体系和模型。这个模型涵盖了商业银行所有的包括存款贷款支付结算、卡、资金、外汇、理财、供应链等主要的业务条线，共一千多个标准化的微服务，这些标准化定义的微服务可有效帮助银行进行服务治理的工作。

神州数码融信从应用架构集成的角度，提出了解决银行应用集成以及SOA治理问题的SOA2.0整体解决方案

SOA2.0整体解决方案中有几个主要的模块：

• 最主要的是中间ESB或者ESC的运行平台，这个运行平台实现所有的系统间运行时态的服务的互相访问，通过一个统一构建的平台，来解决所有系统的互联互通，互相访问以及服务互操作的问题，对这个平台而言，最主要的要求是这个平台要足够的稳定，所以对SOA运行平台的稳定性要求非常高，甚至比核心系统都会更高，要真正实现永不停机。

• 第二个问题，需要考虑这个运行平台本身的效率，因为对于SOA架构而言，SOA架构相当于把原来紧耦合式的，从消费者到服务端的直接连接服务访问的方法解耦，变成了三层的架构，不管这层是通过什么方式实现，都意味着多出了一层技术上的消耗，怎么样把消耗降到最低，是平台系统设计时需要充分考虑的问题。

• 第三个问题，是安全性问题，所有的系统都通过这个架构进行互相的服务访问和服务消费以后，对他的安全性要求就会远远比任何一个运行系统都高。ESB/ESC运行平台定义于原子服务的发布、调度、运行管理，是SOA架构的基础。在此之上，神州数码融信提供服务组合平台，实现集装箱式微服务的组装、编排、调度和运行管理功能，极大丰富了银行的服务创新能力。

• 与此相配套，还有文件传输平台，用于解决实时交易过程中需要进行文件交换的交易需求，典型的如代发工资之类的服务需求。另外，神州数码融信有基于SOA治理和SOA治理方法相配套使用的服务治理平台，实现服务生命周期管理和服务治理方法的落地。同时，神州数码融信也推出了架构管理平台，通过该平台支持一系列的架构管理分析工作。

• 在企业外部的应用集成方案，神州数码融信提供互联网开放平台，解决了商业银行内部系统和互联网之间的开放融合，把银行内部系统提供的产品和服务向外部开放，也通过开放平台把互联网世界的服务和产品导入进来。外联平台，则实现银行系统与有明确合作关系的第三方合作伙伴系统的集成。

神州数码融信通过SOA2.0的架构设计，在宏观层面上解决跨业务系统的分布式的问题，能最大程度的帮助各业务系统提升业务支撑能力。