应用系统之间数据传输的几种方式_第1页
应用系统之间数据传输的几种方式_第2页
应用系统之间数据传输的几种方式_第3页
应用系统之间数据传输的几种方式_第4页
应用系统之间数据传输的几种方式_第5页
全文预览已结束

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

应用系统之间数据传输的几种方式应用系统之间数据传输的几种方式 随着近年来 SOA 面向服务技术架构 的兴起 越来越多的应用系统开始进行分布式的设计和 部署 系统由原来单一的技术架构变成面向服务的多系统架构 原来在一个系统之间可以完成的业 务流程 通过多系统的之间多次交互来实现 这里不打算介绍如何进行 SOA 架构的设计 而是介绍 一下应用系统之间如何进行数据的传输 应用系统之间数据传输有三个要素 传输方式 传输协议 数据格式 数据传输方式一般无非是以下几种 1 socket 方式方式 Socket 方式是最简单的交互方式 是典型才 C S 交互模式 一台客户机 一台服务器 服务器 提供服务 通过 IP 地址和端口进行服务访问 而客户机通过连接服务器指定的端口进行消息交互 其中传输协议可以是 TCP UDP 协议 而服务器和约定了请求报文格式和响应报文格式 如图一所 示 目前我们常用的 http 调用 java 远程调用 webservices 都是采用的这种方式 只不过不同的就 是传输协议以及报文格式 这种方式的优点是 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 这种方式的优点 1 由于 jms 定义了规范 有很多的开源的消息中间件可以选择 而且比较通用 接入起来相对 也比较简单 2 通过消息方式比较灵活 可以采取同步 异步 可靠性的消息处理 消息中间件也可以独立 出来部署 这种方式的缺点 1 学习 jms 相关的基础知识 消息中间件的具体配置 以及实现的细节对于开发人员来说还是 有一点学习成本的 2 在大数据量的情况下 消息可能会产生积压 导致消息延迟 消息丢失 甚至消息中间件崩 溃 下面具体来分析一个场景 来看看系统之间数据传输的应用 场景 目前业务人员需要导入一个大文件到系统 A 系统 A 保存文件信息 而文件里面的明细 信息需要导入到系统 B 进行分析 当系统 B 分析完成之后 需要把分析结果通知系统 A A 系统 A 先保存文件到文件服务器 B 系统 A 通过 webservice 调用系统 B 提供的服务器 把需要处理的文件名发送到系统 B 由 于文件很大 需要处理很长时间 所以 B 不及时处理文件 而是保存需要处理的文件名到数据库 通过后台定时调度机制去处理 所以 B 接收请求成功 立刻返

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论