|银行烟囱式系统难题，如何通过应用集成方式来解决？( 五 )

缺点：

不太适合做实时类的业务；
必须有共同的文件服务器，存在安全风险，文件可能被篡改，删除，或者存在泄密等；
格式没有统一标准，标准性差，当改变文件格式的时候，需要各个系统都同步做修改。许多集成问题就是由于分析数据的方法不兼容造成的。

2）共享数据库
共享数据库相比文件传输来说，因为使用的同一个数据库，所以交互更加简单和灵活。通过数据库的事务机制，可以做成可靠性的数据交换，保证了数据的一致性，而且时间特性更强。
让所有应用都能在需要的时候，访问任何共享数据是一个不错的选择。不仅能获取到最新的数据，增强人们对数据本身的信任，而且还能减少因数据修改没迅速传递给应用而造成的错误（如数据不一致）。

本文插图

但如果所集成的所有应用都依赖于相同的数据库，尽管各个应用能保证数据一致，但会大大增加系统间的耦合性。
例如，当多个应用通过共享数据库频繁读取和修改相同的数据时，数据库会成为一个性能瓶颈，如果各个应用都在对数据完成互斥操作时，还会引起死锁。
当应用分布在不同的位置、通过广域网访问同一个共享数据库时，访问速度可能过慢。分布式数据库的话还会涉及数据存储在哪台机器、是否会存在锁定冲突等问题，都很容易在性能方面带来灾难。
而且多层级的组织架构下，协调各部门配合改用统一的数据库，也是一项非常艰难的任务。
3）远程过程调用
应用集成的实现目标除了数据之外，就是集成应用的功能了，因为数据的改变离不开各应用采取的动作，所以需要一种机制通过传递要共享的数据，结合应用间的函数调用，来告诉接受方应用该如何处理数据。
这时就可以使用远程过程调用(RPC) ，也可称为外调或外呼。远程过程调用的方法在早些年比较常见，典型的如Java的RMI 。
在分布式环境下，远程过程调用允许本地计算机上的程序调用远程计算机上的进程。远程过程调用允许发送一个请求（客户进程）到远地进程即被调用者，被调用者或服务器进程执行这个过程并发回一个结果（响应）消息。
远程过程调用方法最主要的特点是程序不需要知道调用的过程是本地还是远地。远程过程调用和传统的过程调用不同就在于调用者（Caller或Client）和被调用的进程（Server）是在不同的机器上的不同的进程。
其典型的应用场景有很多，从12年说起。随着facebook、amazon开放平台获得的巨大成功，互联网头部大厂也逐步开放接口，实施开放平台生态圈战略，银行业开始试点互联网金融，新建互金系统。
传统银行的各个产品系统是比较稳定，采取瀑布式开发方式导致需求实施周期很长，无法满足互金产品快速迭代的需求。

本文插图

所以将互金产品单独排期实施，单独部署。所有的互金产品系统全部将接口服务化注册到服务注册中心，案例是基于阿里的dubbo开发，系统将接口都注册在zookeeper上，两个系统直接的服务交互就采用的是远程过程调用模式。
远程过程调用可以跨平台操作，非常灵活。其缺点主要在于采用了同步通信方式，适合于小型的简单应用，而且应用间仍是紧密的耦合在一起，不同的业务场景下还存在操作处理的时序性问题，所以独立地修改系统比较困难。
为了支持少量数据的频繁交换、以更加松耦合的异步方式来集成应用，可以使用消息传递。
4）消息传递