第一種方案

Socket方式是最簡單的互動方式。是典型才C/S互動模式。一臺客戶機，一臺伺服器。伺服器提供服務，透過IP地址和埠進行服務訪問。而客戶機透過連線伺服器指定的埠進行訊息互動。其中傳輸協議可以是TCP/UDP 協議。而伺服器和約定了請求報文格式和響應報文格式。

socket演示

目前我們常用的http呼叫，java遠端呼叫，webservices 都是採用的這種方式，只不過不同的就是傳輸協議以及報文格式。

這種方式的優點：

1 易於程式設計，目前java提供了多種框架，遮蔽了底層通訊細節以及資料傳輸轉換細節。

2 容易控制權限。透過傳輸層協議https，加密傳輸的資料，使得安全性提高。

3 通用性比較強，無論客戶端是.net架構，java，python 都是可以的。尤其是webservice規範， 使得服務變得通用。

這種方式的缺點：

1 伺服器和客戶端必須同時工作，當伺服器端不可用的時候，整個資料互動是不可進行。

2 當傳輸資料量比較大的時候，嚴重佔用網路頻寬，可能導致連線超時。使得在資料量互動的時候，服務變的很不可靠。

第二種方案：ftp/檔案共享伺服器方式

對於大資料量的互動，採用這種檔案的互動方式最適合不過了。系統A和系統B約定檔案伺服器地址，檔案命名規則,檔案內容格式等內容，透過上傳檔案到檔案伺服器進行資料互動。

ftp/檔案共享伺服器的方式

最典型的應用場景是批次處理資料：例如系統A把今天12點之前把要處理的資料生成到一個檔案，系統B第二天凌晨1點進行處理，處理完成之後，把處理結果生成到一個檔案，系統A 12點在進行結果處理。這種狀況經常發生在A是事物處理型系統，對響應要求比較高，不適合做資料分析型的工作，而系統B是後臺系統，對處理能力要求比較高，適合做批次任務系統。

這種方式的優點：

1 在資料量大的情況下，可以透過檔案傳輸，不會超時，不佔用網路頻寬。

2 方案簡單，避免了網路傳輸，網路協議相關的概念。

這種方案的缺點：

1 不太適合做實時類的業務

3 必須約定檔案資料的格式，當改變檔案格式的時候，需要各個系統都同步做修改。

第三種方案：資料庫共享資料方式

系統A和系統B透過連線同一個資料庫伺服器的同一張表進行資料交換。當系統A請求系統B處理資料的時候，系統A Insert一條資料，系統B select 系統A插入的資料進行處理。

資料庫共享資料

這種方式的優點：

1 相比檔案方式傳輸來說，因為使用的同一個資料庫，互動更加簡單。

2由於資料庫提供相當做的操作，比如更新，回滾等。互動方式比較靈活,而且透過資料庫的事務機制，可以做成可靠性的資料交換。

這種方式的缺點：

1 當連線B的系統越來越多的時候，由於資料庫的連線池是有限的，導致每個系統分配到的連線不會很多，當系統越來越多的時候，可能導致無可用的資料庫連線

2 一般情況，來自兩個不同公司的系統，不太會開放自己的資料庫給對方連線，因為這樣會有安全性影響

第四種方案：message方式

Java訊息服務（Java Message Service）是message資料傳輸的典型的實現方式。系統A和系統B透過一個訊息伺服器進行資料交換。系統A傳送訊息到訊息伺服器，如果系統B訂閱系統A傳送過來的訊息，訊息伺服器會訊息推送給B。雙方約定訊息格式即可。目前市場上有很多開源的jms訊息中介軟體，比如 ActiveMQ, OpenJMS 。

message方式

這種方式的優點：

1 由於jms定義了規範，有很多的開源的訊息中介軟體可以選擇，而且比較通用。接入起來相對也比較簡單

2 透過訊息方式比較靈活，可以採取同步，非同步，可靠性的訊息處理，訊息中介軟體也可以獨立出來部署。

這種方式的缺點：

1 學習jms相關的基礎知識，訊息中介軟體的具體配置，以及實現的細節對於開發人員來說還是有一點學習成本的

2 在大資料量的情況下，訊息可能會產生積壓，導致訊息延遲，訊息丟失，甚至訊息中介軟體崩潰。

下面具體來分析一個場景，來看看系統之間資料傳輸的應用 場景 目前業務人員需要匯入一個大檔案到系統A，

系統A儲存檔案資訊，而檔案裡面的明細資訊需要匯入到系統B進行分析，當系統B分析完成之後，

需要把分析結果通知系統A。

有什麼用，真正的人體個人體質資訊應由自已保管，自己患病時帶去讓醫生看作為碗究參考，存在系統有什麼用，有的一身很少患重病，有的系統還沒錄完就死了，有的一身很少患病，在年青時很少患病，有的在這個醫院也輸入，在那個醫院也輸入，佔用很多記憶體，記憶體不了就刪了，有什麼用