在上篇文章中，我們講到 TiKV 為了支持 gRPC，我們?cè)炝藗€(gè)輪子 gRPC-rs，這篇文章簡(jiǎn)要地介紹一下這個(gè)庫(kù)。首先我們來(lái)聊聊什么是 gRPC。gRPC 是 Google 推出的基于 HTTP2 的開(kāi)源 RPC 框架，希望通過(guò)它使得各種微服務(wù)之間擁有統(tǒng)一的 RPC 基礎(chǔ)設(shè)施。它不僅支持常規(guī)的平臺(tái)如 Linux，Windows，還支持移動(dòng)設(shè)備和 IoT，現(xiàn)有十幾種語(yǔ)言的實(shí)現(xiàn)，現(xiàn)在又多了一種語(yǔ)言 Rust。

gRPC 之所以有如此多的語(yǔ)言支持，是因?yàn)樗幸粋€(gè) C 寫(xiě)的核心庫(kù)(gRPC core)，因此只要某個(gè)語(yǔ)言兼容 C ABI，那么就可以通過(guò)封裝，寫(xiě)一個(gè)該語(yǔ)言的 gRPC 庫(kù)。Rust 對(duì) C 有良好的支持，gRPC-rs 就是對(duì) gRPC core ABI 的 Rust 封裝。

Core 能異步處理 RPC 請(qǐng)求，在考慮到 Rust 中已有較為成熟的異步框架 Futures，我們決定將 API 設(shè)計(jì)成 Future 模式。

gRPC-rs 架構(gòu)圖

我們將根據(jù)架構(gòu)圖從底向上地講一下，在上一篇文章中已經(jīng)討論過(guò)傳輸層和協(xié)議，在這就不再贅述。

gRPC Core

Core 中有幾個(gè)比較重要的對(duì)象：

• Call 以及 4 種類(lèi)型 RPC： Call 代表了一次 RPC，可以派生出四種類(lèi)型 RPC，
• Unary： 這是最簡(jiǎn)單的一種 RPC 模式，即一問(wèn)一答，客戶(hù)端發(fā)送一個(gè)請(qǐng)求，服務(wù)端返回一個(gè)回復(fù)，該輪 RPC 結(jié)束。
• Client streaming： 這類(lèi)的 RPC 會(huì)創(chuàng)建一個(gè)客戶(hù)端到服務(wù)端的流，客戶(hù)端可以通過(guò)這個(gè)流，向服務(wù)端發(fā)送多個(gè)請(qǐng)求，而服務(wù)端只會(huì)返回一個(gè)回復(fù)。
• Server streaming： 與上面的類(lèi)似，不過(guò)它會(huì)創(chuàng)建一個(gè)服務(wù)端到客戶(hù)端的流，服務(wù)端可以發(fā)送多個(gè)回復(fù)，
• Bidirectional streaming： 如果說(shuō)上面兩類(lèi)是單工，那么這類(lèi)就是雙工了，客戶(hù)端和服務(wù)端可以同時(shí)向?qū)Ψ桨l(fā)送消息。

值得一提的是由于 gRPC 基于 HTTP2，它利用了 HTTP2 多路復(fù)用特性，使得一個(gè) TCP 連接上可以同時(shí)進(jìn)行多個(gè) RPC，一次 RPC 即為 HTTP2 中的一個(gè) Stream。

• Channel： 它是對(duì)底層鏈接的抽象，具體來(lái)說(shuō)一個(gè) Channel 就是一條連著遠(yuǎn)程服務(wù)器的 TCP 鏈接。
• Server： 顧名思義，它就是 gRPC 服務(wù)端封裝，可以在上面注冊(cè)我們的服務(wù)。
• Completion queue: 它是 gRPC 完成事件隊(duì)列，事件可以是收到新的回復(fù)，可以是新來(lái)的請(qǐng)求。

簡(jiǎn)要介紹一下 Core 庫(kù)的實(shí)現(xiàn)，Core 中有一個(gè) Combiner 的概念，Combiner 中一個(gè)函數(shù)指針或稱(chēng)組合子(Combinator)隊(duì)列。每個(gè)組合子都有特定的功能，通過(guò)不同的組合可以實(shí)現(xiàn)不同的功能。下面的偽碼大概說(shuō)明了 Combiner 的工作方式。

Combiner 里面有一個(gè) mpsc 的無(wú)鎖隊(duì)列 q，由于 q 只能有一個(gè)消費(fèi)者，這就要求在同一時(shí)刻只能有一個(gè)線(xiàn)程去調(diào)用隊(duì)列里面的各個(gè)函數(shù)。調(diào)用的入口是 run() 方法，在 run() 中各個(gè)函數(shù)會(huì)被序列地執(zhí)行。當(dāng)取完 q 時(shí)，該輪調(diào)用結(jié)束。假設(shè)一次 RPC 由六個(gè)函數(shù)組成，這樣的設(shè)計(jì)使這組函數(shù)(RPC)可以在不同的線(xiàn)程上運(yùn)行，這是異步化 RPC 的基礎(chǔ)。

Completion queue(以下簡(jiǎn)稱(chēng) CQ)就是一個(gè) Combiner，它暴露出了一個(gè) next()借口，相當(dāng)于 Combiner 的 run()。由于接口的簡(jiǎn)單，Core 內(nèi)部不用開(kāi)啟額外線(xiàn)程，只要通過(guò)外部不斷調(diào)用 next() 就能驅(qū)動(dòng)整個(gè) Core。

所有的 HTTP2 處理，Client 的 RPC 請(qǐng)求和 Server 的 RPC 連接全是通過(guò)一個(gè)個(gè)組合子的不同組合而構(gòu)成的。下面是一次 Unary 的代碼。它由6個(gè)組合子組成，這些組合子作為一個(gè) batch 再加上 Call 用于記錄狀態(tài)，兩者構(gòu)成了這次的 RPC。

用 Rust 封裝 Core

介紹完 Core，現(xiàn)在說(shuō)一下如何用 Rust 封裝它。這一層封裝并不會(huì)產(chǎn)生額外的開(kāi)銷(xiāo)，不像有的語(yǔ)言在調(diào)用 C 時(shí)會(huì)有類(lèi)型的轉(zhuǎn)換或者 runtime 會(huì)有較大開(kāi)銷(xiāo)，在 Rust 中開(kāi)銷(xiāo)微乎其微，這得益于 Rust 用 llvm 做編譯器后端，它對(duì) C 有良好的支持，Rust 調(diào)用 C ABI 就像調(diào)用一個(gè)普通的函數(shù)，可以做到 Zero-cost。

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

C：

Rust：

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

C：

Rust：

CQ 在 Core 的 ABI 中傳遞的形式是指針，Rust Wraper 無(wú)須知道 CQ 具體的內(nèi)部結(jié)構(gòu)。對(duì)于這種情況，Rust 推薦用無(wú)成員的枚舉體表示，具體好處有兩個(gè)，***，由于沒(méi)有成員，我們無(wú)法在 Rust 中構(gòu)建該枚舉體的實(shí)例，第二，Type safe，當(dāng)傳遞了一個(gè)錯(cuò)誤類(lèi)型的指針時(shí)編譯器會(huì)報(bào)錯(cuò)。

#[repr(C)] 也是 Rust 的黑魔法之一。加上了這個(gè)標(biāo)簽的結(jié)構(gòu)體，在內(nèi)存中的布局和對(duì)齊就和 C 一樣了，這樣的結(jié)構(gòu)體可以安全地傳遞給 C ABI。

Futures in gRPC-rs

經(jīng)過(guò)上一節(jié)的封裝，我們已經(jīng)得到了一個(gè)可用但是非常裸的 Rust gRPC 庫(kù)了，grpc-sys。在實(shí)踐中，我們不推薦直接用 grpc-sys，直接用它就像在 Rust 中寫(xiě) C 一樣，事倍功半，Rust 語(yǔ)言的諸多特性無(wú)法得到施展，例如泛型，Trait，Ownership 等，也無(wú)法融入 Rust 社區(qū)。

上面說(shuō)過(guò) Core 能異步處理 RPC，那么如何用 Rust 來(lái)做更好的封裝呢? Futures!它是一個(gè)成熟的異步編程庫(kù)，同時(shí)有一個(gè)活躍的社區(qū)。 Futures 非常適用于 RPC 等一些 IO 操作頻繁的場(chǎng)景。Futures 中也有組合子概念，和 Core 中的類(lèi)似，但是使用上更加方便，也更加好理解。舉一個(gè)栗子：

你覺(jué)得輸出的答案是多少呢?沒(méi)錯(cuò)就是 42。在 Core 那節(jié)說(shuō)過(guò)不同的組合子組織在一起可以干不同的事，在 Future 中我們可以這么理解，一件事可以分成多個(gè)步驟，每個(gè)步驟由一個(gè)組合子完成。比如上例，map 完成了翻倍的動(dòng)作，and_then 將輸入加上 40。 現(xiàn)在來(lái)看看 gRPC-rs 封裝的 API。

以 helloworld.proto 為例，GreeterClient::say_hello_async() 向遠(yuǎn)程 Server 發(fā)送一個(gè)請(qǐng)求 (HelloRequest)，Server 返回給一個(gè)結(jié)果 (HelloReply)。由于是異步操作，這個(gè)函數(shù)會(huì)立即返回，返回的 ClientUnaryReceiver 實(shí)現(xiàn)了 Future，當(dāng)它完成時(shí)就會(huì)得到 HelloReply。在一般的異步編程中都會(huì)有 Callback，用于處理異步的返回值，在這個(gè) RPC 中就是 HelloReply，在 Future 中可以用組合子來(lái)寫(xiě)，比如 and_then，再舉一個(gè)栗子，現(xiàn)有一次完整的 RPC 邏輯，拿到回復(fù)后打印到日志。下面就是 gRPC-rs 的具體用法。

Unary RPC

gRPC-rs 根據(jù) service 在 proto 文件中的定義生成對(duì)應(yīng)的代碼，包括 RPC 方法的定義(Method)、客戶(hù)端和服務(wù)端代碼，生成的代碼中會(huì)使用 gRPC-rs 的 API。那么具體是怎么做的呢?這節(jié)還是以 helloworld.proto 為例，來(lái)講講客戶(hù)端 Unary RPC 具體的實(shí)現(xiàn)。首先，SayHello 的 Method 記錄了 RPC 類(lèi)型，全稱(chēng)以及序列化反序列化函數(shù)。為什么要序列化反序列化函數(shù)呢?因?yàn)?Core 本身不涉及消息的序列化，這一部分交由封裝層解決。在生成的客戶(hù)端中可以會(huì)調(diào)用 gRPC-rs 的 API，根據(jù) Method 的定義發(fā)起 RPC。

寫(xiě)在***

這篇簡(jiǎn)單介紹了 gRPC Core 的實(shí)現(xiàn)和 gRPC-rs 的封裝，詳細(xì)的用法，在這就不做過(guò)多介紹了，大家如果感興趣可以查看 examples。 gRPC-rs 深入使用了 Future，里面有很多神奇的用法，比如 Futures in gRPC-rs 那節(jié)***的 executer， gRPC-rs 利用 CQ 實(shí)現(xiàn)了一個(gè)能并發(fā)執(zhí)行 Future 的 executer(類(lèi)似 furtures-rs 中的 Executer)，大幅減少 context switch，性能得到了顯著提升。

【本文是51CTO專(zhuān)欄機(jī)構(gòu)“PingCAP”的原創(chuàng)文章，轉(zhuǎn)載請(qǐng)聯(lián)系作者本人獲取授權(quán)】

戳這里，看該作者更多好文