假設你對項目管理、系統架構有興趣。請加微信訂閱號“softjg”，增加這個PM、架構師的大家庭
隨着近年來SOA（面向服務技術架構）的興起。越來越多的應用系統開始進行分布式的設計和部署。系統由原來單一的技術架構變成面向服務的多系統架構。原來在一個系統之間能夠完畢的業務流程。通過多系統的之間多次交互來實現。這里不打算介紹怎樣進行SOA架構的設計。而是介紹一下應用系統之間怎樣進行數據的傳輸。
應用系統之間傳輸數據有三個要素：傳輸方式，傳輸協議。數據格式
傳輸數據方式一般無非是下面幾種：
1 socket方式
Socket方式是最簡單的交互方式。是典型才c/s 交互模式。一台客戶機，一台server。server提供服務，通過ip地址和port進行服務訪問。而客戶機通過連接server指定的port進行消息交互。
當中傳輸協議能夠是tcp/UDP 協議。而server和約定了請求報文格式和響應報文格式。
如圖一所看到的：
眼下我們經常使用的http調用，java遠程調用。webserivces 都是採用的這樣的方式。僅僅只是不同的就是傳輸協議以及報文格式。
這樣的方式的長處是：
1 易於編程。眼下java提供了多種框架，屏蔽了底層通信細節以及傳輸數據轉換細節。
2 easy控制權限。通過傳輸層協議https，加密傳輸的數據，使得安全性提高
3 通用性比較強。不管client是.net架構，java，python 都是能夠的。尤其是webservice規范，使得服務變得通用
而這樣的方式的缺點是：
1 server和client必須同一時候工作，當server端不可用的時候，整個數據交互是不可進行。
2 當數據傳輸量比較大的時候，嚴重占用網絡帶寬。可能導致連接超時。使得在數據量交互的時候。服務變的非常不可靠。
2 ftp/文件共享server方式
對於大數據量的交互，採用這樣的文件的交互方式最適合只是了。
系統A和系統B約定文件server地址，文件命名規則,文件內容格式等內容。通過上傳文件到文件server進行數據交互。
最典型的應用場景是批量處理數據：比如系統A把今天12點之前把要處理的數據生成到一個文件，系統B第二天凌晨1點進行處理，處理完畢之后，把處理結果生成到一個文件，系統A 12點在進行結果處理。這樣的狀況常常發生在A是事物處理型系統。對響應要求比較高，不適合做數據分析型的工作，而系統B是后台系統，對處理能力要求比較高，適合做批量任務系統。
以上僅僅是說明通過文件方式的數據交互。實際情況B完畢任務之后。可能通過socket的方式通知A，不一定是通過文件方式。
這樣的方式的長處：
1 在數據量大的情況下，能夠通過文件傳輸。不會超時，不占用網絡帶寬。
2 方案簡單，避免了網絡傳輸，網絡協議相關的概念。
這樣的方式的缺點：
1 不太適合做實時類的業務
2 必須有共同的文件server，文件server這里面存在風險。由於文件可能被篡改，刪除，或者存在泄密等。
3 必須約定文件數據的格式，當改變文件格式的時候，須要各個系統都同步做改動。
3 數據庫共享數據方式
系統A和系統B通過連接同一個數據庫server的同一張表進行數據交換。
當系統A請求系統B處理數據的時候。系統A Insert一條數據，系統B select 系統A插入的數據進行處理。
這樣的方式的長處是
1 相比文件方式傳輸來說，由於使用的同一個數據庫，交互更加簡單。
2 因為數據庫提供相當做的操作。比方更新，回滾等。交互方式比較靈活,並且通過數據庫的事務機制。能夠做成可靠性的數據交換。
這樣的方式的缺點：
1 當連接B的系統越來越多的時候，因為數據庫的連接池是有限的，導致每一個系統分配到的連接不會非常多，當系統越來越多的時候，可能導致無可用的數據庫連接
2 普通情況。來自兩個不同公司的系統。不太會開放自己的數據庫給對方連接，由於這樣會有安全性影響
4 message方式
Java消息服務（Java Message Service）是message傳輸數據的典型的實現方式。
系統A和系統B通過一個消息server進行數據交換。系統A發送消息到消息server，假設系統B訂閱系統A發送過來的消息，消息server會消息推送給B。
兩方約定消息格式就可以。
眼下市場上有非常多開源的jms消息中間件。比方 ActiveMQ, OpenJMS 。
這樣的方式的長處
1 因為jms定義了規范，有非常多的開源的消息中間件能夠選擇。並且比較通用。接入起來相對也比較簡單
2 通過消息方式比較靈活。能夠採取同步，異步。可靠性的消息處理，消息中間件也能夠獨立出來部署。
這樣的方式的缺點
1 學習jms相關的基礎知識。消息中間件的詳細配置，以及實現的細節對於開發者來說還是有一點學習成本的
2 在大數據量的情況下，消息可能會產生積壓，導致消息延遲，消息丟失，甚至消息中間件崩潰。
以下詳細來分析一個場景。來看看系統之間傳輸數據的應用
場景 眼下業務人員須要導入一個大文件到系統A，系統A保存文件信息。而文件中面的明細信息須要導入到系統B進行分析，當系統B分析完畢之后，須要把分析結果通知系統A。
A 系統A先保存文件到文件server。
B 系統A 通過webservice 調用系統B提供的server，把須要處理的文件名稱發送到系統B。因為文件非常大。須要處理非常長時間，所以B不及時處理文件，而是保存須要處理的文件名稱到數據庫。通過后台定時調度機制去處理。
所以B接收請求成功，立馬返回系統A成功。
C 系統B定時查詢數據庫記錄，通過記錄查找文件路徑。找到文件進行處理。這個過程非常長。
D 系統B處理完畢之后發送消息給系統A。告知系統A文件處理完畢。
E 系統A 接收到系統B請求來的消息，進行展示任務結果
假設你對項目管理、系統架構有興趣。請加微信訂閱號“softjg”，增加這個PM、架構師的大家庭
