編輯 | 言征

出品 | 51CTO技術(shù)棧（微信號(hào)：blog51cto）

gRPC 是一種高性能 RPC 框架，它取得了巨大的成功，并且徹底改變了我們部署 API 的方式。gRPC 和 protobuf 是一種性能極高的以契約為中心的框架，具有極其廣泛的語(yǔ)言支持。但它并非沒(méi)有缺點(diǎn)。制作一個(gè)需要代碼生成和多種編程語(yǔ)言支持的 RPC 框架肯定會(huì)出錯(cuò)。隨著 gRPC 的使用時(shí)間接近十年，反思哪些方面可以做得更好是很重要的。

1.學(xué)習(xí)曲線

讓我們從極其挑剔開(kāi)始。所謂的一元 RPC 是指客戶端向服務(wù)器發(fā)送單個(gè)請(qǐng)求并收到單個(gè)響應(yīng)的調(diào)用。為什么 gRPC 必須使用這樣一個(gè)只有數(shù)學(xué)家才直觀理解的非標(biāo)準(zhǔn)術(shù)語(yǔ)來(lái)表示這一點(diǎn)？每次使用這個(gè)術(shù)語(yǔ)時(shí)，我都必須解釋一下。我有點(diǎn)厭倦了。

說(shuō)到一元 RPC，其實(shí)現(xiàn)比它需要的更復(fù)雜。雖然 gRPC 的流式傳輸功能很強(qiáng)大，但它們?yōu)椴恍枰魇絺鬏數(shù)暮?jiǎn)單 RPC 調(diào)用引入了復(fù)雜性。這損害了檢查 gRPC 調(diào)用的能力，因?yàn)楝F(xiàn)在每個(gè)一元 RPC 上都有框架，而這只對(duì)流式傳輸有意義。Protobuf 編碼已經(jīng)足夠復(fù)雜了，所以我們不要在不需要的地方添加額外的 gRPC 框架。此外，它沒(méi)有通過(guò)我對(duì)任何 Web API 的“向朋友發(fā)送 cURL 示例”測(cè)試。向某人解釋如何使用 gRPC 實(shí)在是太煩人了。我已經(jīng)說(shuō)過(guò)“好的，但是服務(wù)器反射啟用了嗎？”很多次了。我只是厭倦了。

這種復(fù)雜性還通過(guò)強(qiáng)制代碼生成步驟滲透到工具中。這可能是一個(gè)障礙，尤其是對(duì)于重視運(yùn)行時(shí)靈活性的動(dòng)態(tài)語(yǔ)言。此外，一些開(kāi)發(fā)人員可能不愿意采用需要額外構(gòu)建步驟的技術(shù)?，F(xiàn)代 Web 開(kāi)發(fā)已經(jīng)需要 20 個(gè)構(gòu)建步驟，有時(shí)很難再增加一個(gè)步驟。

圖片

2.與 Web 的兼容性

對(duì) HTTP/2 的依賴(lài)最初限制了 gRPC 的覆蓋范圍，因?yàn)椴⒎撬衅脚_(tái)和瀏覽器都完全支持它。這種情況隨著時(shí)間的推移有所改善，但在某些環(huán)境中仍然構(gòu)成挑戰(zhàn)。但即使有了 HTTP/2 支持，瀏覽器也避免添加處理 HTTP 尾部的方法，因此今天的瀏覽器仍然無(wú)法使用“原始” gRPC。gRPC-Web 通過(guò)避免使用尾部充當(dāng)了這個(gè)問(wèn)題的膏藥，但它通常需要“額外的東西”，比如運(yùn)行支持 gRPC-Web 的代理。這很煩人。

HTTP/3 的采用較晚：HTTP/3 的采用延遲可能阻礙了 gRPC 充分利用該協(xié)議的性能和效率優(yōu)勢(shì)。我個(gè)人受到將 gRPC 與 HTTP/2 結(jié)合使用時(shí)可能發(fā)生的隊(duì)頭阻塞問(wèn)題的影響，如果能夠?qū)?HTTP/3 與 gRPC 結(jié)合使用，可以完全消除此問(wèn)題，那就太好了?？吹揭粋€(gè)推動(dòng)多種語(yǔ)言支持 HTTP/2 的框架在努力用 HTTP/3 做同樣的事情，真是奇怪。

3.JSON 映射和 Prototext

另一個(gè)“時(shí)機(jī)”不對(duì)的領(lǐng)域是早期缺乏標(biāo)準(zhǔn)化的 JSON 映射。這讓習(xí)慣于基于 JSON 的 API 的開(kāi)發(fā)人員更難使用 gRPC，而且我認(rèn)為它從未從這種污名中恢復(fù)過(guò)來(lái)。在 protobuf 類(lèi)型和 JSON 之間建立映射簡(jiǎn)化了與現(xiàn)有工具和系統(tǒng)的集成和互操作性。當(dāng)你說(shuō)“是的，這是一種超高效的二進(jìn)制格式……但如果你想調(diào)試，你可以設(shè)置這個(gè)標(biāo)志并取回 JSON”時(shí)，你不會(huì)相信 Web 開(kāi)發(fā)人員會(huì)有多高興。他們會(huì)興奮得不得了。太興奮了。無(wú)論如何，既然 protobuf 有了將 protobuf 類(lèi)型映射到 JSON（反之亦然）的標(biāo)準(zhǔn)規(guī)則，我覺(jué)得protobuf 文本格式是一種不必要的復(fù)雜性。既然有了 JSON，我看不到文本格式的用例。所以讓我們拋棄文本格式吧。我們不需要它，如果其他人都不需要它，我愿意假裝它從未存在過(guò)。很酷吧？

4.有限的消息大小

大多數(shù) Protobuf 編碼器/解碼器都希望完全解析整個(gè)消息并向消費(fèi)者提供完整的響應(yīng)，但內(nèi)存是有限的，有時(shí)您可能需要更大的消息。有時(shí)您希望將這些較大消息的部分流式傳輸?shù)狡渌胤?，而不是將整個(gè)消息保存在內(nèi)存中。因此，如果您想要上傳大文件，您將需要實(shí)現(xiàn)某種分塊。雖然分塊是處理大文件的合理解決方案，但 gRPC 中缺乏標(biāo)準(zhǔn)化方法可能會(huì)導(dǎo)致實(shí)現(xiàn)不一致并增加開(kāi)發(fā)工作量。

作為演示，使用 gRPC 上傳文件如下所示：

syntax = "proto3";

package file_service;


service FileService {
   rpc Upload(stream UploadRequest) returns(UploadResponse);
}


message UploadRequest {
    string file_name = 1;
    bytes chunk = 2;
}


message UploadResponse {
  string etag = 1;
}

5.協(xié)議緩沖區(qū)

這是 protobuf 的優(yōu)點(diǎn)，也是缺點(diǎn)。這個(gè)概念在 protobuf 中非常容易定義，但在實(shí)踐中，正確實(shí)現(xiàn)它的代碼可能很麻煩且容易出錯(cuò)。雖然 gRPC 的創(chuàng)建者 Google 已經(jīng)為他們的 API 找到了解決方案，但缺乏標(biāo)準(zhǔn)化方法使得其他人只能重新發(fā)明輪子。

你可能會(huì)想“Google 在其大多數(shù) API 中使用 gRPC，因此顯然他們已經(jīng)這樣做了”，您是對(duì)的。他們實(shí)際上有一個(gè)用于下載（可能很大的）文件的 gRPC 和 HTTP 版本。我們可以直接比較 gRPC 和 HTTP 版本，并且gRPC到目前為止要復(fù)雜得多。繼續(xù)比較鏈接的代碼。我會(huì)等待。

6.互聯(lián)網(wǎng)理論

我看到很多 gRPC/protobuf 社區(qū)都缺乏活動(dòng)。一些網(wǎng)站上缺乏可見(jiàn)的活動(dòng)可能會(huì)給人留下 gRPC 停滯不前或維護(hù)不積極的印象。這可能會(huì)阻礙潛在的采用者并導(dǎo)致社區(qū)增長(zhǎng)放緩。這可能是因?yàn)檫x擇太多，很難在 GitHub 問(wèn)題之外找到對(duì) gRPC 感興趣的人，因?yàn)檫@種熱情可能會(huì)被視為煩人。

7.糟糕的工具

很長(zhǎng)一段時(shí)間以來(lái)，當(dāng)我看到代碼庫(kù)使用 protobuf 時(shí)，我都會(huì)發(fā)現(xiàn)一個(gè)奇怪的腳本，它以超級(jí)自定義的方式下載隨機(jī)的 protobuf 文件并將它們放置在隨機(jī)路徑中，然后對(duì)進(jìn)行一系列超級(jí)復(fù)雜的調(diào)用protoc。只有谷歌會(huì)認(rèn)為不解決依賴(lài)管理就是解決依賴(lài)管理問(wèn)題的辦法。谷歌有自己非常谷歌式的管理依賴(lài)的方式，我們這些農(nóng)民只能夢(mèng)想著使用。

• 當(dāng)生活給你錘子時(shí)，就把它變成錘子吧。
• 它可以更好（而且確實(shí)更好）

雖然我一直批評(píng) gRPC，但我希望我的評(píng)論能起到建設(shè)性的作用。讀到本文末尾的人會(huì)知道，其中許多問(wèn)題已經(jīng)得到解決，或者至少正在得到解決！

一些 gRPC 實(shí)現(xiàn)已經(jīng)支持 HTTP/3。ConnectRPC 使得使用 HTTP/3 和 gRPC 變得非常容易（我將在以后的文章中繼續(xù)介紹這一點(diǎn)）。

由于protobuf 規(guī)范具有與 JSON 的規(guī)范映射，我不再需要擔(dān)心文本格式。我真的希望每個(gè)人都忘記它的存在。文本格式的空間有限。我不是開(kāi)玩笑。這是我最后一次承認(rèn)它的存在。

如果您知道該去哪里找，gRPC 社區(qū)實(shí)際上非常活躍。例如，buf slack對(duì)我來(lái)說(shuō)是一個(gè)很好的資源。您可能會(huì)發(fā)現(xiàn)我經(jīng)常在這里閑逛并回答問(wèn)題。

Buf CLI是一款出色的 gRPC 工具。它protoc不僅完全替代了 gRPC 的 linting、重大更改檢測(cè)、用于 gRPC 的 curl、與 Buf Schema Registry 的集成（哇，真正的依賴(lài)管理?。?，而且還添加了更多功能！此外，您熟悉和喜愛(ài)的 HTTP 工具也支持 gRPC，例如Postman、Insomnia和k6。

盡管 gRPC 取得了不可否認(rèn)的成功，但承認(rèn)該框架的缺點(diǎn)以確保其持續(xù)發(fā)展和改進(jìn)仍然很重要。通過(guò)解決其學(xué)習(xí)曲線、兼容性問(wèn)題、缺乏標(biāo)準(zhǔn)化和社區(qū)參與，我們可以釋放 gRPC 的全部潛力，使其成為所有開(kāi)發(fā)人員更易于訪問(wèn)和用戶友好的工具。