聊聊gRPC的特性和背後設計的原則（一）

開一個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)必須遵循普通網際網路基礎架構

資訊來源 https://grpc.io/faq/