當(dāng)一個(gè)人要把一件事情告訴另外一個(gè)人的時(shí)候，我們可以通過(guò)電話、郵件、短信、IM工具或者當(dāng)面說(shuō)的方式來(lái)交流。這種方式類似于系統(tǒng)數(shù)據(jù)交換要通過(guò) tcp、udp、管道等等的方式實(shí)現(xiàn)。當(dāng)兩個(gè)人交流的時(shí)候，我們需要一種共同的語(yǔ)言才能明白對(duì)方的意思，同樣的，兩個(gè)系統(tǒng)要交換數(shù)據(jù)，也需要定義一種雙方都明白的協(xié)議，我們稱為“數(shù)據(jù)交換協(xié)議”。

　　數(shù)據(jù)交換協(xié)議

　　數(shù)據(jù)交換協(xié)議的目的是讓兩個(gè)系統(tǒng)進(jìn)行正確的數(shù)據(jù)交互。所以幾乎各種開(kāi)發(fā)語(yǔ)言都提供了方便使用的數(shù)據(jù)交換功能。比如說(shuō)使用JAVA語(yǔ)言的開(kāi)發(fā)的系統(tǒng)使用 MySQL數(shù)據(jù)庫(kù)存儲(chǔ)數(shù)據(jù)，就是通過(guò)MySQL數(shù)據(jù)交換協(xié)議跟MySQL做數(shù)據(jù)交換；通過(guò)JAVA的RMI可以方便的做跨機(jī)器的分布式數(shù)據(jù)交換，RMI也就是一種數(shù)據(jù)交換協(xié)議。

　　一般我們?cè)诓煌南到y(tǒng)、不同的語(yǔ)言之間交換數(shù)據(jù)的時(shí)候，我們會(huì)選擇一種通用的交換協(xié)議或者自己定義一種容易使用的交換協(xié)議。 WebService曾經(jīng)非常流行， 在Web 2.0時(shí)代，輕量級(jí)的REST協(xié)議又開(kāi)始受到追捧。那么究竟在我們的系統(tǒng)中應(yīng)該選擇什么樣的協(xié)議呢？

　　如何選擇數(shù)據(jù)交換協(xié)議

　　選擇什么樣的協(xié)議跟我們的應(yīng)用場(chǎng)景有很大的關(guān)系。我們需要考慮我們開(kāi)發(fā)是否方便、接口是否容易發(fā)布、是否需要考慮帶寬占用成本、序列化和反序列化的性能、接口協(xié)議的擴(kuò)展性等等。下面我們看下幾個(gè)比較常用的交換協(xié)議實(shí)現(xiàn)。

　　上面表格列出了一些常用數(shù)據(jù)交換協(xié)議的一些特性的比較。這里并沒(méi)有比較好壞，只是想說(shuō)明不同數(shù)據(jù)交換協(xié)議是有區(qū)別的，所以我們需要在我們的應(yīng)用場(chǎng)景中進(jìn)行選擇。

　　開(kāi)放式

     　像微博，SNS這種開(kāi)放平臺(tái)、對(duì)靜態(tài)html頁(yè)面提供javascript接口調(diào)用的系統(tǒng)都屬于這種類型 。這種類型的特點(diǎn)是：

    　1、調(diào)用方不完全可控，而且是針對(duì)公網(wǎng)的，你可能不知道是誰(shuí)、是什么語(yǔ)言、是什么方式在調(diào)用你提供的數(shù)據(jù)接口；

    　2、接口訪問(wèn)量一般都非常大，要求具有很高的性能和吞吐量；

    　3、需要考慮安全問(wèn)題，外部提交的數(shù)據(jù)可能不是合法的。

   　 所以在這種情況下，需要考慮數(shù)據(jù)傳輸?shù)膸捪暮蛿?shù)據(jù)交換協(xié)議的易用性，以及多語(yǔ)言支持程度。以前對(duì)于html頁(yè)面使用的javascript接口調(diào)用一般都使用XML格式，最近幾年幾乎都轉(zhuǎn)成了json格式了，因?yàn)閖son傳輸量更小，比XML更加容易使用。

    　而對(duì)于開(kāi)放平臺(tái)，由于使用的場(chǎng)景很多，所以需要提供多種交換協(xié)議格式?；旧隙紩?huì)提供XML和json。為了提高平臺(tái)本身的性能和客戶端的性能，也可以提供protobuf這種二進(jìn)制交換協(xié)議并且增加壓縮支持，以節(jié)省帶寬傳輸和解析的性能消耗。

    　內(nèi)部服務(wù)

    　對(duì)于一個(gè)大型系統(tǒng)來(lái)說(shuō)，內(nèi)部服務(wù)的數(shù)據(jù)交換無(wú)處不在。從最基本和常見(jiàn)的數(shù)據(jù)庫(kù)數(shù)據(jù)交換、memcached緩存數(shù)據(jù)交換、消息隊(duì)列的數(shù)據(jù)交換到系統(tǒng)之間使用的RPC服務(wù)框架等等，都可以算作內(nèi)部服務(wù)的數(shù)據(jù)交換。內(nèi)部服務(wù)的特點(diǎn)是不用考慮防火墻，不對(duì)外開(kāi)放，速度快（基本無(wú)帶寬成本）。

    　內(nèi)部服務(wù)的數(shù)據(jù)交換協(xié)議的選擇空間非常大，一般需要考慮：

    　1、數(shù)據(jù)交換協(xié)議的性能

    　2、是否需要跨語(yǔ)言支持

    　3、數(shù)據(jù)交換協(xié)議的消息體大小

    　持久化存儲(chǔ)

    　對(duì)于持久化存儲(chǔ)來(lái)說(shuō)，每一種數(shù)據(jù)交換協(xié)議其實(shí)都可以實(shí)現(xiàn)。一般需要根據(jù)應(yīng)用場(chǎng)景考慮：

    　1、是否人工可閱讀

    　2、存儲(chǔ)的空間消耗

    　3、序列化和反序列化的性能

    　4、是否經(jīng)過(guò)壓縮

    　跨語(yǔ)言

    　假設(shè)我們的網(wǎng)站前端頁(yè)面展示層使用PHP語(yǔ)言開(kāi)發(fā)，中間業(yè)務(wù)邏輯使用JAVA語(yǔ)言開(kāi)發(fā)，那么就涉及到跨語(yǔ)言數(shù)據(jù)交換的問(wèn)題。只要系統(tǒng)不是單純的使用一種語(yǔ)言，那么就必須考慮這個(gè)問(wèn)題。事實(shí)上，考慮未來(lái)的擴(kuò)展和需求變化問(wèn)題，也最好考慮跨語(yǔ)言的數(shù)據(jù)交互協(xié)議。

    　數(shù)據(jù)交換協(xié)議可升級(jí)

    　在選擇數(shù)據(jù)交換協(xié)議的時(shí)候，我們同樣需要考慮類似于數(shù)據(jù)庫(kù)表的?schema設(shè)計(jì)時(shí)的擴(kuò)展問(wèn)題。比如一個(gè)提供用戶信息的數(shù)據(jù)交換協(xié)議接口，現(xiàn)在包含用戶名、性別、住址的信息，在升級(jí)過(guò)程中，增加了一個(gè)最后登錄的IP信息。如果不考慮數(shù)據(jù)交換協(xié)議升級(jí)帶來(lái)的影響，很可能會(huì)導(dǎo)致以前的客戶端出現(xiàn)異?；蛘吲f的數(shù)據(jù)無(wú)法正確解析的問(wèn)題。

    　兼容協(xié)議的巧用

    　兼容協(xié)議的巧用非常有用，新產(chǎn)品兼容提供現(xiàn)有成熟的數(shù)據(jù)交換協(xié)議，可以降低使用門檻和產(chǎn)品的開(kāi)發(fā)速度。比如新浪開(kāi)源的memcacheQ就使用了memcached協(xié)議。

    　總結(jié)

    　數(shù)據(jù)交換協(xié)議的各種通用開(kāi)源實(shí)現(xiàn)非常多，數(shù)據(jù)交換協(xié)議只是一個(gè)非常寬泛的說(shuō)法，其實(shí)只要實(shí)現(xiàn)了數(shù)據(jù)的序列化和反序列化 ，那么就可以說(shuō)是一個(gè)可以交換數(shù)據(jù)的協(xié)議。數(shù)據(jù)交換協(xié)議的性能其實(shí)就是序列化和反序列化的性能，如果加上RPC，那么跟RPC實(shí)現(xiàn)本身的性能也有非常大的關(guān)系。