信息系統(tǒng)A和信息系統(tǒng)B，假設(shè)B要訪問A的數(shù)據(jù)庫
問題：
◎?是否擔(dān)心數(shù)據(jù)丟失蒲拉，比如丟失率?1%肃拜？
◎?系統(tǒng)時效性要求是否很高，比如是：實(shí)時雌团、秒級、分鐘級還是小時級士聪？
◎?系統(tǒng)間網(wǎng)絡(luò)環(huán)境是否OK锦援，比如是：互聯(lián)網(wǎng)、同機(jī)房剥悟、同城專線灵寺？
◎?系統(tǒng)間有無安全通訊信道等問題需要保障？
初步建議：
◎?不暴露數(shù)據(jù)庫区岗，否則：人家統(tǒng)計你等待略板、人家鎖表你死機(jī)、人家改數(shù)你糾錯慈缔；
◎?約松耦合越好叮称，能批處理就不要實(shí)時處理，能用數(shù)據(jù)交換就不用接口調(diào)用藐鹤，能用異步接口就不用同步接口瓤檐；
◎?是不是WebService隨意，不過現(xiàn)在有不少輕量級方案娱节，主要還是看安全性和性能要求了
第一種方案
?Socket方式是最簡單的交互方式挠蛉。是典型才C/S交互模式。一臺客戶機(jī)肄满，一臺服務(wù)器谴古。服務(wù)器提供服務(wù)，通過IP地址和端口進(jìn)行服務(wù)訪問稠歉。而客戶機(jī)通過連接服務(wù)器指定的端口進(jìn)行消息交互掰担。其中傳輸協(xié)議可以是TCP/UDP 協(xié)議。而服務(wù)器和約定了請求報文格式和響應(yīng)報文格式轧抗。
目前我們常用的http調(diào)用恩敌，java遠(yuǎn)程調(diào)用，webservices 都是采用的這種方式横媚，只不過不同的就是傳輸協(xié)議以及報文格式纠炮。
這種方式的優(yōu)點(diǎn)：
1 易于編程月趟，目前java提供了多種框架，屏蔽了底層通信細(xì)節(jié)以及數(shù)據(jù)傳輸轉(zhuǎn)換細(xì)節(jié)恢口。
2 容易控制權(quán)限孝宗。通過傳輸層協(xié)議https，加密傳輸?shù)臄?shù)據(jù)耕肩，使得安全性提高因妇。
3 通用性比較強(qiáng)，無論客戶端是.net架構(gòu)猿诸，java婚被，python 都是可以的。尤其是webservice規(guī)范梳虽，?使得服務(wù)變得通用址芯。
這種方式的缺點(diǎn)：
1 服務(wù)器和客戶端必須同時工作，當(dāng)服務(wù)器端不可用的時候窜觉，整個數(shù)據(jù)交互是不可進(jìn)行谷炸。
2 當(dāng)傳輸數(shù)據(jù)量比較大的時候，嚴(yán)重占用網(wǎng)絡(luò)帶寬禀挫，可能導(dǎo)致連接超時旬陡。使得在數(shù)據(jù)量交互的時候，服務(wù)變的很不可靠语婴。
第二種方案：ftp/文件共享服務(wù)器方式
對于大數(shù)據(jù)量的交互描孟，采用這種文件的交互方式最適合不過了。系統(tǒng)A和系統(tǒng)B約定文件服務(wù)器地址腻格，文件命名規(guī)則,文件內(nèi)容格式等內(nèi)容画拾，通過上傳文件到文件服務(wù)器進(jìn)行數(shù)據(jù)交互。
最典型的應(yīng)用場景是批量處理數(shù)據(jù)：例如系統(tǒng)A把今天12點(diǎn)之前把要處理的數(shù)據(jù)生成到一個文件菜职，系統(tǒng)B第二天凌晨1點(diǎn)進(jìn)行處理青抛，處理完成之后，把處理結(jié)果生成到一個文件酬核，系統(tǒng)A 12點(diǎn)在進(jìn)行結(jié)果處理蜜另。這種狀況經(jīng)常發(fā)生在A是事物處理型系統(tǒng)，對響應(yīng)要求比較高嫡意，不適合做數(shù)據(jù)分析型的工作举瑰，而系統(tǒng)B是后臺系統(tǒng)，對處理能力要求比較高蔬螟，適合做批量任務(wù)系統(tǒng)此迅。
這種方式的優(yōu)點(diǎn)：
1 在數(shù)據(jù)量大的情況下，可以通過文件傳輸，不會超時耸序，不占用網(wǎng)絡(luò)帶寬忍些。
2 方案簡單，避免了網(wǎng)絡(luò)傳輸坎怪，網(wǎng)絡(luò)協(xié)議相關(guān)的概念罢坝。
這種方案的缺點(diǎn)：
1 不太適合做實(shí)時類的業(yè)務(wù)
2 必須有共同的文件服務(wù)器，文件服務(wù)器這里面存在風(fēng)險搅窿。因?yàn)槲募赡鼙淮鄹泥夷穑瑒h除，或者存在泄密等男应。
3 必須約定文件數(shù)據(jù)的格式闹司，當(dāng)改變文件格式的時候，需要各個系統(tǒng)都同步做修改殉了。
第三種方案：數(shù)據(jù)庫共享數(shù)據(jù)方式
系統(tǒng)A和系統(tǒng)B通過連接同一個數(shù)據(jù)庫服務(wù)器的同一張表進(jìn)行數(shù)據(jù)交換开仰。當(dāng)系統(tǒng)A請求系統(tǒng)B處理數(shù)據(jù)的時候，系統(tǒng)A Insert一條數(shù)據(jù)薪铜，系統(tǒng)B select 系統(tǒng)A插入的數(shù)據(jù)進(jìn)行處理。
這種方式的優(yōu)點(diǎn)：
1 相比文件方式傳輸來說恩溅，因?yàn)槭褂玫耐粋€數(shù)據(jù)庫隔箍，交互更加簡單。
2由于數(shù)據(jù)庫提供相當(dāng)做的操作脚乡，比如更新蜒滩，回滾等。交互方式比較靈活,而且通過數(shù)據(jù)庫的事務(wù)機(jī)制奶稠，可以做成可靠性的數(shù)據(jù)交換俯艰。
這種方式的缺點(diǎn)：
1 當(dāng)連接B的系統(tǒng)越來越多的時候，由于數(shù)據(jù)庫的連接池是有限的锌订，導(dǎo)致每個系統(tǒng)分配到的連接不會很多竹握，當(dāng)系統(tǒng)越來越多的時候，可能導(dǎo)致無可用的數(shù)據(jù)庫連接
2 一般情況辆飘，來自兩個不同公司的系統(tǒng)啦辐，不太會開放自己的數(shù)據(jù)庫給對方連接，因?yàn)檫@樣會有安全性影響
第四種方案：message方式
Java消息服務(wù)（Java Message Service）是message數(shù)據(jù)傳輸?shù)牡湫偷膶?shí)現(xiàn)方式蜈项。系統(tǒng)A和系統(tǒng)B通過一個消息服務(wù)器進(jìn)行數(shù)據(jù)交換芹关。系統(tǒng)A發(fā)送消息到消息服務(wù)器，如果系統(tǒng)B訂閱系統(tǒng)A發(fā)送過來的消息紧卒，消息服務(wù)器會消息推送給B侥衬。雙方約定消息格式即可。目前市場上有很多開源的jms消息中間件，比如 ?ActiveMQ, OpenJMS 轴总。
這種方式的優(yōu)點(diǎn)：
1 由于jms定義了規(guī)范直颅，有很多的開源的消息中間件可以選擇，而且比較通用肘习。接入起來相對也比較簡單
2 通過消息方式比較靈活际乘，可以采取同步，異步漂佩，可靠性的消息處理脖含，消息中間件也可以獨(dú)立出來部署。
這種方式的缺點(diǎn)：
1 學(xué)習(xí)jms相關(guān)的基礎(chǔ)知識投蝉，消息中間件的具體配置养葵，以及實(shí)現(xiàn)的細(xì)節(jié)對于開發(fā)人員來說還是有一點(diǎn)學(xué)習(xí)成本的
2 在大數(shù)據(jù)量的情況下，消息可能會產(chǎn)生積壓瘩缆，導(dǎo)致消息延遲关拒，消息丟失，甚至消息中間件崩潰庸娱。
下面具體來分析一個場景着绊，來看看系統(tǒng)之間數(shù)據(jù)傳輸?shù)膽?yīng)用 ?場景 目前業(yè)務(wù)人員需要導(dǎo)入一個大文件到系統(tǒng)A，
系統(tǒng)A保存文件信息熟尉，而文件里面的明細(xì)信息需要導(dǎo)入到系統(tǒng)B進(jìn)行分析归露，當(dāng)系統(tǒng)B分析完成之后，
需要把分析結(jié)果通知系統(tǒng)A斤儿。
轉(zhuǎn)自：http://blog.csdn.net/yanmh007/article/details/78590409
