目錄

RPC

RPC（Remote Procedure Call，遠程程序呼叫），是一個計算機通信協議，該協議允許運行于一臺計算機的程式呼叫另一臺計算機的子程式，而程式員無需額外地為這個互動作用編程，如果涉及的軟體采用面向物件編程，那么遠程程序呼叫亦可稱作 “遠程函式/方法呼叫”，

簡而言之，RPC 就是實作不同服務之間的相互呼叫的協議，這個不同服務可以是本地服務，也可以是互聯網上的遠程服務，

gRPC

A high-performance, open-source universal RPC framework.

gRPC（Google Remote Procedure Call，谷歌遠程程序呼叫）是 Google 發布的基于 HTTP 2.0 協議承載的高性能、開源和通用的 RPC 框架，提供了 C、Java 和 Go 語言版本，分別是：grpc、grpc-java 和 grpc-go，

• 官方網頁：https://grpc.io/

gRPC 基于 HTTP/2 協議設計，帶來諸如雙向流、流控、頭部壓縮、單 TCP 連接上的多復用請求等特，這些特性使得其在移動設備上表現更好，更省電和節省空間占用，

gRPC 提供了 protocol buffer 編譯插件，能夠從一個服務定義的 .proto 檔案生成客戶端和服務端代碼，通常 gRPC 用戶可以在服務端實作這些 API，并從客戶端呼叫它們，

• 在服務側，服務端實作服務介面，運行一個 gRPC 服務器來處理客戶端呼叫，gRPC 底層架構會解碼傳入的請求，執行服務方法，編碼服務應答，

• 在客戶側，客戶端有一個存根實作了服務端同樣的方法，客戶端可以在本地存根呼叫這些方法，用合適的 protocol buffer 訊息型別封裝這些引數，gRPC 來負責發送請求給服務端并回傳服務端 protocol buffer 回應，

gRPC vs. REST

gRPC 和 REST 都提供了一套 C/S 通信機制，而且它們都基于 HTTP 作為底層的傳輸協議，但嚴格地說，gRPC 使用的是 HTTP/2，REST 則不對協議版本有要求，

gRPC 的優勢如下：

• gRPC 可以通過 protobuf 來定義介面，從而可以具有更加嚴格的介面約束條件，
• gRPC 通過 protobuf 可以將資料序列化為二進制編碼，大幅減少了需要傳輸的資料量，從而大幅提高性能，
• gRPC 支持流式（Streaming）通信，理論上基于 HTTP/2 就可以使用 Streaming 模式，但是通常使用 REST 的 Web Service 很少這么用，流式資料應用常見與視頻流一類，但一般會使用專門的協議如：HLS，RTMP 等，

gRPC 的使用場景

• 需要對介面進行嚴格約束的情況，比如我們對外提供了一個公共的服務，這時我們就會希望對傳輸的資料有更加嚴格的約束，尤其是考慮到安全性的因素，這時 gRPC 就可以通過 protobuf 來提供嚴格的介面約束，

• 對于性能有更高的要求時，也可以考慮使用 gRPC，因為通過 protobuf 我們可以將資料壓縮編碼轉化為二進制格式，通常傳遞的資料量要小得多，而且通過 HTTP/2 還可以實作異步的請求，從而大大提高了通信效率，

通常的，我們不會單獨使用 gRPC，而是將 gRPC 作為一個部件，因為在大并發的生產環境中，我們通常選擇使用分布式系統來進行處理，而 gRPC 并沒有提供分布式系統相關的一些必要組件，而且，真正的線上服務還需要提供包括負載均衡，限流熔斷，監控報警，服務注冊和發現等等必要的組件，

Protocol Buffers

Protocol Buffers 是一種更加靈活、高效的資料格式，與 XML、JSON 類似，在一些高性能且對回應速度有要求的資料傳輸場景非常適用，

Protoco Buffers 在 gRPC 的框架中主要有三個作用：

1. 定義資料結構，
2. 定義資料結構，
3. 通過序列化和反序列化，提升傳輸效率，

我們使用 XML、JSON 進行資料編譯時，資料文本格式會更易于閱讀，但進行資料交換時，就需要耗費大量的 CPU 在 I/O 動作上，自然會影響整個傳輸速率，Protocol Buffers 則會將字串進行序列化后再進行傳輸，即二進制資料，

從編碼的角度，可以看到其實兩者內容相差不大，都非常直觀，但 Protocol Buffers 編碼的內容是面向操作者閱讀的，實際上并不會以這種文本形式進行傳輸，而是序列化后的二進制資料，位元組數會比 JSON、XML 的位元組數少很多，速率更快，

Protocol Buffers 自帶一個編譯器也是其一大優勢，前面提到的 .proto 檔案就是通過編譯器進行編譯的，.proto 檔案需要編譯生成一個類似庫檔案，基于庫檔案才能真正開發資料應用，

另外，Protocol Buffers 還具有跨語言的優勢，

小結 Protocol Buffers 同比于 XML、JSON 的優勢：

1. 簡單，體積小，資料描述檔案大小只有 1/10 至 1/3；
2. 傳輸和決議的速率快，相比 XML 等，決議速度提升 20 倍甚至更高；
3. 可編譯性強；
4. 跨語言，

gRPC 的服務定義

正如其他 RPC 系統，gRPC 基于如下思想：定義一個服務，指定其可以被遠程呼叫的方法及其引數和回傳型別，gRPC 默認使用 protocol buffers 作為介面定義語言，以此來描述服務介面和有效載荷訊息結構，當然，如果有需要的話，也可以使用其他替代方案，

service HelloService {
  rpc SayHello (HelloRequest) returns (HelloResponse);
}

message HelloRequest {
  required string greeting = 1;
}

message HelloResponse {
  required string reply = 1;
}

gRPC 支持定義四類服務方法：

1. 單項 RPC，即：客戶端發送一個請求給服務端，從服務端獲取一個應答，就像一次普通的函式呼叫，

rpc SayHello(HelloRequest) returns (HelloResponse){}

2. 服務端流式 RPC，即：客戶端發送一個請求給服務端，然后服務端可獲取一個資料流用來讀取一系列訊息，客戶端從回傳的資料流里一直讀取直到沒有更多訊息為止，

rpc LotsOfReplies(HelloRequest) returns (stream HelloResponse){}

3. 客戶端流式 RPC，即：客戶端用提供的一個資料流寫入并發送一系列訊息給服務端，一旦客戶端完成訊息寫入，就等待服務端讀取這些訊息并回傳應答，

rpc LotsOfGreetings(stream HelloRequest) returns (HelloResponse) {}

4. 雙向流式 RPC，即：兩邊都可以分別通過一個讀寫資料流來發送一系列訊息，這兩個資料流操作是相互獨立的，所以客戶端和服務端能按其希望的任意順序讀寫，例如：服務端可以在寫應答前等待所有的客戶端訊息，或者它可以先讀一個訊息再寫一個訊息，或者是讀寫相結合的其他方式，每個資料流里訊息的順序會被保持，

rpc BidiHello(stream HelloRequest) returns (stream HelloResponse){}

gRPC 的安全認證

gRPC 被設計成可以利用插件的形式支持多種安全認證機制，

• SSL/TLS：gRPC 集成 SSL/TLS 對客戶端和服務端的資料交換進行了加密，對客戶端來講，提供了可選的憑證機制來獲得共同的授權，
• Google OAuth 2.0：值得注意的是，Google OAuth2 憑證應該僅用于連接 Google 的服務，把 Google 對應的 OAuth2 令牌發往非 Google 的服務會導致令牌被竊取用作冒充客戶端來訪問 Google 的服務，

參考檔案

http://doc.oschina.net/grpc?t=60133