到目前為止，咱們講了四種 RPC，分別是 ONC RPC、基于 XML 的 SOAP、基于 JSON 的 RESTful 和 Hessian2，
通過學習，我們知道，二進制的傳輸性能好，文本類的傳輸性能差一些；二進制的難以跨語言，文本類的可以跨語言；要寫協議檔案的嚴謹一些，不寫協議檔案的靈活一些，雖然都有服務發現機制，有的可以進行服務治理，有的則沒有，
我們也看到了 RPC 從最初的客戶端服務器模式，最終演進到微服務，對于 RPC 框架的要求越來越多了，具體有哪些要求呢？
- 首先，傳輸性能很重要，因為服務之間的呼叫如此頻繁了，還是二進制的越快越好，
- 其次，跨語言很重要，因為服務多了，什么語言寫成的都有，而且不同的場景適宜用不同的語言，不能一個語言走到底，
- 最好既嚴謹又靈活，添加個欄位不用重新編譯和發布程式，
- 最好既有服務發現，也有服務治理，就像 Dubbo 和 Spring Cloud 一樣，
Protocol Buffers
這是要多快好省地建設社會主義啊，理想還是要有的嘛，這里我就來介紹一個向“理想”邁進的 GRPC，
GRPC 首先滿足二進制和跨語言這兩條，二進制說明壓縮效率高，跨語言說明更靈活，但是又是二進制，又是跨語言，這就相當于兩個人溝通，你不但說方言，還說縮略語，人家怎么聽懂呢？所以，最好雙方弄一個協議約定檔案，里面規定好雙方溝通的專業術語，這樣溝通就順暢多了，
對于 GRPC 來講，二進制序列化協議是 Protocol Buffers，首先，需要定義一個協議檔案.proto，
我們還看買極客時間專欄的這個例子，
syntax = “proto3”;
package com.geektime.grpc
option java_package = “com.geektime.grpc”;
message Order {
required string date = 1;
required string classname = 2;
required string author = 3;
required int price = 4;
}
message OrderResponse {
required string message = 1;
}
service PurchaseOrder {
rpc Purchase (Order) returns (OrderResponse) {}
}
在這個協議檔案中，我們首先指定使用 proto3 的語法，然后我們使用 Protocol Buffers 的語法，定義兩個訊息的型別，一個是發出去的引數，一個是回傳的結果，里面的每一個欄位，例如 date、classname、author、price 都有唯一的一個數字標識，這樣在壓縮的時候，就不用傳輸欄位名稱了，只傳輸這個數字標識就行了，能節省很多空間，
最后定義一個 Service，里面會有一個 RPC 呼叫的宣告，
無論使用什么語言，都有相應的工具生成客戶端和服務端的 Stub 程式，這樣客戶端就可以像呼叫本地一樣，呼叫遠程的服務了，
協議約定問題
Protocol Buffers 是一款壓縮效率極高的序列化協議，有很多設計精巧的序列化方法，
對于 int 型別 32 位的，一般都需要 4 個 Byte 進行存盤，在 Protocol Buffers 中，使用的是變長整數的形式，對于每一個 Byte 的 8 位，最高位都有特殊的含義，
如果該位為 1，表示這個數字沒完，后續的 Byte 也屬于這個數字；如果該位為 0，則這個數字到此結束，其他的 7 個 Bit 才是用來表示數字的內容，因此，小于 128 的數字都可以用一個 Byte 表示；大于 128 的數字，比如 130，會用兩個位元組來表示，
對于每一個欄位，使用的是 TLV（Tag，Length，Value）的存盤辦法，
其中 Tag = (field_num << 3) | wire_type，field_num 就是在 proto 檔案中，給每個欄位指定唯一的數字標識，而 wire_type 用于標識后面的資料型別，
例如，對于 string author = 3，在這里 field_num 為 3，string 的 wire_type 為 2，于是 (field_num << 3) | wire_type = (11000) | 10 = 11010 = 26；接下來是 Length，最后是 Value 為“liuchao”，如果使用 UTF-8 編碼，長度為 7 個字符，因而 Length 為 7，
可見，在序列化效率方面，Protocol Buffers 簡直做到了極致，
在靈活性方面，這種基于協議檔案的二進制壓縮協議往往存在更新不方便的問題，例如，客戶端和服務器因為需求的改變需要添加或者洗掉欄位，
這一點上，Protocol Buffers 考慮了兼容性，在上面的協議檔案中，每一個欄位都有修飾符，比如：
- required：這個值不能為空，一定要有這么一個欄位出現；
- optional：可選欄位，可以設定，也可以不設定，如果不設定，則使用默認值；
- repeated：可以重復 0 到多次，
如果我們想修改協議檔案，對于賦給某個標簽的數字，例如 string author=3，這個就不要改變了，改變了就不認了；也不要添加或者洗掉 required 欄位，因為決議的時候，發現沒有這個欄位就會報錯，對于 optional 和 repeated 欄位，可以洗掉，也可以添加，這就給了客戶端和服務端升級的可能性，
例如，我們在協議里面新增一個 string recommended 欄位，表示這個課程是誰推薦的，就將這個欄位設定為 optional，我們可以先升級服務端，當客戶端發過來訊息的時候，是沒有這個值的，將它設定為一個默認值，我們也可以先升級客戶端，當客戶端發過來訊息的時候，是有這個值的，那它將被服務端忽略，
至此，我們解決了協議約定的問題，
網路傳輸問題
接下來，我們來看網路傳輸的問題，
如果是 Java 技術堆疊，GRPC 的客戶端和服務器之間通過 Netty Channel 作為資料通道，每個請求都被封裝成 HTTP 2.0 的 Stream，
Netty 是一個高效的基于異步 IO 的網路傳輸框架，這個上一節我們已經介紹過了，HTTP 2.0 在第 14 講，我們也介紹過，HTTP 2.0 協議將一個 TCP 的連接，切分成多個流，每個流都有自己的 ID，而且流是有優先級的，流可以是客戶端發往服務端，也可以是服務端發往客戶端，它其實只是一個虛擬的通道，
HTTP 2.0 還將所有的傳輸資訊分割為更小的訊息和幀，并對它們采用二進制格式編碼，
通過這兩種機制，HTTP 2.0 的客戶端可以將多個請求分到不同的流中，然后將請求內容拆成幀，進行二進制傳輸，這些幀可以打散亂序發送， 然后根據每個幀首部的流識別符號重新組裝，并且可以根據優先級，決定優先處理哪個流的資料，
由于基于 HTTP 2.0，GRPC 和其他的 RPC 不同，可以定義四種服務方法，
第一種，也是最常用的方式是單向 RPC，即客戶端發送一個請求給服務端，從服務端獲取一個應答，就像一次普通的函式呼叫，
rpc SayHello(HelloRequest) returns (HelloResponse){}
第二種方式是服務端流式 RPC，即服務端回傳的不是一個結果，而是一批，客戶端發送一個請求給服務端，可獲取一個資料流用來讀取一系列訊息，客戶端從回傳的資料流里一直讀取，直到沒有更多訊息為止，
rpc LotsOfReplies(HelloRequest) returns (stream HelloResponse){}
第三種方式為客戶端流式 RPC，也即客戶端的請求不是一個，而是一批，客戶端用提供的一個資料流寫入并發送一系列訊息給服務端，一旦客戶端完成訊息寫入，就等待服務端讀取這些訊息并回傳應答，
rpc LotsOfGreetings(stream HelloRequest) returns (HelloResponse) {}
第四種方式為雙向流式 RPC，即兩邊都可以分別通過一個讀寫資料流來發送一系列訊息，這兩個資料流操作是相互獨立的，所以客戶端和服務端能按其希望的任意順序讀寫，服務端可以在寫應答前等待所有的客戶端訊息，或者它可以先讀一個訊息再寫一個訊息，或者讀寫相結合的其他方式，每個資料流里訊息的順序會被保持，
rpc BidiHello(stream HelloRequest) returns (stream HelloResponse){}
如果基于 HTTP 2.0，客戶端和服務器之間的互動方式要豐富得多，不僅可以單方向遠程呼叫，還可以實作當服務端狀態改變的時候，主動通知客戶端，
至此，傳輸問題得到了解決，
服務發現與治理問題
最后是服務發現與服務治理的問題，
GRPC 本身沒有提供服務發現的機制，需要借助其他的組件，發現要訪問的服務端，在多個服務端之間進行容錯和負載均衡，
其實負載均衡本身比較簡單，LVS、HAProxy、Nginx 都可以做，關鍵問題是如何發現服務端，并根據服務端的變化，動態修改負載均衡器的配置，
在這里我們介紹一種對于 GRPC 支持比較好的負載均衡器 Envoy，其實 Envoy 不僅僅是負載均衡器，它還是一個高性能的 C++ 寫的 Proxy 轉發器，可以配置非常靈活的轉發規則，
這些規則可以是靜態的，放在組態檔中的，在啟動的時候加載，要想重新加載，一般需要重新啟動，但是 Envoy 支持熱加載和熱重啟，這在一定程度上緩解了這個問題，
當然，最好的方式是將規則設定為動態的，放在統一的地方維護，這個統一的地方在 Envoy 眼中被稱為服務發現（Discovery Service），過一段時間去這里拿一下配置，就修改了轉發策略，
無論是靜態的，還是動態的，在配置里面往往會配置四個東西，
- 第一個是 listener，Envoy 既然是 Proxy，專門做轉發，就得監聽一個埠，接入請求，然后才能夠根據策略轉發，這個監聽的埠就稱為 listener，
- 第二個是 endpoint，是目標的 IP 地址和埠，這個是 Proxy 最終將請求轉發到的地方，
- 第三個是 cluster，一個 cluster 是具有完全相同行為的多個 endpoint，也即如果有三個服務端在運行，就會有三個 IP 和埠，但是部署的是完全相同的三個服務，它們組成一個 cluster，從 cluster 到 endpoint 的程序稱為負載均衡，可以輪詢，
- 第四個是 route，有時候多個 cluster 具有類似的功能，但是是不同的版本號，可以通過 route 規則，選擇將請求路由到某一個版本號，也即某一個 cluster，
如果是靜態的，則將后端的服務端的 IP 地址拿到，然后放在組態檔里面就可以了，
如果是動態的，就需要配置一個服務發現中心，這個服務發現中心要實作 Envoy 的 API，Envoy 可以主動去服務發現中心拉取轉發策略，
看來，Envoy 行程和服務發現中心之間要經常相互通信，互相推送資料，所以 Envoy 在控制面和服務發現中心溝通的時候，就可以使用 GRPC，也就天然具備在用戶面支撐 GRPC 的能力，
Envoy 如果復雜的配置，都能干什么事呢？
一種常見的規則是配置路由策略，例如后端的服務有兩個版本，可以通過配置 Envoy 的 route，來設定兩個版本之間，也即兩個 cluster 之間的 route 規則，一個占 99% 的流量，一個占 1% 的流量，
另一種常見的規則就是負載均衡策略，對于一個 cluster 下的多個 endpoint，可以配置負載均衡機制和健康檢查機制，當服務端新增了一個，或者掛了一個，都能夠及時配置 Envoy，進行負載均衡，
所有這些節點的變化都會上傳到注冊中心，所有這些策略都可以通過注冊中心進行下發，所以，更嚴格的意義上講，注冊中心可以稱為注冊治理中心，
Envoy 這么牛，是不是能夠將服務之間的相互呼叫全部由它代理？如果這樣，服務也不用像 Dubbo，或者 Spring Cloud 一樣，自己感知到注冊中心，自己注冊，自己治理，對應用干預比較大，
如果我們的應用能夠意識不到服務治理的存在，就可以直接進行 GRPC 的呼叫，
這就是未來服務治理的趨勢 Serivce Mesh，也即應用之間的相互呼叫全部由 Envoy 進行代理，服務之間的治理也被 Envoy 進行代理，完全將服務治理抽象出來，到平臺層解決，
至此 RPC 框架中有治理功能的 Dubbo、Spring Cloud、Service Mesh 就聚齊了，
小結
- GRPC 是一種二進制，性能好，跨語言，還靈活，同時可以進行服務治理的多快好省的 RPC 框架，唯一不足就是還是要寫協議檔案，
- GRPC 序列化使用 Protocol Buffers，網路傳輸使用 HTTP 2.0，服務治理可以使用基于 Envoy 的 Service Mesh，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/211567.html
標籤：其他