當一個人要把一件事情告訴另外一個人的時候，我們可以通過電話、郵件、短信、IM工具或者當面說的方式來交流。這種方式類似於系統數據交換要通過 tcp、udp、管道等等的方式實現。當兩個人交流的時候，我們需要一種共同的語言才能明白對方的意思，同樣的，兩個系統要交換數據，也需要定義一種雙方都明白的協議，我們稱為“數據交換協議”。
數據交換協議
數據交換協議的目的是讓兩個系統進行正確的數據交互。所以幾乎各種開發語言都提供了方便使用的數據交換功能。比如說使用JAVA語言的開發的系統使用 MySQL數據庫存儲數據，就是通過MySQL數據交換協議跟MySQL做數據交換；通過Java的RMI可以方便的做跨機器的分布式數據交換，RMI也就是一種數據交換協議。
一般我們在不同的系統、不同的語言之間交換數據的時候，我們會選擇一種通用的交換協議或者自己定義一種容易使用的交換協議。 WebService曾經非常流行， 在Web 2.0時代，輕量級的REST協議又開始受到追捧。那麼究竟在我們的系統中應該選擇什麼樣的協議呢？
如何選擇數據交換協議
選擇什麼樣的協議跟我們的應用場景有很大的關系。我們需要考慮我們開發是否方便、接口是否容易發布、是否需要考慮帶寬占用成本、序列化和反序列化的性能、接口協議的擴展性等等。下面我們看下幾個比較常用的交換協議實現。
上面表格列出了一些常用數據交換協議的一些特性的比較。這裡並沒有比較好壞，只是想說明不同數據交換協議是有區別的，所以我們需要在我們的應用場景中進行選擇。
開放式
像微博，SNS這種開放平台、對靜態Html頁面提供Javascript接口調用的系統都屬於這種類型 。這種類型的特點是：
1、調用方不完全可控，而且是針對公網的，你可能不知道是誰、是什麼語言、是什麼方式在調用你提供的數據接口；
2、接口訪問量一般都非常大，要求具有很高的性能和吞吐量；
3、需要考慮安全問題，外部提交的數據可能不是合法的。
所以在這種情況下，需要考慮數據傳輸的帶寬消耗和數據交換協議的易用性，以及多語言支持程度。以前對於Html頁面使用的Javascript接口調用一般都使用XML格式，最近幾年幾乎都轉成了json格式了，因為JSon傳輸量更小，比XML更加容易使用。
而對於開放平台，由於使用的場景很多，所以需要提供多種交換協議格式。基本上都會提供XML和JSon。為了提高平台本身的性能和客戶端的性能，也可以提供protobuf這種二進制交換協議並且增加壓縮支持，以節省帶寬傳輸和解析的性能消耗。
內部服務
對於一個大型系統來說，內部服務的數據交換無處不在。從最基本和常見的數據庫數據交換、memcached緩存數據交換、消息隊列的數據交換到系統之間使用的RPC服務框架等等，都可以算作內部服務的數據交換。內部服務的特點是不用考慮防火牆，不對外開放，速度快（基本無帶寬成本）。
內部服務的數據交換協議的選擇空間非常大，一般需要考慮：
1、數據交換協議的性能
2、是否需要跨語言支持
3、數據交換協議的消息體大小
持久化存儲
對於持久化存儲來說，每一種數據交換協議其實都可以實現。一般需要根據應用場景考慮：
1、是否人工可閱讀
2、存儲的空間消耗
3、序列化和反序列化的性能
4、是否經過壓縮
跨語言
假設我們的網站前端頁面展示層使用PHP語言開發，中間業務邏輯使用Java語言開發，那麼就涉及到跨語言數據交換的問題。只要系統不是單純的使用一種語言，那麼就必須考慮這個問題。事實上，考慮未來的擴展和需求變化問題，也最好考慮跨語言的數據交互協議。
數據交換協議可升級
在選擇數據交換協議的時候，我們同樣需要考慮類似於數據庫表的?schema設計時的擴展問題。比如一個提供用戶信息的數據交換協議接口，現在包含用戶名、性別、住址的信息，在升級過程中，增加了一個最後登錄的IP信息。如果不考慮數據交換協議升級帶來的影響，很可能會導致以前的客戶端出現異常或者舊的數據無法正確解析的問題。
兼容協議的巧用
兼容協議的巧用非常有用，新產品兼容提供現有成熟的數據交換協議，可以降低使用門檻和產品的開發速度。比如新浪開源的memcacheQ就使用了memcached協議。
總結
數據交換協議的各種通用開源實現非常多，數據交換協議只是一個非常寬泛的說法，其實只要實現了數據的序列化和反序列化 ，那麼就可以說是一個可以交換數據的協議。數據交換協議的性能其實就是序列化和反序列化的性能，如果加上RPC，那麼跟RPC實現本身的性能也有非常大的關系。
