gRPC 與 REST

用戶端/伺服器架構、C/S架構，是一種分布式架構，它把用戶端與伺服器分割開來。每一個用戶端軟體的執行個體都可以向一個伺服器或應用程式伺服器送出請求。有很多不同類型的伺服器，例如檔案伺服器、遊戲伺服器等。主從式架構通過不同的途徑應用于很多不同類型的應用程式，最常見就是目前在網際網路上用的網頁。例如，當你在維基百科閱讀文章時，你的電腦和網頁浏覽器就被當做一個用戶端，同時，組成維基百科的電腦、資料庫和應用程式就被當做伺服器。當你的網頁浏覽器向維基百科請求一個指定的文章時，維基百科伺服器從維基百科的資料庫中找出所有該文章需要的資訊，結合成一個網頁，再發送回你的浏覽器。

流行的用戶端-伺服器架構将通信分為兩部分：

1. 伺服器是承擔所有繁重任務并提供服務的。
2. 用戶端是享受這些服務的對象。

在一般的用戶端-伺服器通信中，用戶端簡單地向伺服器發送請求資源或服務的請求，伺服器響應該請求。

對于用戶端-伺服器通信，用戶端和伺服器需要有能夠了解它們通信所用協定的庫。協定是一種語言或一組網際網路通信規則。它們是遵循一些準則的傳輸機制，用于通過 Internet 傳輸資料。

用戶端通信的第二個最重要的方面是用戶端和伺服器都同意的消息格式。此消息格式基于某些模式，如果不遵循這些模式，就不會進行通信。消息格式可以類似于遵循模式的 XML，或包含特定鍵值對的 JSON 檔案。

了解此類通信的另一個重要方面是它基于請求和響應機制，這意味着伺服器僅在用戶端發起通信時才進行通信。對于 REST 和 GraphQL，這主要是單向的。這是一個基本問題，将通過 gRPC 這樣的技術來解決。

為什麼 REST 應運而生？

在 20 世紀 90 年代初期，一種名為 SOAP 的流行用戶端-伺服器協定使用帶有寫死模式的 XML 消息格式。消息格式的架構非常嚴格。缺乏自由是導緻 SOAP 被放棄和 REST 出現的原因。

由于 JavaScript 的日益流行，REST 應運而生，這導緻了 JSON 檔案格式的流行。它簡單易懂且友善。它的消息格式中隻有一些鍵值對。

簡而言之，Rest 是使用 HTTP 作為其協定（傳輸機制）在 Internet 上傳輸 JSON 消息的指南。使用 Rest，無需擔心制作模式。

什麼是REST？

我們談到了 REST 的出現。現在讓我們深入探讨其核心技，REST 代表 Representational State Transfer。Rest是一種标準化的軟體架構風格，是業界經常使用的API。

REST 流行和廣泛使用的原因

• REST 是簡單且标準化的通信架構。使用 REST 時，不必擔心格式化消息或資料，不必每次都為的消息格式操心，因為它都是标準化的和行業使用的。
• REST 是可擴充的。假設服務變得更大并且需要更多功能，在這種情況下，可以輕松地改造伺服器，而不必擔心伺服器的 REST 性能，并且可以完全隔離地建立新功能，除非它們弄亂了資料。
• REST 是無狀态的。這意味着每個請求都會有一些伺服器必須了解的資料。伺服器的體系結構使伺服器重新調用請求的資訊。盡管如此，在 REST 架構中，會話狀态存儲在用戶端，使伺服器更高效，并為伺服器提供更少的工作負載以實作更好的功能。
• 最後但同樣重要的是，REST 是一種高性能架構并支援緩存。

何時使用 REST：

想象一下，你正在為一家餐館制作一個網站。你有所有的線上菜單，食物分為三類：

1. 初學者
2. 主菜
3. 飲料

現在，假設想線上檢視所有飲料。在 Rest 架構中，可以輕松且一緻地對 API 端點上的所有資源進行分區。當然，你可以對它們使用多重身份驗證來確定它們的安全。

在這種情況下，我們向伺服器發送一個 GET 請求到一個我們可以擷取飲料資源資料的端點。

同樣，我們可以在Rest API中進行所有的CRUD（Create、Read、Update、Delete），這使得它适用于不需要超傳輸資料、不需要實時的大項目。

Rest 最适合高效資料傳輸是重要因素的項目。緩存是 REST 的另一個特性，它對食品預訂應用程式、酒店預訂應用程式、部落格網站、線上論壇網站等标準應用程式很有用。

REST 的局限性和問題

REST 很棒，但它有很多缺點，在某些情況下這些缺點非常重要。讓我們談談他們。

• 雙向通信的需要。如果伺服器需要向用戶端發送一些資料怎麼辦？意思是伺服器想要發起通信。在 REST 架構中，這是不可能的。當然，你可以使用一些技巧，但它們并不實用。
• 想象一下制作一個現場比分網站。你将如何管理伺服器向用戶端發送更新分數資料的請求？我們可以讓用戶端每 10 秒發送一次請求，但這根本不是一個好習慣。它會使伺服器過載，這可能會導緻速度問題。
• REST 架構純粹是請求和響應，不支援資料流（連續事件處理）。
• 無狀态的 REST 屬性可以被認為是一種祝福和詛咒，因為你無法決定 REST 架構上資料的狀态。

為什麼 gRPC 應運而生？

為了解決 REST 的第一個問題，即雙向通信的需要，發明了 WebSocket，它允許伺服器發起通信。不過，它的問題是它沒有格式。它隻是發送位元組，沒有任何限制。

WebSockets 本身沒有任何問題。盡管如此，實際問題仍然是任何類型的通信都需要一個協定，并且每個協定都需要一個可以使用該協定進行通信的用戶端庫。

如果你正在建立一個在 Rest 架構上運作的 Python 應用程式，你将需要一個可以與伺服器通信的 HTTP 用戶端。有時，用戶端庫是由第三方制作的，主要是獨立開發人員。使用第三方庫會暴露你的安全性，并且你的整個應用程式将依賴第三方進行通信。

對于 Web 應用程式，浏覽器就像一個用戶端庫，但對于非 Web 項目，你将需要第三方用戶端庫。如果你正在考慮自己制作一個應用程式，請記住這并不容易，而且會因為維護另一個應用程式而加重自己的負擔。

是以，為了解決 Rest 的一些問題和用戶端庫的問題，谷歌在 2015 年發明了 gRPC。

對于 gRPC，谷歌為幾乎所有流行語言維護了一個用戶端庫。它在底層使用 HTTP 2 協定和協定緩沖區 (protobuf) 作為其消息格式。

無需擔心任何用戶端庫，因為 Google 會為你和幾乎所有程式設計語言維護它。然而，單一且集中的用戶端庫是 gRPC 的主要優勢之一。

gRPC 的另一個好處是它使用的消息格式。此外，protocol buffer 與語言無關，是以可以在 Python 中建立用戶端，在 Go 中建立伺服器，并且仍然能夠毫不費力地進行通信。

gRPC 本質上是一個用戶端庫和一種可以在任何裝置上使用的協定。

什麼是 gRPC？

gRPC 使用 protobuf 進行通信。它将proto檔案序列化為二進制格式發送給伺服器，在伺服器端反序列化為原始格式。這就是它與 protobuf 一起工作的方式。

gRPC 有不同的通信形式，可以将它們視為 gRPC 的功能。

gRPC 的特點

1.單一請求

它是一種簡單類型的請求-響應通信，其中用戶端發送原始請求，伺服器在收到請求後等待一段時間以執行某些過程，然後傳回一些響應。

2.伺服器流媒體

在發出單個請求時，大量資料作為來自伺服器的響應。例如，當點選視訊時，大量與視訊相關的資料從伺服器端湧入。

3.用戶端流

對于伺服器流，反之亦然。在這裡，用戶端一次向伺服器發送大量資料。例如，當您在 Internet 上共享一個大檔案或将圖像或視訊上傳到 Internet 時，就會發生這種情況。用戶端不斷向伺服器端發送資料。

4.雙向流

在這種類型的通信中，用戶端和伺服器發送多條消息。聊天就是一個很好的例子。

gRPC 的四個流行特性使其如此強大。

何時使用 gRPC

至于 gRPC 的特性，我們看到了 gRPC 的一些用例。例如，假設你想制作一個聊天應用程式。你不會使用 Rest API，因為它無法允許雙向通信的快速流式傳輸。為此，我們将使用 gRPC 流，這将提供速度以外的更多好處。

首先，它的語言中立行為與伺服器或其他用戶端正在編寫的程式設計語言無關。在消息格式被接受之前，仍然可以建立通信。

是以，有了這個功能，Android 版本的聊天應用程式可以與 iOS 版本進行通信，反之亦然。

gRPC 的問題

一切都有問題，包括 gRPC。

有限的浏覽器支援

gRPC 使用 HTTP 2，是以很難直接從浏覽器調用 gRPC 服務。有時需要設定代理。

不可讀形式

衆所周知，gRPC 使用的是人類不可讀的二進制格式。在某些情況下這是一個缺點。

缺乏成熟度

gRPC 是 2015 年開發的，是以相對于 REST 還有些不成熟，還有很多 bug 和問題需要解決。

學習問題

Rest 和 GraphQL 使用 JSON，它更容易學習。然而，大多數人會嘗試堅持使用它們，因為 protobuf 仍然是一個新的複雜主題，是以很難找到 gRPC 專家。

休息與 gRPC

現在我們将讨論 REST 和 gRPC 之間的技術差異。

消息格式

REST 使用的消息格式主要是 JSON（有時是 XML 格式），這是一種可讀性更好且更易于處理的形式。不必擔心 Rest 中的模式。另一方面，gRPC 使用協定緩沖區來序列化資料。壓縮形式更輕，攜帶起來更快。它是二進制格式，是以它對資料進行序列化和反序列化以進行傳輸。

HTTP 1.1 與 HTTP 2

Rest API 通常使用 HTTP 1.1 作為其協定，而 gRPC 使用 HTTP 2 作為其底層協定。Rest API 仍然可以使用 HTTP 2，但由于請求-響應機制仍然受到限制。gRPC 使用 HTTP 2 并利用 HTTP 2 支援用戶端響應和雙向通信。這是 gRPC 性能優于 REST 的另一個方面。它可以像 HTTP 1.1 一樣管理單向請求，也可以像 HTTP 2 同時管理雙向請求。

潛伏

gRPC 的低延遲和高速通信使其适用于連接配接由輕量級微服務架構組成的系統，進而提高消息傳輸效率。在網絡的大多數情況下，REST 延遲需要 25ms，而 gRPC 延遲遠低于 REST。

負載限制

在發送傳出消息時，Rest 的最大負載限制為 45MB，而 gRPC 沒有任何限制，這意味着你的傳出消息可以随心所欲。

安全

在安全性方面，Rest 會有所滞後，因為它使用 HTTP 1.1 和易于解密和通路的 JSON 格式。另一方面，gRPC 使用安全得多的 HTTP 2，并使用二進制格式且難以解密的 protobuf。

速度

在這裡，gRPC 再次獲勝，因為它提供的速度是 Rest 的 10 倍，而且出于同樣的原因，它使用 HTTP 2 作為協定，使用 protobuf 作為消息格式。

代碼生成函數

Rest 不提供内置代碼生成功能，這意味着開發人員需要第三方應用程式來生成 API 代碼。相比之下，gRPC 由于其 protobuf 編譯器而具有本機代碼生成功能，該編譯器與多種程式設計語言相容。這是另一個好處，特别是對于微服務架構。

結論

最終，我想說的是，REST 仍然是使用最多、最流行的架構，放棄它是不可能的。當然REST也有很多缺點，比如沒有資料流，沒有雙向通信，速度慢等等，但是最适合我們日常生活中看到的标準應用。

另一方面，gRPC 年輕難學，提供了很多東西，比如用戶端和伺服器端的高資料流，良好的雙向資料流，快速緊湊，使用 HTTP 2。由于它的快速性能，gRPC 最适合高負載應用程式，如視訊流、歌曲流、線上遊戲、檔案共享和聊天應用程式。