gRpc簡介
gRPC 是Google公司開發的基於HTTP/2設計，面向移動的一個高性能、開源和通用的 RPC 框架，是一款語言中立、平臺中立、開源的遠程過程調用(RPC)系統。
gRpc官網地址：https://www.grpc.io
gRpc中文文檔地址：http://doc.oschina.net/grpc
gRPC是一款RPC框架，那麼先了解Rpc是什麼。
Rpc基本概念
RPC（Remote Procedure Call）遠程過程調用，是一種通過網絡從遠程計算機程序上請求服務，而不需要了解底層網絡技術的協議，簡單的理解是一個節點請求另一個節點提供的服務。RPC只是一套協議，基於這套協議規範來實現的框架都可以稱爲 RPC 框架，比較典型的有 Dubbo、Thrift 和 gRPC。
RPC 機制和實現過程
RPC 是遠程過程調用的方式之一，涉及調用方和被調用方兩個進程的交互。因爲 RPC 提供類似於本地方法調用的形式，所以對於調用方來說，調用 RPC 方法和調用本地方法並沒有明顯區別。
RPC的機制的誕生和基礎概念
1984 年，Birrell 和 Nelson 在 ACM Transactions on Computer
Systems 期刊上發表了名爲“Implementing remote procedure calls”的論文，該文對 RPC 的機制做了經典的詮釋：
RPC 遠程過程調用是指計算機 A 上的進程，調用另外一臺計算機 B 上的進程的方法。其中A 上面的調用進程被掛起，而 B 上面的被調用進程開始執行對應方法，並將結果返回給 A，計算機 A 接收到返回值後，調用進程繼續執行。
發起 RPC 的進程通過參數等方式將信息傳送給被調用方，然後被調用方處理結束後，再通過返回值將信息傳遞給調用方。這一過程對於開發人員來說是透明的，開發人員一般也無須知道雙方底層是如何進行消息通信和信息傳遞的，這樣可以讓業務開發人員更專注於業務開發，而非底層細節。
RPC 讓程序之間的遠程過程調用具有與本地調用類似的形式。比如說某個程序需要讀取某個文件的數據，開發人員會在代碼中執行 read 系統調用來獲取數據。
當 read 實際是本地調用時，read 函數由鏈接器從依賴庫中提取出來，接着鏈接器會將它鏈接到該程序中。雖然 read 中執行了特殊的系統調用，但它本身依然是通過將參數壓入堆棧的常規方式調用的，調用方並不知道 read 函數的具體實現和行爲。
當 read 實際是一個遠程過程時（比如調用遠程文件服務器提供的方法），調用方程序中需要引入 read 的接口定義，稱爲客戶端存根（client-stub）。遠程過程 read 的客戶端存根與本地方法的 read 函數類似，都執行了本地函數調用。不同的是它底層實現上不是進行操作系統調用讀取本地文件來提供數據，而是將參數打包成網絡消息，並將此網絡消息發送到遠程服務器，交由遠程服務執行對應的方法，在發送完調用請求後，客戶端存根隨即阻塞，直到收到服務器發回的響應消息爲止。
下圖展示了遠程方法調用過程中的客戶端和服務端各個階段的操作。
RPC 示意圖
當客戶端發送請求的網絡消息到達服務器時，服務器上的網絡服務將其傳遞給服務器存根（server-stub）。服務器存根與客戶端存根一一對應，是遠程方法在服務端的體現，用來將網絡請求傳遞來的數據轉換爲本地過程調用。服務器存根一般處於阻塞狀態，等待消息輸入。
當服務器存根收到網絡消息後，服務器將方法參數從網絡消息中提取出來，然後以常規方式調用服務器上對應的實現過程。從實現過程角度看，就好像是由客戶端直接調用一樣，參數和返回地址都位於調用堆棧中，一切都很正常。實現過程執行完相應的操作，隨後用得到的結果設置到堆棧中的返回值，並根據返回地址執行方法結束操作。以 read 爲例，實現過程讀取本地文件數據後，將其填充到 read 函數返回值所指向的緩衝區。
read 過程調用完後，實現過程將控制權轉移給服務器存根，它將結果（緩衝區的數據）打包爲網絡消息，最後通過網絡響應將結果返回給客戶端。網絡響應發送結束後，服務器存根會再次進入阻塞狀態，等待下一個輸入的請求。
客戶端接收到網絡消息後，客戶操作系統會將該消息轉發給對應的客戶端存根，隨後解除對客戶進程的阻塞。客戶端存根從阻塞狀態恢復過來，將接收到的網絡消息轉換爲調用結果，並將結果複製到客戶端調用堆棧的返回結果中。當調用者在遠程方法調用 read 執行完畢後重新獲得控制權時，它唯一知道的是 read 返回值已經包含了所需的數據，但並不知道該 read 操作到底是在本地操作系統讀取的文件數據，還是通過遠程過程調用遠端服務讀取文件數據。
總結下RPC執行步驟：
1. 調用客戶端句柄，執行傳遞參數。
2. 調用本地系統內核發送網絡消息。
3. 消息傳遞到遠程主機，就是被調用的服務端。
4. 服務端句柄得到消息並解析消息。
5. 服務端執行被調用方法，並將執行完畢的結果返回給服務器句柄。
6. 服務器句柄返回結果，並調用遠程系統內核。
7. 消息經過網絡傳遞給客戶端。
8. 客戶端接受數據。
RPC框架的組成
一個完整的 RPC 框架包含了服務註冊發現、負載、容錯、序列化、協議編碼和網絡傳輸等組件。不同的 RPC 框架包含的組件可能會有所不同，但是一定都包含 RPC 協議相關的組件，RPC 協議包括序列化、協議編解碼器和網絡傳輸棧，如下圖所示：
RPC 協議一般分爲公有協議和私有協議。例如，HTTP、SMPP、WebService
等都是公有協議。如果是某個公司或者組織內部自定義、自己使用的，沒有被國際標準化組織接納和認可的協議，往往劃爲私有協議，例如 Thrift 協議和螞蟻金服的 Bolt 協議。
分佈式架構所需要的企業內部通信模塊，往往採用私有協議來設計和研發。相較公有協議，私有協議雖然有很多弊端，比如在通用性上、公網傳輸的能力上，但是高度定製化的私有協議可以最大限度地降低成本，提升性能，提高靈活性與效率。定製私有協議，可以有效地利用協議裏的各個字段，靈活滿足各種通信功能需求，比如：CRC 校驗、Server Fail-Fast 機制和自定義序列化器。
在協議設計上，你還需要考慮以下三個關鍵問題：
1. 協議包括的必要字段與主要業務負載字段。協議裏設計的每個字段都應該被使用到，避免無效字段。
2. 通信功能特性的支持。比如，CRC 校驗、安全校驗、數據壓縮機制等。
3. 協議的升級機制。畢竟是私有協議，沒有長期的驗證，字段新增或者修改，是有可能發生的，因此升級機制是必須考慮的。
RPC和HTTP區別
RPC 和 HTTP都是微服務間通信較爲常用的方案之一，其實RPC 和 HTTP 並不完全是同一個層次的概念，它們之間還是有所區別的。
1. RPC 是遠程過程調用，其調用協議通常包括序列化協議和傳輸協議。序列化協議有基於純文本的 XML 和 JSON、二進制編碼的Protobuf和Hessian。傳輸協議是指其底層網絡傳輸所使用的協議，比如 TCP、HTTP。
2. 可以看出HTTP是RPC的傳輸協議的一個可選方案，比如說 gRPC 的網絡傳輸協議就是 HTTP。HTTP 既可以和 RPC 一樣作爲服務間通信的解決方案，也可以作爲 RPC 中通信層的傳輸協議（此時與之對比的是 TCP 協議）。
常見的 RPC 框架
目前流行的開源 RPC 框架還是比較多的，有阿里巴巴的
Dubbo、Google 的 gRPC、Facebook 的 Thrift 和
Twitter 的 Finagle 等。
1. Go RPC：Go 語言原生支持的 RPC 遠程調用機制，簡單便捷。
2. gRPC：Google 發佈的開源 RPC 框架，是基於 HTTP 2.0 協議的，並支持衆多常見的編程語言，它提供了強大的流式調用能力，目前已經成爲最主流的 RPC 框架之一。
3. Thrift：Facebook 的開源 RPC 框架，主要是一個跨語言的服務開發框架，作爲老牌開源 RPC 協議，以其高性能和穩定性成爲衆多開源項目提供數據的方案選項。