本文轉(zhuǎn)載自sina_blog(siangzhang)

---

目錄

1? Socket方式

2? ftp/文件共享服務(wù)器方式

3 數(shù)據(jù)庫共享數(shù)據(jù)方式

4 message方式

5 案例

---

?

隨著近年來SOA（面向服務(wù)技術(shù)架構(gòu)）的興起，越來越多的應(yīng)用系統(tǒng)開始進(jìn)行分布式的設(shè)計(jì)和部署。?
系統(tǒng)由原來單一的技術(shù)架構(gòu)變成面向服務(wù)的多系統(tǒng)架構(gòu)。 原來在一個(gè)系統(tǒng)之間可以完成的業(yè)務(wù)流程，通過多系統(tǒng)的之間多次交互來實(shí)現(xiàn)。?
這里不打算介紹如何進(jìn)行SOA架構(gòu)的設(shè)計(jì)，而是介紹一下應(yīng)用系統(tǒng)之間如何進(jìn)行數(shù)據(jù)的傳輸。

應(yīng)用系統(tǒng)之間數(shù)據(jù)傳輸有三個(gè)要素：

傳輸方式，傳輸協(xié)議，數(shù)據(jù)格式

數(shù)據(jù)傳輸方式一般無非是以下幾種：

1 socket方式、

2 ftp/文件共享服務(wù)器方式、

3 數(shù)據(jù)庫共享數(shù)據(jù)方式、

4 message方式

?

---

1? Socket方式

?

Socket方式是最簡(jiǎn)單的交互方式。是典型才c/s 交互模式。?
一臺(tái)客戶機(jī)，一臺(tái)服務(wù)器。?
服務(wù)器提供服務(wù)，通過ip地址和端口進(jìn)行服務(wù)訪問。?
而客戶機(jī)通過連接服務(wù)器指定的端口進(jìn)行消息交互。?
其中傳輸協(xié)議可以是tcp/UDP 協(xié)議。?
而服務(wù)器和約定了請(qǐng)求報(bào)文格式和響應(yīng)報(bào)文格式。如圖一所示：

目前我們常用的 http調(diào)用， java遠(yuǎn)程調(diào)用， webserivces 都是采用的這種方式， 只不過不同的就是傳輸協(xié)議以及報(bào)文格式。

這種方式的優(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ù)器和客戶端必須同時(shí)工作，當(dāng)服務(wù)器端不可用的時(shí)候，整個(gè)數(shù)據(jù)交互是不可進(jìn)行。

2 當(dāng)傳輸數(shù)據(jù)量比較大的時(shí)候，嚴(yán)重占用網(wǎng)絡(luò)帶寬，可能導(dǎo)致連接超時(shí)。使得在數(shù)據(jù)量交互的時(shí)候，服務(wù)變的很不可靠。

?

---

2? ftp/文件共享服務(wù)器方式

?

對(duì)于大數(shù)據(jù)量的交互，?
采用這種文件的交互方式最適合不過了。?
系統(tǒng)A和系統(tǒng)B約定文件服務(wù)器地址，文件命名規(guī)則,文件內(nèi)容格式等內(nèi)容，?
通過上傳文件到文件服務(wù)器進(jìn)行數(shù)據(jù)交互。

最典型的應(yīng)用場(chǎng)景是批量處理數(shù)據(jù)：例如系統(tǒng)A把今天12點(diǎn)之前把要處理的數(shù)據(jù)生成到一個(gè)文件，系統(tǒng)B第二天凌晨1點(diǎn)進(jìn)行處理，處理完成之后，把處理結(jié)果生成到一個(gè)文件，系統(tǒng)A?
12點(diǎn)在進(jìn)行結(jié)果處理。

這種狀況經(jīng)常發(fā)生在A是事物處理型系統(tǒng)，對(duì)響應(yīng)要求比較高，不適合做數(shù)據(jù)分析型的工作，而系統(tǒng)B是后臺(tái)系統(tǒng)，對(duì)處理能力要求比較高，適合做批量任務(wù)系統(tǒng)。

以上只是說明通過文件方式的數(shù)據(jù)交互，實(shí)際情況B完成任務(wù)之后，可能通過socket的方式通知A，不一定是通過文件方式。

這種方式的優(yōu)點(diǎn)：

1 在數(shù)據(jù)量大的情況下，可以通過文件傳輸，不會(huì)超時(shí)，不占用網(wǎng)絡(luò)帶寬。

2 方案簡(jiǎn)單，避免了網(wǎng)絡(luò)傳輸，網(wǎng)絡(luò)協(xié)議相關(guān)的概念。

這種方式的缺點(diǎn)：

1 不太適合做實(shí)時(shí)類的業(yè)務(wù)

2 必須有共同的文件服務(wù)器，文件服務(wù)器這里面存在風(fēng)險(xiǎn)。因?yàn)槲募赡鼙淮鄹?#xff0c;刪除，或者存在泄密等。

3 必須約定文件數(shù)據(jù)的格式，當(dāng)改變文件格式的時(shí)候，需要各個(gè)系統(tǒng)都同步做修改。

?

---

3 數(shù)據(jù)庫共享數(shù)據(jù)方式

?

系統(tǒng)A和系統(tǒng)B通過連接同一個(gè)數(shù)據(jù)庫服務(wù)器的同一張表進(jìn)行數(shù)據(jù)交換。 當(dāng)系統(tǒng)A請(qǐng)求系統(tǒng)B處理數(shù)據(jù)的時(shí)候，系統(tǒng)A Insert一條數(shù)據(jù)，系統(tǒng)B?
select 系統(tǒng)A插入的數(shù)據(jù)進(jìn)行處理。

這種方式的優(yōu)點(diǎn)是

1 相比文件方式傳輸來說，因?yàn)槭褂玫耐粋€(gè)數(shù)據(jù)庫，交互更加簡(jiǎn)單。

2 由于數(shù)據(jù)庫提供相當(dāng)做的操作，比如更新，回滾等。交互方式比較靈活,而且通過數(shù)據(jù)庫的事務(wù)機(jī)制，可以做成可靠性的數(shù)據(jù)交換。

這種方式的缺點(diǎn)：

1 當(dāng)連接B的系統(tǒng)越來越多的時(shí)候，由于數(shù)據(jù)庫的連接池是有限的，導(dǎo)致每個(gè)系統(tǒng)分配到的連接不會(huì)很多，當(dāng)系統(tǒng)越來越多的時(shí)候，可能導(dǎo)致無可用的數(shù)據(jù)庫連接

2 一般情況，來自兩個(gè)不同公司的系統(tǒng)，不太會(huì)開放自己的數(shù)據(jù)庫給對(duì)方連接，因?yàn)檫@樣會(huì)有安全性影響

?

---

4 message方式

?

Java消息服務(wù)（Java Message Service）是message數(shù)據(jù)傳輸?shù)牡湫偷膶?shí)現(xiàn)方式。?
系統(tǒng)A和系統(tǒng)B通過一個(gè)消息服務(wù)器進(jìn)行數(shù)據(jù)交換。 系統(tǒng)A發(fā)送消息到消息服務(wù)器，如果系統(tǒng)B訂閱系統(tǒng)A發(fā)送過來的消息，消息服務(wù)器會(huì)消息推送給B。?
雙方約定消息格式即可。

目前市場(chǎng)上有很多開源的jms消息中間件，比如 ActiveMQ, OpenJMS ,RabbitMQ。

• 1

這種方式的優(yōu)點(diǎn)

1 由于jms定義了規(guī)范，有很多的開源的消息中間件可以選擇，而且比較通用。接入起來相對(duì)也比較簡(jiǎn)單

2 通過消息方式比較靈活，可以采取同步，異步，可靠性的消息處理，消息中間件也可以獨(dú)立出來部署。

這種方式的缺點(diǎn)

1 學(xué)習(xí)jms相關(guān)的基礎(chǔ)知識(shí)，消息中間件的具體配置，以及實(shí)現(xiàn)的細(xì)節(jié)對(duì)于開發(fā)人員來說還是有一點(diǎn)學(xué)習(xí)成本的

2 在大數(shù)據(jù)量的情況下，消息可能會(huì)產(chǎn)生積壓，導(dǎo)致消息延遲，消息丟失，甚至消息中間件崩潰。

?

---

5 案例

下面具體來分析一個(gè)場(chǎng)景，來看看系統(tǒng)之間數(shù)據(jù)傳輸?shù)膽?yīng)用

?

場(chǎng)景?
目前業(yè)務(wù)人員需要導(dǎo)入一個(gè)大文件到系統(tǒng)A，系統(tǒng)A保存文件信息，而文件里面的明細(xì)信息需要導(dǎo)入到系統(tǒng)B進(jìn)行分析，當(dāng)系統(tǒng)B分析完成之后，需要把分析結(jié)果通知系統(tǒng)A。

A 系統(tǒng)A先保存文件到文件服務(wù)器。

B 系統(tǒng)A 通過webservice?
調(diào)用系統(tǒng)B提供的服務(wù)器，把需要處理的文件名發(fā)送到系統(tǒng)B。由于文件很大，需要處理很長(zhǎng)時(shí)間，所以B不及時(shí)處理文件，而是保存需要處理的文件名到數(shù)據(jù)庫，通過后臺(tái)定時(shí)調(diào)度機(jī)制去處理。所以B接收請(qǐng)求成功，立刻返回系統(tǒng)A成功。

C 系統(tǒng)B定時(shí)查詢數(shù)據(jù)庫記錄，通過記錄查找文件路徑，找到文件進(jìn)行處理。這個(gè)過程很長(zhǎng)。

D 系統(tǒng)B處理完成之后發(fā)送消息給系統(tǒng)A，告知系統(tǒng)A文件處理完成。

E 系統(tǒng)A 接收到系統(tǒng)B請(qǐng)求來的消息，進(jìn)行展示任務(wù)結(jié)果

總結(jié)

以上是生活随笔為你收集整理的Web应用系统中数据传递的方式汇总的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。