在很多地方都有“數(shù)據(jù)交換”這個概念，本文所說的“數(shù)據(jù)交換” 是指在計算機網絡中，一個系統(tǒng)把數(shù)據(jù)傳遞給另外一個系統(tǒng)。這非常類似于一個人要告訴另外一個人一件事情。

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

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

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

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

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

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

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

　　開放式

　　像微博，SNS這種開放平臺、對靜態(tài)html頁面提供Javascript接口調用的系統(tǒng)都屬于這種類型 。這種類型的特點是：

• 調用方不完全可控，而且是針對公網的，你可能不知道是誰、是什么語言、是什么方式在調用你提供的數(shù)據(jù)接口；
• 接口訪問量一般都非常大，要求具有很高的性能和吞吐量；
• 需要考慮安全問題，外部提交的數(shù)據(jù)可能不是合法的。

　　所以在這種情況下，需要考慮數(shù)據(jù)傳輸?shù)膸捪暮蛿?shù)據(jù)交換協(xié)議的易用性，以及多語言支持程度。以前對于html頁面使用的Javascript接口調用一般都使用XML格式，最近幾年幾乎都轉成了json格式了，因為json傳輸量更小，比XML更加容易使用。 而對于開放平臺，由于使用的場景很多，所以需要提供多種交換協(xié)議格式。基本上都會提供XML和json。為了提高平臺本身的性能和客戶端的性能，也可以提供protobuf這種二進制交換協(xié)議并且增加壓縮支持，以節(jié)省帶寬傳輸和解析的性能消耗。

　　內部服務

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

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

• 數(shù)據(jù)交換協(xié)議的性能
• 是否需要跨語言支持
• 數(shù)據(jù)交換協(xié)議的消息體大小

　　持久化存儲

　　對于持久化存儲來說，每一種數(shù)據(jù)交換協(xié)議其實都可以實現(xiàn)。一般需要根據(jù)應用場景考慮：

• 是否人工可閱讀
• 存儲的空間消耗
• 序列化和反序列化的性能
• 是否經過壓縮

　　跨語言

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

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

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

　　兼容協(xié)議的巧用

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

　　總結

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

　　我的新浪微博@sunli1223 ,歡迎與我討論。

　　參考鏈接：

• Java序列化和反序列化性能比較：https://github.com/eishay/jvm-serializers/wiki
• Java跨語言調用實現(xiàn)方案 http://rdc.taobao.com/team/jm/archives/389

it知識庫：軟件系統(tǒng)開發(fā)中的數(shù)據(jù)交換協(xié)議，轉載需保留來源！

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。