REST和RPC架構之間的差異
本文的目的是對gRPC有一個高級的了解。 它還將解釋gRPC與Web應用程序通信遵循的現有協議和體系結構之間的異同。
什么是gRPC？
gRPC是一個開源的遠程過程調用框架，用于在服務之間進行高性能的通信。 這是將以不同語言編寫的服務與可插拔支持（用于負載平衡，跟蹤，運行狀況檢查和身份驗證）相連接的有效方法。 默認情況下，gRPC使用協議緩沖區來序列化結構化數據。 通常，對于微服務體系結構，gRPC被認為是REST協議的更好替代方案。 gRPC中的" g"可以歸因于最初開發該技術的google。
在詳細介紹gRPC之前，讓我們看一下微服務架構。
微服務與Monoliths
整體架構是設計應用程序的傳統方式。 它包含一個不可分割的代碼庫，用于服務于客戶端用戶界面，服務器端應用程序和數據庫。 在項目中工作的所有開發人員都將代碼貢獻到同一存儲庫中。 我最喜歡的與整體建筑相關的類比之一是將其視為一室公寓。 單個房間將根據需要分為各種空間。
整體架構的優勢在于，由于只有一個單元，因此可以輕松完成日志記錄，性能監控和緩存等操作。 而且，它很容易開發，測試，調試和部署。
但是隨著應用程序的增長，它變得難以維護，擴展甚至理解。 而且，它可能變得如此復雜，以至于代碼的少量更改會影響整個應用程序。
整體結構的另一個重要缺點是，它是對單一技術的嚴格承諾。 采用新的框架或語言可能需要對整個系統進行重寫。
進入微服務架構！
如果單片式架構是一室公寓，則微服務架構可以視為具有許多房間的房屋。 這意味著整個應用程序將細分為多個較小的應用程序或服務。
這使開發團隊可以靈活地選擇最適合其需求的技術，并使他們能夠獨立擴展服務。 微服務應用程序中的任何故障僅影響特定服務，而不影響整個應用程序。
這些服務可以獨立開發，維護和部署，它們通過稱為API（應用程序編程接口）的已定義方法相互通信。
通過HTTP的微服務之間的通信可以通過多種方式完成。 使用最廣泛的方法是遵循REST協議。 gRPC是執行此通信的另一種方法。 它旨在克服REST在微服務通信中的局限性。
REST架構
REST是使用HTTP協議的Web架構。 它被廣泛用于Web應用程序的開發。 簡而言之，REST是一種客戶端-服務器關系，其中后端數據通過諸如JSON / XML的簡單表示形式提供給客戶端。 如Roy Fielding所述，REST代表代表狀態轉移。 REST是一種協議，它不強制執行任何有關如何在較低級別實施的規則。 它為高級體系結構實施提供了指導。
為了使任何應用程序真正實現RESTful，必須遵循六個體系結構約束：
· 統一接口：意味著必須向Web應用程序中的API使用者提供API接口。
· 客戶端服務器：客戶端和服務器必須彼此獨立，并且客戶端應僅知道資源的URI。
· 無狀態：服務器不得存儲與客戶端請求相關的任何內容。 客戶端負責維護應用程序的狀態。
· 可緩存的：資源必須可緩存。
· 分層系統：體系結構必須是分層的，這意味著體系結構的組件可以位于多個服務器中。
· 按需代碼：客戶端必須能夠獲取可執行代碼作為響應。 這是一個可選約束。
基于REST的Web服務被稱為RESTful Web服務。 在這些應用程序中，每個組件都是一種資源，可以使用HTTP標準方法通過公共接口訪問這些資源。 以下四種HTTP方法通常用于基于REST的體系結構中：
· GET-對資源的只讀訪問。
· POST —創建一個新資源。
· DELETE—刪除資源。
· PUT-更新現有資源/創建新資源。
RPC架構
RPC代表遠程過程調用。 顧名思義，其思想是我們可以在遠程服務器上調用函數/方法。 RPC協議允許以相同的格式獲取問題的結果，而不管它在何處執行。 它可以是本地的，也可以使用更好的資源在遠程服務器中。
RPC是比REST更舊的協議。 從1970年代的ARPANET時代起，它就已經用于執行網絡操作。 RPC一詞最早由布魯斯·杰伊·尼爾森（Bruce Jay Nelson）于1981年提出。但是，正如我們將要看到的，RPC仍然很重要，并以不同的方式在基于API的現代應用程序中實現。
想法是一樣的。 通過定義公共方法來構建API。 然后用參數調用方法。 RPC只是一堆函數，但是在HTTP API的上下文中，它需要將方法放在URL中，并將參數放在查詢字符串或主體中。
RPC API將使用帶有{{id"：1}主體的POST / deleteResource之類的東西，而不是REST方法，即DELETE / resource / 1。
RPC在IoT設備和其他需要針對低功率設備進行自定義合約通信的解決方案中非常受歡迎，因為許多計算操作可以轉移到另一設備。 傳統上，RPC可以實現為RPC-XML和RPC-JSON。
gRPC是要在RPC協議上創建的最新框架。 它利用其優勢，并試圖糾正傳統RPC的問題。
什么是gRPC？
根據目前為止所讀的內容，我們可以重新定義gRPC。 它是對傳統RPC框架的改編。 那么，它與現有的RPC框架有何不同？
最重要的區別是gRPC使用protobuf 協議緩沖區作為接口定義語言進行序列化和通信，而不是JSON / XML。 協議緩沖區可以描述數據的結構，并且可以從該描述中生成代碼，以生成或解析表示結構化數據的字節流。 這就是為什么gRPC首選多語言（使用不同技術實現）的Web應用程序的原因。 二進制數據格式使通信更輕松。 gRPC也可以與其他數據格式一起使用，但是首選的是protobuf。
同樣，gRPC建立在HTTP / 2之上，它支持雙向通信以及傳統的請求/響應。 gRPC允許服務器和客戶端之間的松散耦合。 在實踐中，客戶端打開與gRPC服務器的長期連接，并且將為每個RPC調用打開一個新的HTTP / 2流。
REST與gRPC
與使用JSON（主要是JSON）的REST不同，gRPC使用協議緩沖區，這是編碼數據的更好方法。 由于JSON是基于文本的格式，因此它比protobuf格式的壓縮數據要重得多。
與REST相比，gRPC的另一個顯著改進是它使用HTTP 2作為其傳輸協議。 REST使用的HTTP 1.1基本上是一個請求-響應模型。 gRPC利用HTTP 2的雙向通信功能以及傳統的響應請求結構。 在HTTP 1.1中，當多個請求來自多個客戶端時，它們將被一一處理。 這會降低系統速度。 HTTP 2允許多路復用，因此可以同時處理多個請求和響應。
從這些觀點出發，我們可以得出結論，當用例涉及使用慣用API的多語言通信或大規模微服務通信時，gRPC是一個不錯的選擇。
(本文翻譯自Arun Mathew Kurian的文章《Understanding gRPC》，參考：https://medium.com/better-programming/understanding-grpc-60737b23e79e)
