項目中要使用rpc協議框架來實現兩個系統之間的接口調用。A系統調用B系統的相應接口，因爲考慮到http請求會包含更多冗餘信息，造成請求過大，因此選用了rpc衆多框架中的grpc。
grpc是google開源的rpc框架，目前版本1.0.0，看jar包引入包括netty與okhttp，同時序列化中使用的是protobuf（google自主研發的序列化方式——支持http2.0與多路複用，同時對數據進行壓縮，效率較高，跨平臺），目前grpc中的protobuf使用的是3.0最新版本（除了部分語言目前僅支持protobuf 2版本）。
爲什麼要使用grpc：
RPC可以基於TCP協議也可以基於HTTP協議，基於TCP的RPC協議較爲難讀，不友好，雖然數據量小精簡，但如果對數據速度及IO要求沒有那麼高，完全可以使用基於HTTP協議的rpc。由於gRPC基於HTTP/2標準設計，所以相對於其他RPC框架，gRPC帶來了更多強大功能，如雙向流、頭部壓縮、多複用請求等。這些功能給移動設備帶來重大益處，如節省帶寬、降低TCP鏈接次數、節省CPU使用和延長電池壽命等。同時，gRPC還能夠提高了雲端服務和Web應用的性能。gRPC既能夠在客戶端應用，也能夠在服務器端應用，從而以透明的方式實現客戶端和服務器端的通信和簡化通信系統的構建。
爲什麼要使用protobuf：
Protocol Buffers 是一種輕便高效的結構化數據存儲格式，可以用於結構化數據串行化，很適合做數據存儲或 RPC 數據交換格式。
比json、xml效率更高，以高效的二進制方式存儲，比 XML 小 3 到 10 倍，快 20 到 100 倍。Protobuf 的編程模式比較友好，簡單易學。
有兩項技術保證了採用 Protobuf 的程序能獲得相對於 XML 極大的性能提高：
1. Protobuf 序列化後的信息內容，信息的表示非常緊湊。
Protobuf 序列化後所生成的二進制消息非常緊湊，這得益於 Protobuf 採用的非常巧妙的 Encoding 方法。
2. Protobuf 封解包的大致過程，封解包的速度。
首先我們來了解一下 XML 的封解包過程。XML 需要從文件中讀取出字符串，再轉換爲 XML 文檔對象結構模型。之後，再從 XML 文檔對象結構模型中讀取指定節點的字符串，最後再將這個字符串轉換成指定類型的變量。這個過程非常複雜，其中將 XML 文件轉換爲文檔對象結構模型的過程通常需要完成詞法文法分析等大量消耗 CPU 的複雜計算。
反觀 Protobuf，它只需要簡單地將一個二進制序列，按照指定的格式讀取到程序對應的結構類型中就可以了。從上一節的描述可以看到消息的 decoding 過程也可以通過幾個位移操作組成的表達式計算即可完成。速度非常快。
環境：IntelliJ IDEA 2016 JDK1.8 Gradle3.0
1. gradle安裝grpc-all（或maven都可以）， compile group: ‘io.grpc’, name: ‘grpc-all’, version: ‘1.0.0’
2. 下載IDEA的插件 Protobuf Support，使得IDEA支持Protobuf文件格式。
3. 在main/resources下創建文件夾proto，用來存放proto文件
4. 創建相應的proto文件，使用protoc.exe對proto文件進行編譯，編譯成java文件。
5. 然後使用相應的java文件作爲message，作爲對象使用，序列化、反序列化即可。
之所以結尾很倉促，是因爲領導忽然說基於HTTP的RPC會消耗大量資源，不得已轉入基於TCP的RPC框架，後續可能會有其他更新，比如基於TCP的Dubbo（淘寶的），序列化可以多種選擇，傳輸則是TCP協議，使用了高性能的NIO框架Netty。