gRPC實戰--gRPC簡介:why,what,how?

gRPC實戰包含一系列文章，包括原創和翻譯。最終會造成一個完整的系列，後續會不斷完善，增長新的內容：

• gRPC簡介:why,what,how?
• gRPC服務健康檢查最佳實踐
• Kubernetes中使用envoy負載均衡gRPC流量
• 用Golang編寫經過gRPC進行通訊的服務
• 如何在NodeJS中有效使用gRPC流

=============================================================

Why gRPC?

讓咱們從一個簡單的問題開始：gRPC的動機是什麼？或是gRPC試圖解決的問題是什麼？

好吧，答案是通訊。

應用程序是使用不一樣的編程語言編寫的。
例如，後端能夠用Go編寫，而前端（例如android app用Java編寫，iOS app用Swift編寫）。
那麼他們如何互相通訊

當今的趨勢是使用微服務架構。所以，即便在後端，根據業務需求和技術約束，咱們可能還會有許多用不一樣語言（例如Go，Python或Rust）編寫的服務。

使用gRPC的動機：不一樣語言之間通訊

• 先後端採用了不一樣的語言
• 微服務架構，採用了不一樣的語言

• 經過遵照一致的約定去交互信息

  • 通訊通道：REST，SOAP，消息隊列
  • 身份驗證機制：Basic，OAuth，JWT
  • 負載類型：JSON，XML，binary
  • 數據模型
  • 錯誤處理

所以，爲了彼此通訊，他們必須都遵照一組API約定。例如：通訊通道，身份驗證機制，有效載荷格式，數據模型以及如何處理錯誤。

有太多事情須要考慮，這就是爲何構建API真的很困難。

使用gRPC的動機：簡單而高效的通訊

更重要的是，咱們但願通訊高效，快速且輕巧。您知道，微服務之間的交換消息數量巨大。所以，通訊越快越好。

另外，在某些環境（例如移動應用）中，網絡速度和帶寬受到限制，擁有輕量級的通訊協議與服務器進行交互很是重要。

最後但並不是最不重要的一點是，咱們但願溝通很簡單。假設咱們正在構建一個包含數百個甚至數千個微服務的系統。咱們絕對不但願將大部分時間花在編寫代碼上只是爲了讓他們彼此通訊，對嗎？

咱們想要的是某種框架，容許開發人員專一於實現其服務的核心邏輯。並將其餘全部內容留給框架處理。

該框架就是gRPC。

What is gRPC? How it works?

gRPC是最初由Google開發的高性能，開源，功能豐富的RPC框架，如今與Kubernetes或Prometheus同樣，它是雲原生計算基礎（或CNCF）的一部分。

RPC是什麼？ RPC表明遠程過程調用。它是容許程序執行位於其餘計算機上的另外一個程序的過程的協議。

使人敬畏的是，開發人員沒必要明確編碼網絡交互的細節。它由基礎框架自動處理。

所以，在客戶端代碼中，看起來咱們只是在直接調用服務器代碼的功能。即便客戶端和服務器上的代碼是用不一樣的編程語言編寫的，它也能夠工做。像本示例同樣，客戶端代碼用Go編寫，服務器代碼用Rust編寫。

那麼gRPC如何作到這一點？基本上，客戶端具備一個存根，該存根提供與服務器相同的方法（或功能）。該存根由gRPC自動爲您生成。

存根將在後臺調用gRPC框架，以經過網絡與服務器交換信息。

瞧，神奇的是一切正常。因爲存根，客戶端和服務器如今只須要關心實現其核心服務邏輯。

接下來，咱們將看到如何在protocol buffer的幫助下生成gRPC存根。

gRPC如何生成代碼？

代碼生成是gRPC的最重要功能之一。

爲了爲服務器和客戶端生成存根，咱們首先須要編寫API協定，該協定包括在protocol buffer文件中的服務及其有效載荷消息的描述，以下所示：

syntax = "proto3"

message HelloRequest {
  string name = 1;
}

message HelloResponse {
  string greet = 1;
}

service HelloService {
  rpc Hello(HelloRequest) return (HelloResponse);
}

在此文件中，定義了一個Hello方法，該方法將HelloRequest做爲輸入並返回HelloResponse。 HelloRequest僅包含一個字符串名稱，而HelloResponse具備一個字符串。

protocol buffer編譯器今後proto文件生成服務器和客戶端存根代碼。根據編程語言，咱們將不得不告訴編譯器爲其使用正確的gRPC插件。

爲Rust和Go生成的代碼將以下所示：

OK，因此您可能想知道爲何gRPC使用protocol buffer？好吧，有不少緣由。

首先，它很是易於閱讀和理解。

其次，它的語言可與多種語言自動生成代碼互操做

第三，它表示二進制格式的數據，與某些基於文本的格式（如JSON或XML）相比，它的大小更小，傳輸速度更快，序列化的效率更高。

它在客戶端和服務器之間提供了一種強類型的API契約，使用它很是安全, 並且確保向後和向前的兼容性。

聽起來很棒，對嗎？可是，使用gRPC必定須要protocol buffer嗎？

答案是不。您能夠改用Google Flatbuffers或Microsoft Bond。可是我認爲protocol buffer已是一個不錯的選擇。

它支持許多流行的編程語言，其中10種已正式支持，其中純實現了Go，Java，NodeJS，另外7種是gRPC核心C的包裝，即C ++，C＃，Objective-C，Python，Ruby，Dart和PHP。

此外，還有許多其餘語言的非官方庫，例如Swift，Rust，TypeScript，Haskell等。

gRPC與HTTP2

gRPC使用HTTP/2做爲其傳輸協議，所以它繼承了HTTP/2提供的一些出色功能，例如二進制幀，與其餘基於文本的協議相比，它具備高性能，強健性，更輕便的傳輸和更安全的解碼能力。並且由於它是二進制文件，因此它與protocol buffer完美結合。

HTTP/2還使用HPACK壓縮報頭，這將減小開銷成本並提升性能。

在HTTP/2中能夠進行多路複用，這意味着客戶端和服務器能夠經過單個TCP鏈接並行發送多個請求和響應。這將有助於減小延遲並提升網絡利用率。

最後，HTTP/2容許服務器推送，其中來自客戶端的1個單個請求使服務器能夠發回多個響應。在許多狀況下，當服務器確切知道客戶端須要什麼資源並在請求以前將其發送時，這對於減小客戶端和服務器之間的往返延遲很是有價值。