全文共2925字，預計學習時長9分鐘
在今天的文章，小芯將帶著大家對gRPC進行高層次的了解，還將解釋gRPC與網絡應用程式通信所遵循的現有協議和體系結構之間的異同。
Are you ready？
什麼是gRPC？
gRPC是一個開源的遠程過程調用框架，用於伺服器間的高效對接。通過可插拔接口有效連接不同語言編寫的伺服器，進行負載平衡、跟蹤、運行狀況檢查和身份驗證。默認情況下，gRPC通過一種輕便高效的結構化存儲格式，對數據序列化。一般來說，gRPC被認為是微服務架構中REST協議更好的替代方案。gRPC中的「g」來源於最初開發這項技術的谷歌。
在研究更多gRPC細節之前，讓我們先看看微服務架構。
微服務與單體架構（Monoliths）
單體架構是設計應用程式的傳統方式。它包含一個不可分割的代碼庫，為客戶端用戶介面、伺服器端應用程式和資料庫提供服務。項目中工作的所有開發人員將把代碼存儲進同一代碼庫。筆者最喜歡對單片架構的類比是把它想像成一個工作室公寓。一間單人房將根據需要分成不同的空間。
單體架構的優勢在於，因為只有一個單元，所以像日誌記錄、性能監控和緩存等的操作可以很容易地完成。此外，開發、測試、調試和部署也很簡單。
但是隨著應用程式的增長，單片架構變得難以維護、擴展甚至難以理解。此外，它可以變得非常複雜，以至於代碼中的一個小變化都會影響到整個應用程式。
單片架構的另一重要缺點是它是對單一技術限制嚴格。採用一個新的框架或語言就可能需要重新編寫一個完整的系統。
接下來說微服務架構！
如果單體架構是一個工作室公寓，那麼微服務建築可以被認為是一個有許多房間的房子。這意味著整個應用程式將被細分為多個較小的應用程式或服務。
這使得開發團隊能夠靈活地選擇最適合他們需求的技術，並且允許獨立擴展服務。微服務應用程式中的任何故障只影響特定的服務，而不是整個應用程式。
這些服務可以獨立開發、維護和部署，並且通過API (應用編程接口)相互聯繫。
基於HTTP協議的微服務之間的通信可以通過多種方式完成。最廣泛使用的方法是遵循REST協議。gRPC是執行這種通信的另一種方式。它的建立是為了克服微服務通信中REST的局限性。
來源：Pexels
REST架構
REST是一個使用HTTP協議的網絡架構。它被廣泛應用於開發網絡應用程式。簡而言之，REST是一種客戶機-伺服器關係，其中後端數據通過簡單的表示(如JSON/XML)提供給客戶機。如羅伊·菲爾丁所描述,REST代表REpresentational State Transfer。REST是一種協議，不強制執行任何關於它應該如何在較低級別實現的規則。為實現高級架構提供了指導。
為了使任何應用程式真正具有RESTful屬性，必須遵循六個架構準則:
1. 統一接口:API接口必須向API使用者呈現網絡應用程式中的資源。
2. 客戶端/伺服器:客戶端和伺服器必須相互獨立，客戶端只需知道連結。
3. 無狀態該伺服器不能存儲任何與客戶端請求相關的內容。客戶端負責維護應用程式的狀態。
4. 可緩存:資源必須是可緩存的。
5. 分層系統:架構必須有層次，這意味著架構的組件可以存在於多個伺服器中。
6. 按需編碼:客戶端必須能夠獲得可執行代碼作為響應。這是一個可選約束。
基於REST的網絡服務被稱為RESTful網絡服務。在這些應用程式中，每個組件都是一個資源，並且這些資源可以基於HTTP標準方法，通過一個通用接口來訪問。以下四種HTTP方法通常在REST結構中使用:
· GET—對資源的只讀訪問。
· POST—創建新資源。
· DELETE—刪除資源。
· PUT—更新現有資源/創建新資源。
RPC架構
RPC代表遠程過程調用。顧名思義，可以在遠程伺服器上調用一個函數/方法。不管在哪裡執行，RPC協議允許以相同的格式獲得問題的結果。可以是本地伺服器，也可以是使用更好資源的遠程伺服器。
RPC是一個比REST還要早的協議。自20世紀70年代ARPANET問世以來，它就一直用於執行網絡操作。1981年，布魯斯·傑伊·納爾遜首次創造了RPC這個術語。但是正如我們將要看到的，RPC仍然是相關的，並且以不同的方式在基於API的現代應用程式中實現。
理念是的。通過定義公共方法來構建一個應用編程接口。然後用參數調用這些方法。RPC只是一堆函數，但對於HTTP API，它需要將方法放在URL中，將參數放在查詢字符串或正文中。
RPC API將使用類似POST /deleteResource的方法，其主體為{ 「id」: 1 } ，而不是REST方法，即DELETE /resource/1.
RPC非常受物聯網設備和其他需要為低功耗設備定製通信的解決方案的歡迎，因為許多計算操作可以轉移到另一個設備。傳統上，遠程過程控制可以用於RPC-XML和RPC-JSON。
gRPC是在RPC協議上創建的最新框架。它充分利用了傳統RPC的優點，試圖解決傳統RPC的問題。
那什麼是gRPC？
截至目前，我們所讀到的都可以重新定義gRPC。它是對傳統的RPC框架的改編。那麼，它與現有的RPC框架有什麼不同呢？
最重要的區別是gRPC使用協議緩衝區作為序列化和通信的接口定義語言，而不是JSON/XML。協議緩衝區可以描述數據的結構，代碼可以從描述中生成，以生成或解析表示結構化數據的位元組流。這就是為什麼gRPC更適合多語言編寫(用不同的技術實現) 的網絡應用程式。二進位數據格式允許通信更輕量。gRPC也可以與其他數據格式一起使用，但是首選格式是協議緩衝區。
此外，gRPC建立在HTTP/2之上，支持雙向通信以及傳統請求/響應。gRPC允許伺服器和客戶端之間的鬆散耦合。實際上，客戶端建立一個與gRPC伺服器的長期連接，並為每個RPC調用建立一個新的HTTP/2流。
來源：Pexels
REST與gRPC
與大多數使用JSON的REST不同，gRPC使用協議緩衝區，這是一種更好的數據編碼方式。由於JSON是一種基於文本的格式，它將比protobuf格式的壓縮數據占用更多的存儲。
與REST相比，gRPC的另一個重要改進是它使用HTTP 2作為傳輸協議。REST使用的HTTP 1.1基本上是一個請求-響應模型。gRPC利用了HTTP 2的雙向通信特性以及傳統的響應請求結構。在HTTP 1.1中，當多個請求來自多個客戶端時，它們將按順序提供服務。這會降低系統速度。HTTP 2允許多路復用，因此可以同時處理多個請求和響應。
基於以上觀點，可以得出結論，當用例涉及使用慣用的API的多語言通信或大規模微服務通信時，gRPC是一個很好的選擇。
留言點贊關注
我們一起分享AI學習與發展的乾貨
如轉載，請後台留言，遵守轉載規範