gRPC 的特性和背後設計的原則(一)

a_wei發表於2019-08-21

開一個gRPC學習的專題,感興趣的一起參與,一週一篇,下一篇聊聊protocol buffer

什麼是gRPC?

  1. RPC全稱(Remote Procedure Call),遠端過程呼叫,指的是一臺計算機透過網路請求另一臺計算機的上服務,從而不需要了解底層網路細節,RPC是構建在已經存在的協議(TCP/IP,HTTP等)之上的,RPC採用的是客戶端,伺服器模式。
  2. gRPC是雲原生計算基金會(CNCF)專案, gRPC 一開始由 google 開發,是一款語言中立、平臺中立的服務間通訊框架,使用gRPC可以使得客戶端像呼叫本地方法一樣,呼叫遠端主機提供的服務。可以在任何地方執行,它使客戶端和伺服器應用程式能夠透明地進行通訊,並使構建連線系統變得更加容易。
  3. gRPC目前最新版本是v1.22.0

gRPC的一些特性

  1. gRPC基於服務的思想:定義一個服務,描述這個服務的方法以及入參出參,伺服器端有這個服務的具體實現,客戶端保有一個存根,提供與服務端相同的服務
  2. gRPC預設採用protocol buffer作為IDL(Interface Description Lanage)介面描述語言,服務之間通訊的資料序列化和反序列化也是基於protocol buffer的,因為protocol buffer的特殊性,所以gRPC框架是跨語言的通訊框架(與程式語言無關性),也就是說用Java開發的基於gRPC的服務,可以用GoLang程式語言呼叫
  3. gRPC同時支援同步呼叫和非同步呼叫,同步RPC呼叫時會一直阻塞直到服務端處理完成返回結果, 非同步RPC是客戶端呼叫服務端時不等待服務段處理完成返回,而是服務端處理完成後主動回撥客戶端告訴客戶端處理完成
  4. gRPC是基於http2協議實現的,http2協議提供了很多新的特性,並且在效能上也比http1提搞了許多,所以gRPC的效能是非常好的
  5. gRPC並沒有直接實現負載均衡和服務發現的功能,但是已經提供了自己的設計思路。已經為命名解析和負載均衡提供了介面
  6. 基於http2協議的特性:gRPC允許定義如下四類服務方法
    1. 單項RPC:客戶端傳送一次請求,等待服務端響應結構,會話結束,就像一次普通的函式呼叫這樣簡單
    2. 服務端流式RPC:客戶端發起一起請求,服務端會返回一個流,客戶端會從流中讀取一系列訊息,直到沒有結果為止
    3. 客戶端流式RPC:客戶端提供一個資料流並寫入訊息發給服務端,一旦客戶端傳送完畢,就等待伺服器讀取這些訊息並返回應答
    4. 雙向流式RPC:客戶端和服務端都一個資料流,都可以透過各自的流進行讀寫資料,這兩個流是相互獨立的,客戶端和服務端都可以按其希望的任意順序獨寫

gRPC支援的程式語言

  • C ++,Java(包括對Android的支援),Objective-C(對於iOS),Python,Ruby,Go,C#,Node.js都在GA中,並遵循語義版本控制。

gRPC的使用場景

  1. 低延遲,高度可擴充套件的分散式系統
  2. 開發與雲伺服器通訊的客戶端
  3. 設計一個準確,高效,且與語言無關的新協議時
  4. 分層設計,以實現擴充套件,例如。身份驗證,負載平衡,日誌記錄和監控等

誰在使用gRPC

  • 谷歌長期以來一直在gRPC中使用很多基礎技術和概念。目前正在谷歌的幾個雲產品和谷歌面向外部的API中使用。Square,Netflix,CoreOS,Docker,CockroachDB,Cisco,Juniper Networks以及許多其他組織和個人也在使用它。

gRPC設計之初的動機和原則

  1. 自由,開放:讓所有人,所有平臺都能使用,其實就是開源,跨平臺,跨語言
  2. 協議可插拔:不同的服務可能需要使用不同的訊息通訊型別和編碼機制,例如,JSON、XML和 Thirft,所以協議應允許可插拔機制,還有負載均衡,服務發現,日誌,監控等都支援可插拔機制
  3. 阻塞和非阻塞:支援客戶端和伺服器交換的訊息序列的非同步和同步處理。這對於在某些平臺上擴充套件和處理至關重要
  4. 取消和超時:一次RPC操作可能是持久並且昂貴的,應該允許客戶端設定取消RPC通訊和對這次通訊加上一個超時時間
  5. 拒絕:必須允許伺服器透過在繼續處理請求的同時拒絕新請求的到來並優雅地關閉。
  6. 流處理:儲存系統依靠流和流控制來表達大型資料集,其他服務,如語音到文字或股票行情,依賴於流來表示與時間相關的訊息序列
  7. 流控制:計算能力和網路容量在客戶端和伺服器之間通常是不平衡的。流控制允許更好的緩衝區管理,以及過度活躍的對等體提供對DOS的保護。
  8. 後設資料交換 - 認證或跟蹤等常見的跨領域問題依賴於不屬於服務宣告介面的資料交換。
    依賴於他們將這些特性演進到服務,暴露API來提供能力。
  9. 標準化狀態碼 - 客戶端通常以有限的方式響應API呼叫返回的錯誤。應約束狀態碼名稱空間,以使這些錯誤處理決策更加清晰。如果需要更豐富的特定領域的狀態,則可以使用後設資料交換機制來提供該狀態。
  10. 互通性:報文協議(Wire Protocol)必須遵循普通網際網路基礎框架

歡迎大家關注微信公眾號:“golang那點事”,更多精彩期待你的到來

聊聊gRPC的特性和背後設計的原則(一)

本作品採用《CC 協議》,轉載必須註明作者和本文連結
那小子阿偉

相關文章