本文共字
建议阅读时间：19分钟
作者：代堂鸣
应用集成是解决各个系统之间信息共享中最基础和最重要的一步。我国的商业银行都拥有繁多、复杂的应用系统，重复开发的情况严重，而且不能很好地跨系统共享数据或功能，不利于金融创新能力的提升。本文主要介绍了应用集成的发展阶段，和如何运用集成技术与方式解决系统的烟囱问题，以及相比较之下的优点与局限性。还请各路专家批评指正：）本文适合系统集成人员、应用开发人员或接口组人员阅读，能扩展一定知识面、实现个人技术业务能力的沉淀和提升、从而设计出更好的集成解决方案。在实际工作中，会遇到各种各样的问题，对开展工作的方式方法或套路还在梳理中，暂不做介绍。此文的输出源于在工作中的一些思考、经查阅资料后而得出的总结，文章内容不代表公司观点。在文末有列出参考资料，方便对某个分支感兴趣的同学，自行深入学习。同时也希望和更多的朋友一起探讨和分享，或直接在留言区说说你的看法，一起成长。一、应用集成的基本概念和发展阶段
1、基本概念应用集成是将基于不同平台、用不同方案建立起异构应用集成的一种方法和技术。对银行信息科技而言，不仅能够充分发挥各单一应用的价值，而且还能使银行的整体运作效率得以提高。在《银行信息系统架构》一书中，关于应用集成是这么说的：“从全行角度看，银行IT系统是一个有机的整体，需要不同应用之间的信息交互和服务协同，那么就要对应用进行集成。”对应用集成的结构化描述叫应用集成架构，可以结构化地描述多个应用之间的关系，具体的例子在下文中会细讲，先一起来看看发展阶段吧。2、发展阶段了解应用集成不同发展阶段的定义，有利于银行认识自己，找出差距，更好地有针对性的实施IT规划；有利于从业人员对本专业形成正确的认知；有利于让我们自身知识体系更加丰饶和健全。如何划分我国银行IT系统应用集成的发展阶段，有多种说法，没有一个业界公认统一的标准。同梁礼方老师说的一样，不能用时间点来统一定义。因为不同的银行，成立的时间不一样，应用系统集成的起步时间自然不一样，并且后来成立的银行可以参考前面银行IT建设的经验，虽然起步稍晚，但发展相对会快一点。从银行的应用集成架构模式来梳理，应用集成的发展阶段主要可以分为网状型架构、轮状型架构、总线型架构、API平台和云服务总线。（1）网状型架构网状型架构又称为"点对点连接"，指不同的应用间处于完全平等的地位，系统间很少有统一的接口规范以及报文格式，任意两个应用间都可以互相连接或服务调用。网状型架构实现了简单、基本的信息交互和数据传递，优点是不必太多关心其他应用的影响，交易路径简短，总体效率高。其缺点也是显而易见的，功能分散、互联复杂、不易管理、缺乏可伸缩性。比如，文件/消息格式、安全策略等集成逻辑是硬编码到应用中；再如，对IT服务没有形成统一管理，检索和发现功能困难，从而阻碍了资源的重用。从上图可以看出，当时系统间的关联关系非常混乱，整体呈现为网状结构，像蜘蛛网一般。这是因为在系统设计开发时，没有考虑它们之间的互联，所以之后系统建设时，会发现有的外包采购系统与其他系统的报文结构都不一样，与这类系统对接时，需要把接口的报文全处理一遍，导致了很多重复的工作。随着银行信息化的不断深入，系统数据和数量不断增加，系统间的相互访问越来越多、越来越密切，系统的建设难度和改造难度也越来越大。这就是我们经常说的牵一发而动全身，也是我们所“深恶痛绝”的网状型架构的由来。（2）轮状型架构由于网状型架构存在诸多弊端，为了更有效地利用现有的信息系统和资源，使人、财、物等资源在企业内部共享，银行IT建设开始注重系统的内部建设，如统一编码标准、命名标准、元数据定义。因此，演化出了轮状型的应用集成架构模式，也可称为"集中式"。集中式典型的做法是将主要业务处理的综合业务系统作为中心节点，系统只需要与中心相连，便可实现彼此间的交互。其他节点作为综合业务系统的外挂系统。即Hub模式，使得系统间连接数量大幅减少，而且很容易实现应用之间的整合，便于管理大量的连接和系统。（Hub模式：是将所有的运输量集中到一个中心节点，然后再向各节点发运的网络模式。）不过，基于中心模式的集成架构，缺点也很明显。由于中间节点既要处理大量的银行业务，又要承担应用之间的交互，具有较大性能瓶颈。尽管国内少数银行仍然采用此种类型的架构，但已经落伍了。（3）总线型架构随着SOA的兴起，出现了总线型架构，它是目前国内银行中使用最多、最广泛的一种应用集成架构模式。在总线型架构中，银行的主要应用都通过总线连接和交互，总线不处理或很少处理银行业务逻辑，它主要负责应用之间的互联互通等功能，即中介代理。换句话说，总线型架构就是在渠道系统与核心、及外围系统间建立一座桥梁。各系统的接口都注册发布到ESB总线上，由总线发布统一的、标准的接口，不同应用只需要按照总线的规范与总线进行互联。因此对服务使用者而言，无需关心服务提供者是基于什么开发技术或平台提供的服务，不仅避免了因服务提供者接口的变化而需要同步修改此服务调用者的资源，而且也降低了系统间耦合，更方便、高效地实现了对新系统的集成，为服务负载均衡、服务管控提供了更专业的能力。从而简化了银行信息系统的复杂性，提高了系统架构的灵活性，降低了行内信息共享的成本。但随着系统功能的追加，总线程序逐渐成为一个复杂的庞然大物，导致存在隐性风险。例如，逻辑耦合严重，代码难以理解，开发人员职责不清，系统部署困难，回归测试、总线的扩容升级、或是在网络设备上的资源投入成本巨大，以及ESB这种“中心化”服务可能带来灾难性的雪崩效应。加上互联网时代的海量用户与数据，对系统可扩展、高并发及业务响应速度等方面都提出了更高的要求。所以，为了进一步提高银行整体科技能力，需要通过适当的分布式架构转型，来降低开发和运维的成本，有效的实现业务创新和技术变革。（4）API平台分布式架构是利用网络计算机设备，将计算任务和数据分解，充分利用各计算机的计算能力，彼此协调、共同完成一项业务功能的技术架构。在年，人行发布了《金融业信息化“十三五”发展规划》，明确提出“以安全、可靠、高效、弹性为重点目标实施架构转型、探索分布式架构和成熟开源技术应用，逐步减少或摆脱对单一技术产品的依赖”。所以无论从技术发展还是监管要求来看，银行核心系统朝着分布式架构、云计算方向发展已是必然趋势。如果将此前的银行系统比作煮鸡蛋，那蛋壳是渠道系统（如营业厅），蛋清是前置服务（如人行前置），蛋*就是银行核心系统。那现在银行IT系统采用了分布式架构，从煮鸡蛋变成了摊鸡蛋饼，底座鸡蛋饼的接触面更大了，里面可以掺着各种各样的蔬菜、各种各样的佐料。就如同银行不能再像以前一样，保守地将技术应用限制在自己的体内，需要逐步从封闭走向开放。所以为突破对单一资源依赖、促进分布式系统发展、避免单点故障提高可用性、提高复用性等方面原因。在应用集成的过程中，核心和基础组建被抽取出来作为单独的系统对外提供服务，形成API平台。银行通过API快速开放核心能力，并对API提供安全运行和高效管理的成熟软件，通过API包装成符合互联网模式的产品或服务，积极输出给自身的业务场景、或合作伙伴，实现共赢，加快银行数字化转型的速度。API平台对传统银行互联网化可分为三大能力，分别是服务访问、管理组织和运维管控。服务访问用于提供稳定高效且可线性扩展的服务能力，可细分为协议转换、认证鉴权、服务控制；管理组织包括API的发布和管理、服务授权与消费；运维管控具有多样的运维管理工具，包括日志监控、平台配置等。构建API平台是一项颇具挑战性的任务，受制于过去银行内部系统间报文结构的惯性，业务和技术部门的分隔也是巨大障碍。国内的先行者，有浦发银行的API开放平台和招商银行的企业开放平台，可以通过