1. 程式人生 > >應用系統之間資料傳遞的幾種方式

應用系統之間資料傳遞的幾種方式

隨著近年來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 由於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請求來的訊息,進行展示任務結果