1. 程式人生 > >應用系統之間數據傳輸的幾種方式

應用系統之間數據傳輸的幾種方式

導致 最簡 批量 發生 插入 響應報文 開放 src www

轉載自:http://www.cnblogs.com/aigongsi/archive/2012/04/26/2413646.html

隨著近年來SOA(面向服務技術架構)的興起,越來越多的應用系統開始進行分布式的設計和部署。系統由原來單一的技術架構變成面向服務的多系統架構。原來在一個系統之間可以完成的業務流程,通過多系統的之間多次交互來實現。這裏不打算介紹如何進行SOA架構的設計,而是介紹一下應用系統之間如何進行數據的傳輸。

應用系統之間數據傳輸有三個要素:傳輸方式,傳輸協議,數據格式

數據傳輸方式一般無非是以下幾種:

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 。

技術分享

這種方式的優點

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請求來的消息,進行展示任務結果

應用系統之間數據傳輸的幾種方式