gRPC-rs：從 C 到 Rust
在上篇文章中，我們講到 TiKV 為了支持 gRPC，我們造了個輪子 gRPC-rs，這篇文章簡要地介紹一下這個庫。首先我們來聊聊什么是 gRPC。gRPC 是 Google 推出的基于 HTTP2 的開源 RPC 框架，希望通過它使得各種微服務(wù)之間擁有統(tǒng)一的 RPC 基礎(chǔ)設(shè)施。它不僅支持常規(guī)的平臺如 Linux，Windows，還支持移動設(shè)備和 IoT，現(xiàn)有十幾種語言的實現(xiàn)，現(xiàn)在又多了一種語言 Rust。
gRPC 之所以有如此多的語言支持，是因為它有一個 C 寫的核心庫(gRPC core)，因此只要某個語言兼容 C ABI，那么就可以通過封裝，寫一個該語言的 gRPC 庫。Rust 對 C 有良好的支持，gRPC-rs 就是對 gRPC core ABI 的 Rust 封裝。
Core 能異步處理 RPC 請求，在考慮到 Rust 中已有較為成熟的異步框架 Futures，我們決定將 API 設(shè)計成 Future 模式。
gRPC-rs 架構(gòu)圖
我們將根據(jù)架構(gòu)圖從底向上地講一下，在上一篇文章中已經(jīng)討論過傳輸層和協(xié)議，在這就不再贅述。
gRPC Core
Core 中有幾個比較重要的對象：
- Call 以及 4 種類型 RPC： Call 代表了一次 RPC，可以派生出四種類型 RPC，
- Unary： 這是最簡單的一種 RPC 模式，即一問一答，客戶端發(fā)送一個請求，服務(wù)端返回一個回復(fù)，該輪 RPC 結(jié)束。
- Client streaming： 這類的 RPC 會創(chuàng)建一個客戶端到服務(wù)端的流，客戶端可以通過這個流，向服務(wù)端發(fā)送多個請求，而服務(wù)端只會返回一個回復(fù)。
- Server streaming： 與上面的類似，不過它會創(chuàng)建一個服務(wù)端到客戶端的流，服務(wù)端可以發(fā)送多個回復(fù)，
- Bidirectional streaming： 如果說上面兩類是單工，那么這類就是雙工了，客戶端和服務(wù)端可以同時向?qū)Ψ桨l(fā)送消息。
值得一提的是由于 gRPC 基于 HTTP2，它利用了 HTTP2 多路復(fù)用特性，使得一個 TCP 連接上可以同時進行多個 RPC，一次 RPC 即為 HTTP2 中的一個 Stream。
- Channel： 它是對底層鏈接的抽象，具體來說一個 Channel 就是一條連著遠程服務(wù)器的 TCP 鏈接。
- Server： 顧名思義，它就是 gRPC 服務(wù)端封裝，可以在上面注冊我們的服務(wù)。
- Completion queue: 它是 gRPC 完成事件隊列，事件可以是收到新的回復(fù)，可以是新來的請求。
簡要介紹一下 Core 庫的實現(xiàn)，Core 中有一個 Combiner 的概念，Combiner 中一個函數(shù)指針或稱組合子(Combinator)隊列。每個組合子都有特定的功能，通過不同的組合可以實現(xiàn)不同的功能。下面的偽碼大概說明了 Combiner 的工作方式。
Combiner 里面有一個 mpsc 的無鎖隊列 q，由于 q 只能有一個消費者，這就要求在同一時刻只能有一個線程去調(diào)用隊列里面的各個函數(shù)。調(diào)用的入口是 run() 方法，在 run() 中各個函數(shù)會被序列地執(zhí)行。當取完 q 時，該輪調(diào)用結(jié)束。假設(shè)一次 RPC 由六個函數(shù)組成，這樣的設(shè)計使這組函數(shù)(RPC)可以在不同的線程上運行，這是異步化 RPC 的基礎(chǔ)。
Completion queue(以下簡稱 CQ)就是一個 Combiner，它暴露出了一個 next()借口，相當于 Combiner 的 run()。由于接口的簡單，Core 內(nèi)部不用開啟額外線程，只要通過外部不斷調(diào)用 next() 就能驅(qū)動整個 Core。
所有的 HTTP2 處理，Client 的 RPC 請求和 Server 的 RPC 連接全是通過一個個組合子的不同組合而構(gòu)成的。下面是一次 Unary 的代碼。它由6個組合子組成，這些組合子作為一個 batch 再加上 Call 用于記錄狀態(tài)，兩者構(gòu)成了這次的 RPC。
用 Rust 封裝 Core
介紹完 Core，現(xiàn)在說一下如何用 Rust 封裝它。這一層封裝并不會產(chǎn)生額外的開銷，不像有的語言在調(diào)用 C 時會有類型的轉(zhuǎn)換或者 runtime 會有較大開銷，在 Rust 中開銷微乎其微，這得益于 Rust 用 llvm 做編譯器后端，它對 C 有良好的支持，Rust 調(diào)用 C ABI 就像調(diào)用一個普通的函數(shù)，可以做到 Zero-cost。
同時用 Rust 封裝 C ABI 是一件很簡單的事情，簡單到像黑魔法。比如封裝 CQ next():
C：
Rust：
接著我們看看如何封裝 C 的類型。繼續(xù)以 next() 為例子：
C：
Rust：
CQ 在 Core 的 ABI 中傳遞的形式是指針，Rust Wraper 無須知道 CQ 具體的內(nèi)部結(jié)構(gòu)。對于這種情況，Rust 推薦用無成員的枚舉體表示，具體好處有兩個，***，由于沒有成員，我們無法在 Rust 中構(gòu)建該枚舉體的實例，第二，Type safe，當傳遞了一個錯誤類型的指針時編譯器會報錯。
#[repr(C)] 也是 Rust 的黑魔法之一。加上了這個標簽的結(jié)構(gòu)體，在內(nèi)存中的布局和對齊就和 C 一樣了，這樣的結(jié)構(gòu)體可以安全地傳遞給 C ABI。
Futures in gRPC-rs
經(jīng)過上一節(jié)的封裝，我們已經(jīng)得到了一個可用但是非常裸的 Rust gRPC 庫了，grpc-sys。在實踐中，我們不推薦直接用 grpc-sys，直接用它就像在 Rust 中寫 C 一樣，事倍功半，Rust 語言的諸多特性無法得到施展，例如泛型，Trait，Ownership 等，也無法融入 Rust 社區(qū)。
上面說過 Core 能異步處理 RPC，那么如何用 Rust 來做更好的封裝呢? Futures!它是一個成熟的異步編程庫，同時有一個活躍的社區(qū)。 Futures 非常適用于 RPC 等一些 IO 操作頻繁的場景。Futures 中也有組合子概念，和 Core 中的類似，但是使用上更加方便，也更加好理解。舉一個栗子：
你覺得輸出的答案是多少呢?沒錯就是 42。在 Core 那節(jié)說過不同的組合子組織在一起可以干不同的事，在 Future 中我們可以這么理解，一件事可以分成多個步驟，每個步驟由一個組合子完成。比如上例，map 完成了翻倍的動作，and_then 將輸入加上 40。 現(xiàn)在來看看 gRPC-rs 封裝的 API。
以 helloworld.proto 為例，GreeterClient::say_hello_async() 向遠程 Server 發(fā)送一個請求 (HelloRequest)，Server 返回給一個結(jié)果 (HelloReply)。由于是異步操作，這個函數(shù)會立即返回，返回的 ClientUnaryReceiver 實現(xiàn)了 Future，當它完成時就會得到 HelloReply。在一般的異步編程中都會有 Callback，用于處理異步的返回值，在這個 RPC 中就是 HelloReply，在 Future 中可以用組合子來寫，比如 and_then，再舉一個栗子，現(xiàn)有一次完整的 RPC 邏輯，拿到回復(fù)后打印到日志。下面就是 gRPC-rs 的具體用法。
Unary RPC
gRPC-rs 根據(jù) service 在 proto 文件中的定義生成對應(yīng)的代碼，包括 RPC 方法的定義(Method)、客戶端和服務(wù)端代碼，生成的代碼中會使用 gRPC-rs 的 API。那么具體是怎么做的呢?這節(jié)還是以 helloworld.proto 為例，來講講客戶端 Unary RPC 具體的實現(xiàn)。首先，SayHello 的 Method 記錄了 RPC 類型，全稱以及序列化反序列化函數(shù)。為什么要序列化反序列化函數(shù)呢?因為 Core 本身不涉及消息的序列化，這一部分交由封裝層解決。在生成的客戶端中可以會調(diào)用 gRPC-rs 的 API，根據(jù) Method 的定義發(fā)起 RPC。
寫在***
這篇簡單介紹了 gRPC Core 的實現(xiàn)和 gRPC-rs 的封裝，詳細的用法，在這就不做過多介紹了，大家如果感興趣可以查看 examples。 gRPC-rs 深入使用了 Future，里面有很多神奇的用法，比如 Futures in gRPC-rs 那節(jié)***的 executer， gRPC-rs 利用 CQ 實現(xiàn)了一個能并發(fā)執(zhí)行 Future 的 executer(類似 furtures-rs 中的 Executer)，大幅減少 context switch，性能得到了顯著提升。
【本文是51CTO專欄機構(gòu)“PingCAP”的原創(chuàng)文章，轉(zhuǎn)載請聯(lián)系作者本人獲取授權(quán)】
