Grpc的介紹
Grpc是由Google主導開發(fā)的RPC框架，使用HTTP/2協(xié)議并用ProtoBuf作為序列化工具。其客戶端提供Objective-C、Java接口，服務器側(cè)則有Java、Golang、C++等接口，從而為移動端（iOS/Androi）到服務器端通訊提供了一種解決方案。Google對其的聲音是：
- 基于Http2.0標準設計，帶來諸如雙向流、流控、頭部壓縮、單 TCP 連接上的多復用請求等特。這些特性使得其在移動設備上表現(xiàn)更好，更省電和節(jié)省空間占用
- 可以一次性的在一個 .proto 文件中定義服務并使用任何支持它的語言去實現(xiàn)客戶端和服務器，反過來，它們可以在各種環(huán)境中，從Google的服務器到你自己的平板電腦- gRPC 幫你解決了不同語言間通信的復雜性以及環(huán)境的不同.使用 protocol buffers 還能獲得其他好處，包括高效的序列號，簡單的 IDL 以及容易進行接口更新
Grpc的缺點
Grpc的優(yōu)點都由Google說了，就來談談Grpc的缺點吧（這是個人見解）
-
數(shù)據(jù)對象的不友好性
- Grpc的數(shù)據(jù)對象是基于ProtobufV3的Message對象來構(gòu)建其入?yún)⒓俺鰠?，這個數(shù)據(jù)對象不是一個真正的PoJo數(shù)據(jù)對象，基于鏈式管理的風格有的人習慣有的人不習慣，這個是其數(shù)據(jù)不友好性之一
- Grpc的接口調(diào)用，如果是要參數(shù)為空，不好意思，不支持，必須要有一個Message對象，必須要有一個數(shù)據(jù)對象，空的也好，必須傳入
- Grpc使用Protobuf來作為其序列化的底層框架，而Protobuf對于任何一個數(shù)據(jù)對象的序列化必須要有一個單例的DEFAULT_INSTANCE，這個是他獲取序列化,這個是Protobuf的真正的弊端，估計有人說這個無所謂，但是如果要實現(xiàn)Api gateway，這種弊端就體現(xiàn)出來了，我們知道任何一個數(shù)據(jù)對象都能以元數(shù)據(jù)的方式來傳入動態(tài)的把這個元數(shù)據(jù)進行序列化，而Grpc無法做到這點，這也導致現(xiàn)在Grpc的gateway必須是依據(jù)Proto的定義改變而改變，也就是Proto定義改變了，gateway必須重啟，這種體驗是無法忍受的
服務契約的不友好性
Java走到服務化這一步，其interface大行其道，像現(xiàn)在主流的Rpc框架中許多都是使用java的接口來做為服務契約，這種方式還是比較根深蒂固的，但是Grpc不是如此，利用protobuf生成的stub存根，可讀性實在是太差了，想要真正的了解序列化邏輯實在是太麻煩了基于流方式的傳輸?shù)膹碗s性
Grpc可以基于streaming流的方式來進行數(shù)據(jù)傳輸，這是啥意思呢，也就是我傳了多少數(shù)據(jù)給服務端，我先告訴你，服務端拿到之后，再去把數(shù)據(jù)反序列化出來，理想很豐滿，現(xiàn)實很骨感，這個通知，Grpc是咋做的呢，其服務定義必須要有一個這樣顯式的定義接口，通過這個接口來定義這種流式的傳輸，這種對Idl的無關(guān)定義侵入讓人很不舒服
Grpc的優(yōu)點
談了談Grpc的缺點，我來說說優(yōu)點吧
多語言
Grpc的多語言是他做的很牛逼的地方，特別是在設備端，客戶端支持ios，android，而基于http2.0的多路復用也的確讓設備真正的省了流量，省了電，也省了空間基于Http2.0
采用HTTP2的好處在于,因為添加了頭信息,可以方便在框架層面對調(diào)用做攔截和控制(比如說限流,調(diào)用鏈分析,安全認證等)而且http2為標準協(xié)議,也方便以后擴展兼容其它調(diào)用端
暫時就談這么多，最后打一個廣告
<a > 傳送門</a>
這個是基于grpc的擴展，能夠進行注冊，發(fā)現(xiàn)，并且初步的解決了數(shù)據(jù)對象不友好性
