应用系统之间数据传输的几种方式

转载自:http://www.cnblogs.com/aigongsi/archive/2012/04/26/2413646.htmlhtml

随着近年来SOA(面向服务技术架构)的兴起,愈来愈多的应用系统开始进行分布式的设计和部署。系统由原来单一的技术架构变成面向服务的多系统架构。原来在一个系统之间能够完成的业务流程,经过多系统的之间屡次交互来实现。这里不打算介绍如何进行SOA架构的设计,而是介绍一下应用系统之间如何进行数据的传输。java

应用系统之间数据传输有三个要素:传输方式,传输协议,数据格式python

数据传输方式通常无非是如下几种:web

1 socket方式数据库

 Socket方式是最简单的交互方式。是典型才c/s 交互模式。一台客户机,一台服务器。服务器提供服务,经过ip地址和端口进行服务访问。而客户机经过链接服务器指定的端口进行消息交互。其中传输协议能够是tcp/UDP 协议。而服务器和约定了请求报文格式和响应报文格式。如图一所示:编程

 

目前咱们经常使用的http调用,java远程调用,webserivces 都是采用的这种方式,只不过不一样的就是传输协议以及报文格式。安全

这种方式的优势是:服务器

1 易于编程,目前java提供了多种框架,屏蔽了底层通讯细节以及数据传输转换细节。网络

2 容易控制权限。经过传输层协议https,加密传输的数据,使得安全性提升架构

3 通用性比较强,不管客户端是.net架构,java,python 都是能够的。尤为是webservice规范,使得服务变得通用

而这种方式的缺点是:

1 服务器和客户端必须同时工做,当服务器端不可用的时候,整个数据交互是不可进行。

2 当传输数据量比较大的时候,严重占用网络带宽,可能致使链接超时。使得在数据量交互的时候,服务变的很不可靠。

 

2 ftp/文件共享服务器方式

 

对于大数据量的交互,采用这种文件的交互方式最适合不过了。系统A和系统B约定文件服务器地址,文件命名规则,文件内容格式等内容,经过上传文件到文件服务器进行数据交互。

最典型的应用场景是批量处理数据:例如系统A把今天12点以前把要处理的数据生成到一个文件,系统B次日凌晨1点进行处理,处理完成以后,把处理结果生成到一个文件,系统A 12点在进行结果处理。这种情况常常发生在A是事物处理型系统,对响应要求比较高,不适合作数据分析型的工做,而系统B是后台系统,对处理能力要求比较高,适合作批量任务系统。

 

以上只是说明经过文件方式的数据交互,实际状况B完成任务以后,可能经过socket的方式通知A,不必定是经过文件方式。

 

 

这种方式的优势:

1 在数据量大的状况下,能够经过文件传输,不会超时,不占用网络带宽。

2 方案简单,避免了网络传输,网络协议相关的概念。

这种方式的缺点:

1 不太适合作实时类的业务

2 必须有共同的文件服务器,文件服务器这里面存在风险。由于文件可能被篡改,删除,或者存在泄密等。

3 必须约定文件数据的格式,当改变文件格式的时候,须要各个系统都同步作修改。

 

数据库共享数据方式

系统A和系统B经过链接同一个数据库服务器的同一张表进行数据交换。当系统A请求系统B处理数据的时候,系统A Insert一条数据,系统B select 系统A插入的数据进行处理。

这种方式的优势是

1 相比文件方式传输来讲,由于使用的同一个数据库,交互更加简单。

2 因为数据库提供至关作的操做,好比更新,回滚等。交互方式比较灵活,并且经过数据库的事务机制,能够作成可靠性的数据交换。

这种方式的缺点:

1 当链接B的系统愈来愈多的时候,因为数据库的链接池是有限的,致使每一个系统分配到的链接不会不少,当系统愈来愈多的时候,可能致使无可用的数据库链接

2 通常状况,来自两个不一样公司的系统,不太会开放本身的数据库给对方链接,由于这样会有安全性影响

 

4 message方式

Java消息服务(Java Message Service)是message数据传输的典型的实现方式。系统A和系统B经过一个消息服务器进行数据交换。系统A发送消息到消息服务器,若是系统B订阅系统A发送过来的消息,消息服务器会消息推送给B。双方约定消息格式便可。目前市场上有不少开源的jms消息中间件,好比  ActiveMQ, OpenJMS 。

这种方式的优势

1 因为jms定义了规范,有不少的开源的消息中间件能够选择,并且比较通用。接入起来相对也比较简单

2 经过消息方式比较灵活,能够采起同步,异步,可靠性的消息处理,消息中间件也能够独立出来部署。

这种方式的缺点

1 学习jms相关的基础知识,消息中间件的具体配置,以及实现的细节对于开发人员来讲仍是有一点学习成本的

2 在大数据量的状况下,消息可能会产生积压,致使消息延迟,消息丢失,甚至消息中间件崩溃。

 

下面具体来分析一个场景,来看看系统之间数据传输的应用

场景 目前业务人员须要导入一个大文件到系统A,系统A保存文件信息,而文件里面的明细信息须要导入到系统B进行分析,当系统B分析完成以后,须要把分析结果通知系统A。

 

A 系统A先保存文件到文件服务器。

B 系统A 经过webservice 调用系统B提供的服务器,把须要处理的文件名发送到系统B。因为文件很大,须要处理很长时间,因此B不及时处理文件,而是保存须要处理的文件名到数据库,经过后台定时调度机制去处理。因此B接收请求成功,马上返回系统A成功。

C 系统B定时查询数据库记录,经过记录查找文件路径,找到文件进行处理。这个过程很长。

D 系统B处理完成以后发送消息给系统A,告知系统A文件处理完成。

E 系统A 接收到系统B请求来的消息,进行展现任务结果

相关文章
相关标签/搜索