<微服務架構>—gRPC篇

簡介

gRPC 是一款高性能、開源的 RPC 框架，產自 Google，基於 ProtoBuf 序列化協議進行開發，支持多種語言（Golang、Python、Java等），本篇只介紹 Python 的 gRPC 使用。由於 gRPC 對 HTTP/2 協議的支持使其在 Android、IOS 等客戶端後端服務的開發領域具備良好的前景。gRPC 提供了一種簡單的方法來定義服務，同時客戶端能夠充分利用 HTTP/2 stream 的特性，從而有助於節省帶寬、下降 TCP 的鏈接次數、節省CPU的使用等

gRPC 默認使用 protocol buffers，這是 Google 開源的一種輕便高效的結構化數據存儲格式，能夠用於結構化數據串行化，或者說序列化。它很適合作數據存儲或 RPC 數據交換格式。

安裝

官方參考文檔

• gRPC 的安裝：

$ pip install grpcio

• 安裝 ProtoBuf 相關的 python 依賴庫：

  $ pip install protobuf

• 安裝 python grpc 的 protobuf 編譯工具：

  $ pip install grpcio-tools

實踐

定義一個消息類型

先來看一個很是簡單的例子。假設你想定義一個「搜索請求」的消息格式，每個請求含有一個查詢字符串、你感興趣的查詢結果所在的頁數，以及每一頁多少條查詢結果。能夠採用以下的方式來定義消息類型的.proto文件了：

syntax = "proto3";  // 聲明使用 proto3 語法

message SearchRequest {
  string query = 1;  // 每一個字段都要指定數據類型
  int32 page_number = 2; // 這裏的數字2 是標識符，最小的標識號能夠從1開始，最大到2^29 - 1, or 536,870,911。不可使用其中的[19000－19999]
  int32 result_per_page = 3; // 這裏是註釋，使用 //
}

• 文章的第一行指定了你正在使用 proto3 語法：若是不指定，編譯器會使用 proto2。這個指定語法必須是文件的非空非註釋的第一行。
• SearchRequest消息格式有三個字段，在消息中承載的數據分別對應於每個字段。其中每一個字段都有一個名字和一種類型。
• 向.proto文件添加註釋，可使用C/C++/java風格的雙斜槓(//) 語法格式。
• 在消息體中，每一個字段都有惟一的一個數字標識符。這些標識符用來在消息的二進制格式中識別各個字段，一旦開始使用就不能再改變。

[1,15]以內的標識號在編碼的時候會佔用一個字節。[16,2047]以內的標識號則佔用2個字節。因此應該爲那些頻繁出現的消息元素保留 [1,15]以內的標識號。切記：要爲未來有可能添加的、頻繁出現的標識號預留一些標識號。

指定字段規則

所指定的消息字段修飾符必須是以下之一：

• singular：一個格式良好的消息應該有0個或者1個這種字段（可是不能超過1個）。
• repeated：在一個格式良好的消息中，這種字段能夠重複任意屢次（包括0次）。重複的值的順序會被保留。
  在proto3中，repeated的標量域默認狀況蝦使用packed。

數值類型

一個標量消息字段能夠含有一個以下的類型——該表格展現了定義於.proto文件中的類型，以及與之對應的、在自動生成的訪問類中定義的類型：

默認值

當一個消息被解析的時候，若是被編碼的信息不包含一個特定的singular元素，被解析的對象鎖對應的域被設置位一個默認值，對於不一樣類型指定以下：

• 對於strings，默認是一個空string
• 對於bytes，默認是一個空的bytes
• 對於bools，默認是false
• 對於數值類型，默認是0
• 對於枚舉，默認是第一個定義的枚舉值，必須爲0;
• 對於消息類型（message），域沒有被設置，確切的消息是根據語言肯定的，詳見generated code guide
• 對於可重複域的默認值是空（一般狀況下是對應語言中空列表）。

嵌套類型

你能夠在其餘消息類型中定義、使用消息類型，在下面的例子中，Result消息就定義在SearchResponse消息內，如：

message SearchResponse {
  message Result {
    string url = 1;
    string title = 2;
    repeated string snippets = 3;
  }
  repeated Result results = 1;
}

在 message SearchResponse 中，定義了嵌套消息 Result，並用來定義SearchResponse消息中的results域。

Protobuf 文件編譯

從.proto文件生成了什麼？

當用protocol buffer編譯器來運行.proto文件時，編譯器將生成所選擇語言的代碼，這些代碼能夠操做在.proto文件中定義的消息類型，包括獲取、設置字段值，將消息序列化到一個輸出流中，以及從一個輸入流中解析消息。

• 對C++來講，編譯器會爲每一個.proto文件生成一個.h文件和一個.cc文件，.proto文件中的每個消息有一個對應的類。
• 對Java來講，編譯器爲每個消息類型生成了一個.java文件，以及一個特殊的Builder類（該類是用來建立消息類接口的）。
• 對Python來講，有點不太同樣——Python編譯器爲.proto文件中的每一個消息類型生成一個含有靜態描述符的模塊，，該模塊與一個元類（metaclass）在運行時（runtime）被用來建立所需的Python數據訪問類。
• 對go來講，編譯器會位每一個消息類型生成了一個.pd.go文件。
• 對於Ruby來講，編譯器會爲每一個消息類型生成了一個.rb文件。
• javaNano來講，編譯器輸出相似域java可是沒有Builder類
• 對於Objective-C來講，編譯器會爲每一個消息類型生成了一個pbobjc.h文件和pbobjcm文件，.proto文件中的每個消息有一個對應的類。
• 對於C#來講，編譯器會爲每一個消息類型生成了一個.cs文件，.proto文件中的每個消息有一個對應的類。

Python gRPC 示例

gRPC_DEMO GitHub源碼

編譯

使用如下命令編譯:

$ python -m grpc_tools.protoc -I./ --python_out=. --grpc_python_out=. ./hello.proto

生成了兩個文件：

• hello_pb2.py 此文件包含生成的 request(HelloRequest) 和 response(HelloReply) 類。
• hello_pb2_grpc.py 此文件包含生成的 客戶端(GreeterStub)和服務端(GreeterServicer)的類。

建立服務端代碼

建立和運行 Greeter 服務能夠分爲兩個部分：

• 實現咱們服務定義的生成的服務接口：作咱們的服務的實際的「工做」的函數。

• 運行一個 gRPC 服務器，監聽來自客戶端的請求並傳輸服務的響應。

建立客戶端代碼

見gRPC_DEMO GitHub源碼

運行代碼

1. 首先運行服務端代碼

   python server/main.py

2. 而後運行客戶端代碼

   python client/main.py

   輸出:
           >>> Greeter client received: Hello, goodspeed!