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

假设你对项目管理、系统架构有兴趣。请加微信订阅号“softjg”,增加这个PM、架构师的大家庭

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

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

传输数据方式一般无非是下面几种:

1 socket方式

Socket方式是最简单的交互方式。是典型才c/s 交互模式。一台客户机,一台server。server提供服务,通过ip地址和port进行服务訪问。而客户机通过连接server指定的port进行消息交互。

当中传输协议能够是tcp/UDP 协议。而server和约定了请求报文格式和响应报文格式。

如图一所看到的:

眼下我们经常使用的http调用,java远程调用。webserivces 都是採用的这样的方式。仅仅只是不同的就是传输协议以及报文格式。

这样的方式的长处是:

1 易于编程。眼下java提供了多种框架,屏蔽了底层通信细节以及传输数据转换细节。

2 easy控制权限。通过传输层协议https,加密传输的数据,使得安全性提高

3 通用性比較强。不管client是.net架构,java,python 都是能够的。尤其是webservice规范,使得服务变得通用

而这样的方式的缺点是:

1 server和client必须同一时候工作,当server端不可用的时候,整个数据交互是不可进行。

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

2 ftp/文件共享server方式

对于大数据量的交互,採用这样的文件的交互方式最适合只是了。

系统A和系统B约定文件server地址,文件命名规则,文件内容格式等内容。通过上传文件到文件server进行数据交互。

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

以上仅仅是说明通过文件方式的数据交互。实际情况B完毕任务之后。可能通过socket的方式通知A,不一定是通过文件方式。

这样的方式的长处:

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

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

这样的方式的缺点:

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

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

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

3 数据库共享数据方式

系统A和系统B通过连接同一个数据库server的同一张表进行数据交换。

当系统A请求系统B处理数据的时候。系统A Insert一条数据,系统B select 系统A插入的数据进行处理。

这样的方式的长处是

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

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

这样的方式的缺点:

1 当连接B的系统越来越多的时候,因为数据库的连接池是有限的,导致每一个系统分配到的连接不会非常多,当系统越来越多的时候,可能导致无可用的数据库连接

2 普通情况。来自两个不同公司的系统。不太会开放自己的数据库给对方连接,由于这样会有安全性影响

4 message方式

Java消息服务(Java Message Service)是message传输数据的典型的实现方式。

系统A和系统B通过一个消息server进行数据交换。系统A发送消息到消息server,假设系统B订阅系统A发送过来的消息,消息server会消息推送给B。

两方约定消息格式就可以。

眼下市场上有非常多开源的jms消息中间件。比方 ActiveMQ, OpenJMS 。

这样的方式的长处

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

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

这样的方式的缺点

1 学习jms相关的基础知识。消息中间件的详细配置,以及实现的细节对于开发者来说还是有一点学习成本的

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

以下详细来分析一个场景。来看看系统之间传输数据的应用

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

A 系统A先保存文件到文件server。

B 系统A 通过webservice 调用系统B提供的server,把须要处理的文件名称发送到系统B。因为文件非常大。须要处理非常长时间,所以B不及时处理文件,而是保存须要处理的文件名称到数据库。通过后台定时调度机制去处理。

所以B接收请求成功,立马返回系统A成功。

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

D 系统B处理完毕之后发送消息给系统A。告知系统A文件处理完毕。

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


假设你对项目管理、系统架构有兴趣。请加微信订阅号“softjg”,增加这个PM、架构师的大家庭

原文地址:https://www.cnblogs.com/yjbjingcha/p/7274060.html