gRPC-rs：從 C 到 Rust

01-27

在上篇文章中，我們講到 TiKV 為了支持 gRPC，我們造了個輪子 gRPC-rs，這篇文章簡要地介紹一下這個庫。首先我們來聊聊什麼是 gRPC。gRPC 是 Google 推出的基於 HTTP2 的開源 RPC 框架，希望通過它使得各種微服務之間擁有統一的 RPC 基礎設施。它不僅支持常規的平台如 Linux，Windows，還支持移動設備和 IoT，現有十幾種語言的實現，現在又多了一種語言 Rust。

gRPC 之所以有如此多的語言支持，是因為它有一個 C 寫的核心庫(gRPC core)，因此只要某個語言兼容 C ABI，那麼就可以通過封裝，寫一個該語言的 gRPC 庫。Rust 對 C 有良好的支持，gRPC-rs 就是對 gRPC core ABI 的 Rust 封裝。

Core 能非同步處理 RPC 請求，在考慮到 Rust 中已有較為成熟的非同步框架 Futures，我們決定將 API 設計成 Future 模式。

gRPC-rs 架構圖

我們將根據架構圖從底向上地講一下，在上一篇文章中已經討論過傳輸層和協議，在這就不再贅述。

gRPC Core

Core 中有幾個比較重要的對象：

Call 以及 4 種類型 RPC： Call 代表了一次 RPC，可以派生出四種類型 RPC，

Unary：這是最簡單的一種 RPC 模式，即一問一答，客戶端發送一個請求，服務端返回一個回復，該輪 RPC 結束。
Client streaming：這類的 RPC 會創建一個客戶端到服務端的流，客戶端可以通過這個流，向服務端發送多個請求，而服務端只會返回一個回復。
Server streaming：與上面的類似，不過它會創建一個服務端到客戶端的流，服務端可以發送多個回復，
Bidirectional streaming：如果說上面兩類是單工，那麼這類就是雙工了，客戶端和服務端可以同時向對方發送消息。

值得一提的是由於 gRPC 基於 HTTP2，它利用了 HTTP2 多路復用特性，使得一個 TCP 連接上可以同時進行多個 RPC，一次 RPC 即為 HTTP2 中的一個 Stream。

Channel：它是對底層鏈接的抽象，具體來說一個 Channel 就是一條連著遠程伺服器的 TCP 鏈接。
Server：顧名思義，它就是 gRPC 服務端封裝，可以在上面註冊我們的服務。
Completion queue: 它是 gRPC 完成事件隊列，事件可以是收到新的回復，可以是新來的請求。

簡要介紹一下 Core 庫的實現，Core 中有一個 Combiner 的概念，Combiner 中一個函數指針或稱組合子（Combinator）隊列。每個組合子都有特定的功能，通過不同的組合可以實現不同的功能。下面的偽碼大概說明了 Combiner 的工作方式。

Combiner 裡面有一個 mpsc 的無鎖隊列 q，由於 q 只能有一個消費者，這就要求在同一時刻只能有一個線程去調用隊列裡面的各個函數。調用的入口是 run() 方法，在 run() 中各個函數會被序列地執行。當取完 q 時，該輪調用結束。假設一次 RPC 由六個函數組成，這樣的設計使這組函數（RPC）可以在不同的線程上運行，這是非同步化 RPC 的基礎。

Completion queue（以下簡稱 CQ）就是一個 Combiner，它暴露出了一個 next()借口，相當於 Combiner 的 run()。由於介面的簡單，Core 內部不用開啟額外線程，只要通過外部不斷調用 next() 就能驅動整個 Core。

所有的 HTTP2 處理，Client 的 RPC 請求和 Server 的 RPC 連接全是通過一個個組合子的不同組合而構成的。下面是一次 Unary 的代碼。它由6個組合子組成，這些組合子作為一個 batch 再加上 Call 用於記錄狀態，兩者構成了這次的 RPC。

用 Rust 封裝 Core

介紹完 Core，現在說一下如何用 Rust 封裝它。這一層封裝並不會產生額外的開銷，不像有的語言在調用 C 時會有類型的轉換或者 runtime 會有較大開銷，在 Rust 中開銷微乎其微，這得益於 Rust 用 llvm 做編譯器後端，它對 C 有良好的支持，Rust 調用 C ABI 就像調用一個普通的函數，可以做到 Zero-cost。

同時用 Rust 封裝 C ABI 是一件很簡單的事情，簡單到像黑魔法。比如封裝 CQ next():

C：

Rust：

接著我們看看如何封裝 C 的類型。繼續以 next() 為例子：

C：

Rust：

CQ 在 Core 的 ABI 中傳遞的形式是指針，Rust Wraper 無須知道 CQ 具體的內部結構。對於這種情況，Rust 推薦用無成員的枚舉體表示，具體好處有兩個，第一，由於沒有成員，我們無法在 Rust 中構建該枚舉體的實例，第二，Type safe，當傳遞了一個錯誤類型的指針時編譯器會報錯。

#[repr(C)] 也是 Rust 的黑魔法之一。加上了這個標籤的結構體，在內存中的布局和對齊就和 C 一樣了，這樣的結構體可以安全地傳遞給 C ABI。

Futures in gRPC-rs

經過上一節的封裝，我們已經得到了一個可用但是非常裸的 Rust gRPC 庫了，grpc-sys。在實踐中，我們不推薦直接用 grpc-sys，直接用它就像在 Rust 中寫 C 一樣，事倍功半，Rust 語言的諸多特性無法得到施展，例如泛型，Trait，Ownership 等，也無法融入 Rust 社區。

上面說過 Core 能非同步處理 RPC，那麼如何用 Rust 來做更好的封裝呢？ Futures！它是一個成熟的非同步編程庫，同時有一個活躍的社區。 Futures 非常適用於 RPC 等一些 IO 操作頻繁的場景。Futures 中也有組合子概念，和 Core 中的類似，但是使用上更加方便，也更加好理解。舉一個栗子：

你覺得輸出的答案是多少呢？沒錯就是 42。在 Core 那節說過不同的組合子組織在一起可以干不同的事，在 Future 中我們可以這麼理解，一件事可以分成多個步驟，每個步驟由一個組合子完成。比如上例，map 完成了翻倍的動作，and_then 將輸入加上 40。現在來看看 gRPC-rs 封裝的 API。

以 helloworld.proto 為例，GreeterClient::say_hello_async() 向遠程 Server 發送一個請求 (HelloRequest)，Server 返回給一個結果 (HelloReply)。由於是非同步操作，這個函數會立即返回，返回的 ClientUnaryReceiver 實現了 Future，當它完成時就會得到 HelloReply。在一般的非同步編程中都會有 Callback，用於處理非同步的返回值，在這個 RPC 中就是 HelloReply，在 Future 中可以用組合子來寫，比如 and_then，再舉一個栗子，現有一次完整的 RPC 邏輯，拿到回復後列印到日誌。下面就是 gRPC-rs 的具體用法。

Unary RPC

gRPC-rs 根據 service 在 proto 文件中的定義生成對應的代碼，包括 RPC 方法的定義（Method）、客戶端和服務端代碼，生成的代碼中會使用 gRPC-rs 的 API。那麼具體是怎麼做的呢？這節還是以 helloworld.proto 為例，來講講客戶端 Unary RPC 具體的實現。首先，SayHello 的 Method 記錄了 RPC 類型，全稱以及序列化反序列化函數。為什麼要序列化反序列化函數呢？因為 Core 本身不涉及消息的序列化，這一部分交由封裝層解決。在生成的客戶端中可以會調用 gRPC-rs 的 API，根據 Method 的定義發起 RPC。

寫在最後

這篇簡單介紹了 gRPC Core 的實現和 gRPC-rs 的封裝，詳細的用法，在這就不做過多介紹了，大家如果感興趣可以查看 examples。 gRPC-rs 深入使用了 Future，裡面有很多神奇的用法，比如 Futures in gRPC-rs 那節最後的 executer， gRPC-rs 利用 CQ 實現了一個能並發執行 Future 的 executer（類似 furtures-rs 中的 Executer），大幅減少 context switch，性能得到了顯著提升。如果你對 gRPC 和 rust 都很感興趣，歡迎參與開發，目前還有一些工作沒完成，詳情請點擊 https://github.com/pingcap/grpc-rs

參考資料：

gRPC open-source universal RPC framework

The rust language implementation of gRPC

Hypertext Transfer Protocol Version 2 (HTTP/2)

Zero-cost Futures in Rust

深入了解 gRPC：協議

gRPC, Combiner Explanation

Rust, Representing opaque structs

Rust repr(), alternative representations

gRPC - A solution for RPCs by Google

Tokio, A platform for writing fast networking code with Rust.

作者：沈泰寧