提及資料結構，我想大多數的程式設計師第一個想起的應該是JSON和XML，然後就沒了。其實不然，如果我們想起只是JSON和XML的話，那就說明我們的視野確實太過狹窄。下面我們來一起談談那些比JSON和XML相對高階的資料結構。

要談資料結構，我們首先要了解一個術語：RPC，他的全程是Remote Procedure Call Protocol ，可以翻譯為：遠端過程呼叫協議。它是一種通過網路從遠端計算機程式上請求服務，而不需要了解底層網路技術的協議。RPC協議假定某些傳輸協議的存在，如TCP或UDP，為通訊程式之間攜帶資訊資料。在OSI網路通訊模型中，RPC跨越了傳輸層和應用層。RPC使得開發包括網路分散式多程式在內的應用程式更加容易。RPC採用客戶機/伺服器模式。請求程式就是一個客戶機，而服務提供程式就是一個伺服器。首先，客戶機呼叫程序傳送一個有程序引數的呼叫資訊到服務程序，然後等待應答資訊。在伺服器端，程序保持睡眠狀態直到呼叫資訊到達為止。當一個呼叫資訊到達，伺服器獲得程序引數，計算結果，傳送答覆資訊，然後等待下一個呼叫資訊，最後，客戶端呼叫程序接收答覆資訊，獲得程序結果，然後呼叫執行繼續進行。

其次我們再來談Protocol Buffer。它是 Google出品的一種輕量、高效的結構化資料儲存格式，效能比 Json、XML 真的強！太！多！具體強多少我們看以下幾點：

1、效能方面：

• 體積小：序列化後，資料大小可縮小至原來的三倍左右；
• 序列化速度快：比XML和JSON快大約20-100倍；
• 傳輸速度快：這個主要是由於資料體積小引起的；

2、使用方面：

• 使用簡單：序列化和反序列化都是有協議自動完成；
• 維護成本低：多平臺只需要一套物件協議檔案；
• 相容性好：不必破壞舊的資料格式就可以直接對資料格式進行更新；
• 加密性好：傳輸過程哪怕是用HTTP，被抓包也只是抓到位元組資料；

3、使用範圍上：

  跨平臺、跨語言、可擴充套件性好

當然，他也有特定的缺點。比如通用性較差，JSON和XML這兩種資料格式都可以幾乎是通用的，但是由ProtocolBuffer組織的資料只適合於特定的環境；還有就是自解釋效能差，它傳輸過程中都是序列化後的位元組資料，可讀性幾乎為零，只能通過反序列化後才行。

然後我們再來說ZeroC-Ice。Ice的全稱是Internet Communications Engine，翻譯為：網際網路通訊引擎。Ice類似於SOCKET通訊技術。Ice 實現各個程序之間的通訊用來傳輸資料，使我們能夠以最小的代價構建分散式應用程式。Ice使我們專注於應用邏輯的開發，它來處理所有底層的網路介面程式設計，這樣我們就不用去考慮這樣的細節：開啟網路連線、網路資料傳輸的序列化與反序列化、連線失敗的嘗試次數等。 Ice 是一種面向物件的中介軟體，為構建面向物件的Client-Sever應用提供了工具、API 和庫支援。Ice 應用適合於異構平臺環境中使用：客戶和伺服器可以採用不同的程式語言，可以執行在不同的作業系統和機器架構上，並且可以使用多種網路技術進行通訊。無論部署環境如何，這些應用的原始碼都是可移植的。 Ice 是 RPC 通訊領域裡最穩定、強大、高效能、跨平臺、多語言支援的老牌開源中介軟體, 特別適合於當前網際網路領域中一個平臺存在多種開發語言程式設計,以及網站和 App 應用並存的複雜大型專案。Ice 實現了語言和平臺中立, 高效通訊, 通過與具體程式語言無關的中立語言 SlIce (Specification Language For Ice)來描述服務的介面,從而達到物件介面與其實現相分離的目的。

• Ice 提供了一種 RPC 協議,既可以把 TCP/IP、也可以把 UDP 用作底層傳輸機制。此外, Ice 還允許你把 SSL 用作傳輸機制,讓客戶與伺服器間的 所有通訊都進行加密。 
• Ice 協議定義了:一些訊息型別,比如請求和答覆型別，每種訊息型別的頭,其中含有像這樣的細節:訊息型別、訊息尺寸、所使用的協議及編碼版本 
• Ice 還支援線上路上進行壓縮:通過設定一個配置引數,你可以讓所有 的網路通訊資料都被壓縮,從而節省頻寬。如果你的應用要在客戶與服務 器間交換大量資料,這種功能會很有用。 
• Ice 協議適用於構建高效的事件轉發機制,因為要想轉發訊息,你不需 要了解訊息內部的詳細資訊。這意味著,訊息交換機不需要對訊息進行任 何解編或重整編——它們可以簡單地把訊息當作不透明的位元組緩衝區加以轉發 
• Ice 協議還適用於構建雙向操作:如果伺服器想要把一條訊息傳送給客戶提供的某個回撥物件,這個回撥物件可以通過客戶原來建立的連線傳給伺服器。如果客戶在防火牆後面,連線只能外出,不能進入,這種特性就特別重要