作者：代堂鸣
应用集成是解决各个系统之间信息共享中最基础和最重要的一步。我国的商业银行都拥有繁多、复杂的应用系统，重复开发的情况严重，而且不能很好地跨系统共享数据或功能，不利于金融创新能力的提升。本文主要介绍了应用集成的发展阶段，和如何运用集成技术与方式解决系统的烟囱问题，以及相比较之下的优点与局限性。还请各路专家批评指正：）本文适合系统集成人员、应用开发人员或接口组人员阅读，能扩展一定知识面、实现个人技术&业务能力的沉淀和提升、从而设计出更好的集成解决方案。在实际工作中，会遇到各种各样的问题，对开展工作的方式方法或套路还在梳理中，暂不做介绍。此文的输出源于在工作中的一些思考、经查阅资料后而得出的总结，文章内容不代表公司观点。在文末有列出参考资料，方便对某个分支感兴趣的同学，自行深入学习。同时也希望和更多的朋友一起探讨和分享，或直接在留言区说说你的看法，一起成长。应用集成是将基于不同平台、用不同方案建立起异构应用集成的一种方法和技术。对银行信息科技而言，不仅能够充分发挥各单一应用的价值，而且还能使银行的整体运作效率得以提高。在《银行信息系统架构》一书中，关于应用集成是这么说的：“从全行角度看，银行IT系统是一个有机的整体，需要不同应用之间的信息交互和服务协同，那么就要对应用进行集成。”对应用集成的结构化描述叫应用集成架构，可以结构化地描述多个应用之间的关系，具体的例子在下文中会细讲，先一起来看看发展阶段吧。了解应用集成不同发展阶段的定义，有利于银行认识自己，找出差距，更好地有针对性的实施IT规划；有利于从业人员对本专业形成正确的认知；有利于让我们自身知识体系更加丰饶和健全。如何划分我国银行IT系统应用集成的发展阶段，有多种说法，没有一个业界公认统一的标准。同梁礼方老师说的一样，不能用时间点来统一定义。因为不同的银行，成立的时间不一样，应用系统集成的起步时间自然不一样，并且后来成立的银行可以参考前面银行IT建设的经验，虽然起步稍晚，但发展相对会快一点。从银行的应用集成架构模式来梳理，应用集成的发展阶段主要可以分为网状型架构、轮状型架构、总线型架构、API平台和云服务总线。网状型架构又称为'点对点连接'，指不同的应用间处于完全平等的地位，系统间很少有统一的接口规范以及报文格式，任意两个应用间都可以互相连接或服务调用。网状型架构实现了简单、基本的信息交互和数据传递，优点是不必太多关心其他应用的影响，交易路径简短，总体效率高。其缺点也是显而易见的，功能分散、互联复杂、不易管理、缺乏可伸缩性。比如，文件/消息格式、安全策略等集成逻辑是硬编码到应用中；再如，对IT服务没有形成统一管理，检索和发现功能困难，从而阻碍了资源的重用。
从上图可以看出，当时系统间的关联关系非常混乱，整体呈现为网状结构，像蜘蛛网一般。这是因为在系统设计开发时，没有考虑它们之间的互联，所以之后系统建设时，会发现有的外包采购系统与其他系统的报文结构都不一样，与这类系统对接时，需要把接口的报文全处理一遍，导致了很多重复的工作。随着银行信息化的不断深入，系统数据和数量不断增加，系统间的相互访问越来越多、越来越密切，系统的建设难度和改造难度也越来越大。这就是我们经常说的牵一发而动全身，也是我们所“深恶痛绝”的网状型架构的由来。由于网状型架构存在诸多弊端，为了更有效地利用现有的信息系统和资源，使人、财、物等资源在企业内部共享，银行IT建设开始注重系统的内部建设，如统一编码标准、命名标准、元数据定义。因此，演化出了轮状型的应用集成架构模式，也可称为'集中式'。集中式典型的做法是将主要业务处理的综合业务系统作为中心节点，系统只需要与中心相连，便可实现彼此间的交互。其他节点作为综合业务系统的外挂系统。
即Hub模式，使得系统间连接数量大幅减少，而且很容易实现应用之间的整合，便于管理大量的连接和系统。（Hub 模式：是将所有的运输量集中到一个中心节点，然后再向各节点发运的网络模式。）不过，基于中心模式的集成架构，缺点也很明显。由于中间节点既要处理大量的银行业务，又要承担应用之间的交互，具有较大性能瓶颈。尽管国内少数银行仍然采用此种类型的架构，但已经落伍了。随着SOA的兴起，出现了总线型架构，它是目前国内银行中使用最多、最广泛的一种应用集成架构模式。在总线型架构中，银行的主要应用都通过总线连接和交互，总线不处理或很少处理银行业务逻辑，它主要负责应用之间的互联互通等功能，即中介代理。换句话说，总线型架构就是在渠道系统与核心、及外围系统间建立一座桥梁。各系统的接口都注册发布到ESB总线上，由总线发布统一的、标准的接口，不同应用只需要按照总线的规范与总线进行互联。因此对服务使用者而言，无需关心服务提供者是基于什么开发技术或平台提供的服务，不仅避免了因服务提供者接口的变化而需要同步修改此服务调用者的资源，而且也降低了系统间耦合，更方便、高效地实现了对新系统的集成，为服务负载均衡、服务管控提供了更专业的能力。从而简化了银行信息系统的复杂性，提高了系统架构的灵活性，降低了行内信息共享的成本。但随着系统功能的追加，总线程序逐渐成为一个复杂的庞然大物，导致存在隐性风险。例如，逻辑耦合严重，代码难以理解，开发人员职责不清，系统部署困难，回归测试、总线的扩容升级、或是在网络设备上的资源投入成本巨大，以及ESB这种“中心化”服务可能带来灾难性的雪崩效应。加上互联网时代的海量用户与数据，对系统可扩展、高并发及业务响应速度等方面都提出了更高的要求。所以，为了进一步提高银行整体科技能力，需要通过适当的分布式架构转型，来降低开发和运维的成本，有效的实现业务创新和技术变革。分布式架构是利用网络计算机设备，将计算任务和数据分解，充分利用各计算机的计算能力，彼此协调、共同完成一项业务功能的技术架构。在2016年，人行发布了《金融业信息化“十三五”发展规划》，明确提出“以安全、可靠、高效、弹性为重点目标实施架构转型、探索分布式架构和成熟开源技术应用，逐步减少或摆脱对单一技术产品的依赖”。所以无论从技术发展还是监管要求来看，银行核心系统朝着分布式架构、云计算方向发展已是必然趋势。如果将此前的银行系统比作煮鸡蛋，那蛋壳是渠道系统（如营业厅），蛋清是前置服务（如人行前置），蛋黄就是银行核心系统。那现在银行IT系统采用了分布式架构，从煮鸡蛋变成了摊鸡蛋饼，底座鸡蛋饼的接触面更大了，里面可以掺着各种各样的蔬菜、各种各样的佐料。就如同银行不能再像以前一样，保守地将技术应用限制在自己的体内，需要逐步从封闭走向开放。所以为突破对单一资源依赖、促进分布式系统发展、避免单点故障提高可用性、提高复用性等方面原因。在应用集成的过程中，核心和基础组建被抽取出来作为单独的系统对外提供服务，形成API平台。
银行通过API快速开放核心能力，并对API提供安全运行和高效管理的成熟软件，通过API包装成符合互联网模式的产品或服务，积极输出给自身的业务场景、或合作伙伴，实现共赢，加快银行数字化转型的速度。API平台对传统银行互联网化可分为三大能力，分别是服务访问、管理组织和运维管控。服务访问用于提供稳定高效且可线性扩展的服务能力，可细分为协议转换、认证鉴权、服务控制；管理组织包括API的发布和管理、服务授权与消费；运维管控具有多样的运维管理工具，包括日志监控、平台配置等。构建API平台是一项颇具挑战性的任务，受制于过去银行内部系统间报文结构的惯性，业务和技术部门的分隔也是巨大障碍。国内的先行者，有浦发银行的API开放平台和招商银行的企业开放平台，可以通过官网了解到。随着银行业信息化的快速发展，各银行都认识到云平台对银行架构转型的重要性，纷纷大力建设云平台。就来说说能帮助银行实现行内系统之间、与合作伙伴或第三方系统间服务互通的CSB。云服务总线 CSB（Cloud Service Bus）提供平台化的应用集成和服务开放能力，通过统一的服务管理，可以适配多种常见服务协议。CBS支持跨环境服务互通，主要用于专有云、混合云。CSB可以把企业内外应用提供的服务发布成API，供消费方订阅调用，并提供审批授权、服务管控和计量监控等能力。不仅是内部服务开放到外部，还可以是内到内、内到外、外到内、外到外的灵活开放模式。
上图来源于阿里云，这块还不太了解，就不再展开，感兴趣的朋友可以自行深入。接下来进入第二部分～不同的应用场景选用不同的集成技术，下面就从系统间集成需求的角度来对系统集成技术进行分类，好让大家对集成技术有更为深入的认识和思考。
应用功能交互是指系统间互相调用对方提供的功能或服务。数据交互是指系统间以获取对方数据为目的的交互或数据传输，又可细分为轻量、批量（大量）。对联机/实时查询交易来说，也作为轻量的数据交互类型选择合适的集成技术。
- WebService(SOAP/HTTP)使用于快速与ESB平台对接，是连接异构系统或语言的首选协议。它不依赖于语言和平台，便可以实现不同的语言间的相互调用，通过Internet进行基于Http协议的网络应用间的交互，多用于同步通信模式。
- JMS是一个Java平台中关于面向消息中间件（MOM）的API，用于在两个应用程序之间，或分布式系统中发送消息，进行异步通信。Java消息服务是一个与具体平台无关的API，绝大多数MOM提供商都对JMS提供支持。
- RMI是远程方法调用，允许运行在一个Java虚拟机的对象调用运行在另一个Java虚拟机上的对象。这两个虚拟机可以是运行在相同计算机上的不同进程中，也可以是运行在网络上的不同计算机中，但不建议用于大数据量传输。
- Socket是计算机之间进行通信的一种约定或一种方式，可以理解为一组较为稳定接口。通过socket约定，一台计算机可以接收其他计算机的数据，也可以向其他计算机发送数据。
- FTP简称为“文传协议”，用于Internet上的控制文件的双向传输，适用于非实时数据传输，使用客户/服务器模式，它属于网络传输协议的应用层，能操作任何类型的文件而不涉及数据的加工转换。
- ETL是构建数据仓库的重要一环，从数据源抽取出所需的数据，经过数据清洗，最终按照预先定义好的数据仓库模型，将数据加载到数据仓库中去
- DBLink用于当前数据库会话中访问另外一个数据库，适用于oracle数据库之间的数据交互。
- JDBC是一种用于执行SQL语句的Java API，可以为多种关系数据库提供统一访问，它由一组用Java语言编写的类和接口组成。
不难看出，集成其实不是一项简单的任务，需要了解银行业务场景或问题后，经过反复摸索和试错，或者是向有经验的集成架构师取经，才能学到套路。套路不是指可以复制粘贴的代码，而是一些宝贵的建议或工作思路，使用得当，才能帮助我们解决集成目标与具体系统之间的鸿沟。为了寻找更好的应用集成解决方案，所以有不同的应用集成方式，大体上可以分为四种，按演化的顺序和复杂度排序，分别是文件传输、共享数据库、远程过程调用和消息传递。它们在解决某些特定领域的问题时都有自己的特长，而且每个应用都可以使用不同的集成方式，所以应当根据实际情况选择最合适的。文件传输是最简单的应用集成方式，因为文件是一种通用的存储机制，各系统都有具备该功能，集成人员不必了解应用的内部细节。通常是由各应用小组提供文件，然后约定文件服务器地址、文件命名规则、文件内容格式等内容，再通过上传文件到文件服务器进行数据交互即可。当今商业银行对数据分析的需求越来越多，系统之间的数据交互活动越来越频繁，同时，银行对数据文件传输的安全性、可靠性、审计性、完整性、可视化等需求也在不断增加，如银行对账文件、账单文件、批量转联机文件等，所以构建更有效的银行文件传输平台需求日益迫切。银行文件传输平台是银行文件传输的重要工具，目前通用的文件传输技术包括文件拷贝、FTP文件传输协议、TCP/IP传输协议和HTTP协议等。除了技术外，建设时还要分析系统接口现状，安全规范，应用场景，运维场景，监管要求和实施商。比如，纳入银行文件传输平台的文件范围，就需要考虑批量是否会影响联机，因为联机交易对时效性要求比批量更高；再如，与行外系统进行文件传输时，就需要考虑外联机构的系统不支持行内现有传输工具，得充分与合作方进行沟通，确定合适的传输机制等。除了批量转联机文件，文件还有一个细分类型：文件通知，顾名思义即采用文件传输的方式进行通知信息的传达。例如，批量是异步处理，调用者如何知道文件处理到哪一步了呢？可以通过一个查询交易来跟踪处理进度，也可以批量处理方处理完关键步骤后主动对外发送文件通知。
- 方案简单（只要接口双方约定好路径、格式、处理方式即可），实现简单、传输批量数据效率较高。避免了网络传输，网络协议相关的概念。
- 必须有共同的文件服务器，存在安全风险，文件可能被篡改，删除，或者存在泄密等。
- 格式没有统一标准，标准性差，当改变文件格式的时候，需要各个系统都同步做修改。许多集成问题就是由于分析数据的方法不兼容造成的。
共享数据库相比文件传输来说，因为使用的同一个数据库，所以交互更加简单和灵活。通过数据库的事务机制，可以做成可靠性的数据交换，保证了数据的一致性，而且时间特性更强。
让所有应用都能在需要的时候，访问任何共享数据是一个不错的选择。不仅能获取到最新的数据，增强人们对数据本身的信任，而且还能减少因数据修改没迅速传递给应用而造成的错误（如数据不一致）。
但如果所集成的所有应用都依赖于相同的数据库，尽管各个应用能保证数据一致，但会大大增加系统间的耦合性。
例如，当多个应用通过共享数据库频繁读取和修改相同的数据时，数据库会成为一个性能瓶颈，如果各个应用都在对数据完成互斥操作时，还会引起死锁。
当应用分布在不同的位置、通过广域网访问同一个共享数据库时，访问速度可能过慢。分布式数据库的话还会涉及数据存储在哪台机器、是否会存在锁定冲突等问题，都很容易在性能方面带来灾难。
而且多层级的组织架构下，协调各部门配合改用统一的数据库，也是一项非常艰难的任务。
应用集成的实现目标除了数据之外，就是集成应用的功能了，因为数据的改变离不开各应用采取的动作，所以需要一种机制通过传递要共享的数据，结合应用间的函数调用，来告诉接受方应用该如何处理数据。这时就可以使用远程过程调用(RPC)，也可称为外调或外呼。远程过程调用的方法在早些年比较常见，典型的如Java的RMI。在分布式环境下，远程过程调用允许本地计算机上的程序调用远程计算机上的进程。远程过程调用允许发送一个请求（客户进程）到远地进程即被调用者，被调用者或服务器进程执行这个过程并发回一个结果（响应）消息。远程过程调用方法最主要的特点是程序不需要知道调用的过程是本地还是远地。远程过程调用和传统的过程调用不同就在于调用者（Caller或Client）和被调用的进程（Server）是在不同的机器上的不同的进程。其典型的应用场景有很多，从12年说起。随着facebook、amazon开放平台获得的巨大成功，互联网头部大厂也逐步开放接口，实施开放平台生态圈战略，银行业开始试点互联网金融，新建互金系统。传统银行的各个产品系统是比较稳定，采取瀑布式开发方式导致需求实施周期很长，无法满足互金产品快速迭代的需求。所以将互金产品单独排期实施，单独部署。所有的互金产品系统全部将接口服务化注册到服务注册中心，案例是基于阿里的dubbo开发，系统将接口都注册在zookeeper上，两个系统直接的服务交互就采用的是远程过程调用模式。远程过程调用可以跨平台操作，非常灵活。其缺点主要在于采用了同步通信方式，适合于小型的简单应用，而且应用间仍是紧密的耦合在一起，不同的业务场景下还存在操作处理的时序性问题，所以独立地修改系统比较困难。为了支持少量数据的频繁交换、以更加松耦合的异步方式来集成应用，可以使用消息传递。采用消息传递实现系统间的协作和通信，有助于集成人员选择不同的消息传递方式，如把消息广播给多个接收者，或把消息路由给多个接收者之一，有助于将集成设计与应用开发分离，以及流量的削峰填谷、解决最终一致性问题等，是一种兼顾了性能、可靠性和松耦合的一种理想集成方式。（消息路由：指消息发送者不知道消息发送到哪里，它可以将数据发送给一个消息路由器，由它将数据转发给适当的接收者。）异步处理是消息传递的主要应用场景之一。当业务或流程处理过程发送一个消息时，通信双方不需要同时在线等待，任何一方只需各自处理自己的业务。比如在打电话的时候，我们是期望被呼叫的一方能够实时响应，如果不在或者忙的话，发起呼叫的一方只能干等，一旦超过时间会自动结束。就好比系统中的多个应用通信时，一个应用的失败引发所有其他应用也失败，这就是系统的健壮性不够。再如发送手机短信，发送消息之后可以准确的送达到对方，无需保持等待状态。接受短信的一方，等空闲时会进行回复。就类似系统中的异步处理。能降低系统响应时间，提高系统性能和吞吐量，而且由于异步处理在不同的服务间，可以隔离服务，避免雪崩。
从技术平台的开发人员来说，实现消息传递方式的细节有一定的学习曲线，意识到比远程过程调动更慢，但同时也会促使他们设计出高内聚和低耦合的组件；对应用开发人员来说更加灵活，同步或异步都能通过消息接口完成具体内容的发送和接受。
在分布式架构中，消息传递只是作为消息中心基础技术组件的功能之一。高流量、高并发、分布式的情况下，消息可能会产生积压、延迟或丢失，导致一致性难以保证，那么就需要消息中心辅助业务补偿机制，保证最终一致性。
目前业内有多个主流消息中心产品，从实现消息中心的开源技术来看，典型的有RabbitMQ，ActiveMQ，RocketMQ，Kafka，网上有很多资料可以参考。
还没细看，有时间再研究研究。
参考书籍或文献：
1.阿里巴巴.《云栖大会》,2020年
2.笨鸟儿.《应用系统间数据传输方式总结》,2018年
3.monkey01.《传统银行架构变迁》,2017年
4.网络.《几种企业应用集成方式的比较》,2017年
5.王汉明.《银行信息系统架构》,2015年
6.美国侯珀.《企业集成模式》,2006年
好了，就先聊到这儿，希望对各位有所帮助。
今天是国庆、中秋双节前最后一个工作日，小代在这里提前祝各位假日愉快！我们节后再见~ ^_^
---------- END ----------
