1.什么是gRPC
gRPC是rpc框架中的一種，是rpc中的大哥。是一個高性能，開源和通用的RPC框架，基于Protobuf序列化協議開發，且支持眾多開發語言。

<i id='0FKct'></i>

面向服務端和協議端，基于http/2設計，帶來諸如雙向流，流控，頭部壓縮，單TCP連接上的多路復用請求等特性。這些特性使得其在移動設備上表現的更好，更省電和節省空間。

在gPRC里客戶端可以向調用本地對象一樣直接調用另一臺不同機器上服務端應用的方法，使得您能夠更容易地創建分布式應用和服務。

與許多RPC系統類似，gRPC也是基于以下理念：定義一個服務，指定其能夠被遠程調用的方法（包含參數和返回類型）。在服務端實現這個接口。并運行一個gRPC服務器來處理客戶端調用。在客戶端擁有一個存根能夠向服務端一樣的方法。

補充一個知識點（HTTP/2 與HTTP1.X的區別）：用于數據傳輸的二進制分幀。

HTTP/2采用二進制格式傳輸協議，而非HTTP/1.x的文本格式。

多路復用

HTTP/2支持通過同一個連接發送多個并發的請求。

而HTTP/1.x雖然通過pipeline也能并發請求，但多個請求之間的響應依然會被阻塞。

服務端推送

服務端推送是一種在客戶端請求之前發送數據的機制。在HTTP/2中，服務器可以對客戶端的一個請求發送多個響應。而不像HTTP/1.X一樣，只能通過客戶端發起request,服務端才產生對應的response。

減少網絡流量的頭部壓縮。

HTTP/2對消息頭進行了壓縮傳輸，能夠節省消息頭占用的網絡流量。至于如何壓縮的，可以查看這篇：HPACK: Header Compression for HTTP/2[1]

2.gRPC大致請求流程
1.客戶端(gRPC Stub)調用A方法，發起RPC調用；

2.對請求信息使用Protobuf進行對象序列化壓縮（IDL）；

3.服務端（gPRC Server)接收到請求后，解碼請求體，進行業務邏輯處理并返回；

4.對響應結果使用Protobuf進行對象序列化壓縮（IDL）；

5.客戶端接受到服務端響應，解碼請求體。回調被調用的A方法，喚醒正在等待響應（阻塞）的客戶端調用并返回響應結果。

3.gRPC的優勢
性能
gRPC消息使用一種有效的二進制消息格式protobuf繼續寧序列化。Protobuf在服務器和客戶機上的序列化非常快。Protobuf序列化之后的消息體積很小，能夠有效負載，在移動應用程序等有限寬帶場景中顯得很重要。與采用文本格式的json相比，采用二進制格式的protobuf在速度上可以達到前者的5倍。

代碼生成
所有gRPC框架都為代碼生成提供了一流的支持。gRPC的開發核心是*.proto文件，它定義了gRPC服務和消息的約定。根據這個文件，gRP框架將生成服務基類，消息和完整的客戶端代碼。

通過在服務器和客戶端之間共享*.proto文件，可以從端到端生成消息和客戶端代碼。客戶端的代碼生成消除了客戶端和服務器上的重復消息，并為您創建了一個強類型的客戶端。無需編寫客戶端代碼，可在具有許多服務和應用程序中節省大量開發時間。

嚴格的規范
不存在具有JSON的HTTP API的正事規范。開發人員不需要討論URL，HTTP動詞和響應代碼的最佳格式。（不需要考慮用post還是get，get還是put)，該gRPC規范是規定有關gPRC服務必須遵循的格式。gRPC消除了爭論并節省了開發人員的時間，因為gRPC在各個平臺上和實現之間是一致的。

流
gRPC服務支持所有流組合：

一元（沒有媒體流）：最簡單的rpc調用，一個請求對象對應一個返回對象。客戶端發起一次請求客戶端相應一個數據，即標準的RPC通信。

服務器到客戶端流：客戶端流式rpc客戶端傳入多個請求對象。服務端返回一個響應結果。應用場景：物聯網終端向服務器報送數據。

客戶端到服務器流：服務端流式rpc一個請求對象，服務端可以傳回多個結果對象。服務端流PRC下，客戶端發出一個請求，但不會立即得到一個響應，而是在服務器與客戶端之間建立一個單向的流，不斷獲取響應直到流關閉。應用場景舉例：典型的例子是客戶端向服務端發送一個股票代碼，服務端就把該股票的實時數據源源不斷的返回客戶端。

雙向流媒體：雙向流式RPC結合客戶端流式RPC和服務端流式RPC，可以傳入多個對象，返回多個響應對象。

應用場景：聊天應用。

截至時間/超時和取消
gRPC允許客戶端指定他們愿意等待RPC完成時間。該期限被發送到服務端，服務端可以決定在超出了期限時采取什么行動，例如，服務器可能會在超時時取消正在進行的gPRC/HTTP/數據庫請求。通過子gRPC調用截至時間和取消操作有助于實施資源使用限制。

4.gRPC的劣勢
瀏覽器支持有限

當下，不能從瀏覽器調用gRPC服務 ,gRPC Web是gRPC團隊的一項附加技術，它在瀏覽器中提供有限的gRPC支持。gRPC Web由兩部分組成：支持所有現代瀏覽器的JavaScript客戶端和服務器上的gRPC Web代理。gRPC Web客戶端調用代理，代理將在gRPC請求上轉發到gRPC服務器。

gRPC Web并非支持所有gRPC功能。不支持客戶端和雙向流，并且對服務器流的支持有限。

不是人類可讀的
HTTP API請求以文本形式發送，可以由人讀取和創建。

默認情況下，gRPC消息使用protobuf編碼。雖然protobuf的發送和接收效率很高，但它的二進制格式是不可讀的。protobuf需要在.proto文件中指定的消息接口描述才能正確反序列化。需要額外的工具來分析線路上的Protobuf有效負載，并手工編寫請求。

存在諸如服務器反射和gRPC命令行工具等功能，以幫助處理二進制protobuf消息。另外，Protobuf消息支持與JSON之間的轉換。內置的JSON轉換提供了一種有效的方法，可以在調試時將Protobuf消息轉換為可讀的形式。

5.使用場景
建議使用的場景：

微服務：gRPC設計為低延遲和高吞吐量通信，非常適用效率至關重要的輕型微服務；

點對點實時通信：gRPC可以實時推送消息而無需輪詢；

多語言混合開發環境：支持所有流行開發語言；

網絡受限環境：使用Protobuf(一種輕量級消息格式)序列化gRPC消息。gRPC消息始終小于等效的JSON消息。

不建議使用場景：

瀏覽器可訪問的API：瀏覽器不支持gRPC,gRPC-Web有局限性而且還引入了服務器代理

廣播實時通信

進程間通信