gRPC vs REST：兩種 API 架構風格的對比

作者 | Mariana Berga、André Santos

譯者 | 王強

策劃 | 萬佳

想知道未來是不是 gRPC 的天下？本文會具體介紹兩種 API 架構風格：REST 和 gRPC，並討論它們之間的區別。不過，首先，我們會解釋什麼是 API，以及爲什麼它對微服務基礎設施而言至關重要。之後，我們會介紹 gRPC 的基礎——RPC，並探討 gRPC 和 REST API 之間的重要差異。根據它們的對比結果，我們最後會分析什麼時候應該使用哪種架構類型。

1API 是什麼

API，即應用程序編程接口。這些接口充當軟件中介，爲應用程序之間的交互和對話建立特定的定義和規則。API 負責將響應從用戶傳遞到系統，然後從系統返回給用戶。聽起來還是有點糊塗？

API 的工作機制

假設我們正在預訂一個酒店。我們在筆記本電腦上訪問酒店預訂頁面，連接到互聯網的這個頁面會將數據（我們的請求）發送到服務器。然後，服務器檢索數據，解析它，一旦所需的操作得到執行，它就會向我們發送一個響應，並在我們的界面上提供信息。這個過程需要 API 才能實現。

API 指定了一個應用程序（網頁或移動應用）可以向另一個應用程序發出的請求類型，並進一步確定：如何發出這些請求；使用哪些數據格式；以及用戶必須遵循的實踐。

本文會對比 gRPC 和 REST 兩大架構風格，因爲它們代表了人們創建 API 時最常用的兩種架構風格。

 API 和微服務

一方面，在單體應用程序中，項目的所有功能都包含在一個單元中，更準確地說是包含在一個代碼庫中。另一方面，微服務架構由一些較小的服務組成，這些服務使用 HTTP 等協議相互通信。作爲微服務架構一部分的組件服務通過 API 相互通信和交互。換句話說，API 允許集成到微服務應用程序中的所有服務互相連接和通信。

最常用的架構風格是 REST API。但構建 API 時主要有 3 種模型：RPC（遠程過程調用）、REST（表徵狀態傳輸）和 GraphQL。在本文中，我們將重點介紹前兩個。

2 什麼是 RPC？

RPC 使用客戶端 - 服務器模型。請求服務器（換句話說就是客戶端）請求一條消息，該消息由 RPC 轉換併發送到另一臺服務器。服務器收到請求後將響應發送回客戶端。當服務器處理這個調用時，客戶端被阻塞，服務器內部的消息傳遞被隱藏。

此外，RPC 允許客戶端以特定格式請求函數，並以完全相同的格式接收響應。在 URL 中可以找到使用 RPC API 提交調用的方法。RPC 支持本地和分佈式環境中的遠程過程調用。

與 REST API 一樣，RPC 還建立了交互規則以及用戶如何提交 “調用”（請求）以調用方法與服務通信和交互的機制。

3 什麼是 REST？

使用 REST API 時，來自後端數據的響應通過 JSON 或 XML 消息格式傳遞給客戶端（或用戶）。這種架構模型傾向於遵循 HTTP 協議。然而，在維護 RCP 模型的同時，RCP 設計也時常從 HTTP 中汲取一些想法。事實上，不管使用的是哪種模型（RPC 或 REST），大多數現代 API 實現都將 API 映射到相同的 HTTP 協議時。

當 REST API 公開可用時，每個集成微服務應用程序的服務都可以作爲資源呈現給用戶 / 客戶端，資源可以通過以下 HTTP 命令訪問：GET、DELETE、POST和PUT。

4 什麼是 gRPC？

gRPC 是 Google Remote Procedure Call 的簡寫，是基於 RCP 架構的變體。該技術遵循一個使用 HTTP 2.0 協議的 RPC API 實現，但 HTTP 不會呈現給 API 開發人員或服務器。因此，開發人員無需擔心 RPC 概念如何映射到 HTTP，從而降低了複雜性。

總的來說，gRPC 旨在加快微服務之間的數據傳輸。它的基礎方法是確定一個服務，建立方法和相應的參數來實現遠程調用和返回類型。

此外，它以 一個 IDL（接口描述語言）表示 RPC API 模型，這爲確定遠程過程提供了更直接的方法。默認情況下，IDL 使用 Protocol Buffers（但也可以使用其他替代方案）來描述服務接口以及負載消息的結構。

5gRPC 與 REST：對比

現在，我們對 gRPC 和 REST 有了一個初步認識，下面我們來看看它們的主要區別。

 HTTP 1.1 vs HTTP 2

REST API 遵循一個通常基於 HTTP 1.1 構建的 請求 - 響應通信模型。不幸的是，這意味着如果一個微服務收到來自多個客戶端的多個請求，該模型必須每次只處理一個請求，拖慢了整個系統的速度。REST API 也可以構建在 HTTP 2 上，但通信的請求 - 響應模型保持不變，這使得 REST API 無法充分利用 HTTP 2 的優勢，例如 流式通信 和 雙向支持。

gRPC 沒有面臨類似的障礙。它建立在 HTTP 2 之上，且遵循客戶端 - 響應通信模型。這讓它支持雙向通信和流式通信，因爲 gRPC 能接收來自多個客戶端的多個請求，並通過不斷地流式傳輸信息來同時處理這些請求。此外，gRPC 還可以處理 “一元” 交互，例如構建在 HTTP 1.1 上的交互。

總之，gRPC 能處理一元交互和多種類型的流：

流類型

 瀏覽器支持

這可能是 REST 相對於 gRPC 的主要優勢之一。一方面，所有瀏覽器都完全支持 REST。另一方面，gRPC 獲得的瀏覽器支持仍然非常有限。

不幸的是，它需要 gRPC-web 和一個代理層來執行 HTTP 1.1 和 HTTP 2 之間的轉換。因此，gRPC 主要用於內部 / 私有系統（特定組織的後端數據和應用程序功能中的 API 程序）。

 負載數據結構

如前所述，gRPC 默認使用 Protocol Buffers 來序列化負載數據。這個方案更輕便，因爲它支持高度壓縮的格式並減少了消息的大小。此外，Protobuf（或 Protocol Buffer）是二進制的；它對結構化數據進行序列化和反序列化，以便通信和傳輸。換句話說，強類型消息可以自動從 Protobuf 轉換爲客戶端和服務器的編程語言。

相比之下，REST 主要依靠 JSON 或 XML 格式來發送和接收數據。事實上，即使它不強制要求任何結構，JSON 也是最流行的格式，因爲它具有靈活性和發送動態數據的能力，而不必遵循嚴格的結構。使用 JSON 的另一顯著優勢是其人類可讀水平，這方面 Protobuf 尚無法與之競爭。

儘管如此，JSON 在數據傳輸方面並不夠輕量或快速。其原因在於，在使用 REST 時，必須將 JSON（或其他格式）序列化並轉換爲客戶端和服務器端使用的編程語言。這在傳輸數據的過程中增加了一個額外步驟，從而可能會損害性能並增加出現錯誤的可能性。

 代碼生成功能

與 gRPC 不同，REST API 不提供內置代碼生成功能，這意味着開發人員必須使用 Swagger 或 Postman 等第三方工具爲 API 請求生成代碼。

相比之下，gRPC 由於其 protoc 編譯器而具有原生代碼生成功能，該編譯器與多種編程語言兼容。這對於集成了以不同語言和平臺開發的各種服務的微服務系統來說尤其方便。此外，內置的代碼生成器還有助於創建 SDK（軟件開發工具包）。

6gRPC 與 REST：對比表

7 何時使用 gRPC，何時使用 REST？

如前所述，儘管 gRPC 提供了許多優勢，但它有一個主要障礙：瀏覽器兼容性低。因此，gRPC 的用例一般侷限在內部 / 私有系統。

相比之下，正如我們所討論的那樣，REST API 可能有其缺點，但它們仍然是連接基於微服務的系統的最流行的 API。此外，REST 遵循 HTTP 協議標準化並提供通用支持，使這種 API 架構風格成爲 Web 服務開發以及應用程序和微服務集成的首選。然而，這並不意味着我們應該忽視 gRPC 的應用場景。

gRPC 架構風格具有很多值得（並且應該）探索的有前途的特性。它是處理多語言系統和實時流的絕佳選擇，例如，當運營需要輕量級消息傳輸（可以由序列化 Protobuf 消息支持）的 IoT 系統時，gRPC 就很合適。此外，gRPC 也可以考慮用於移動應用程序，因爲它們不需要瀏覽器，且消息體積更小，不會拖慢移動設備的速度。

8 結論

gRPC 提供了很多優勢。與 REST 不同，它可以充分利用 HTTP 2，使用多路複用流並遵循二進制協議。此外，由於 Protobuf 消息結構，它還具備性能優勢，支持多語言環境的內置代碼生成功能也是一大好處。這些因素使 gRPC 成爲了一種很有前途的 API 架構風格。

儘管如此，瀏覽器支持不足使 gRPC 很難匹敵 REST 的通用支持能力。REST 仍然是微服務系統中的粘合劑，是最流行的解決方案。因此它很可能會存在很長時間，而且說實話，它是一個非常成熟和成功的架構。

原文鏈接：

https://www.imaginarycloud.com/blog/grpc-vs-rest/?fileGuid=3WQyP6YQDvcqhcXx

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/R2Y5C3ebQ04uCKwAs0pATA

猜你喜歡