gRPC入門學習之旅（一）

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 協議，以其高性能和穩定性成為眾多開源項目提供數據的方案選項。