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


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

    应用系统之间数据传输有三个要素:

    传输方式,传输协议,数据格式

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

    1 socket方式、2 ftp/文件共享服务器方式、3 数据库共享数据方式、4 message方式



    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 必须约定文件数据的格式,当改变文件格式的时候,需要各个系统都同步做修改。



    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 ,RabbitMQ。
    • 1

    这里写图片描述

    这种方式的优点

    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请求来的消息,进行展示任务结果

    转自:https://blog.csdn.net/erhei0317/article/details/52600012

  • 相关阅读:
    请使用迭代查找一个list中最小和最大值,并返回一个tuple
    利用切片操作,实现一个trim()函数,去除字符串首尾的空格,注意不要调用str的strip()方法
    软件测试中的43个功能测试点总结
    Linux下好用的简单实用命令
    小议堆栈
    使用mac的那些稀奇古怪的事
    探索TypeScript第一步之基础类型
    Markdown的基本使用方法
    React的生命周期
    React中的通讯组件
  • 原文地址:https://www.cnblogs.com/turnip/p/13999271.html
Copyright © 2020-2023  润新知