gRPC入門

時間 2019-11-09

標籤 grpc 入門简体版

原文原文鏈接

時間飛逝如一名攜帶信息的郵差但那隻不過是咱們的比喻人物是杜撰的匆忙是僞裝的攜帶的也不是人的訊息

爲何使用`grpc`

主要包括如下兩點緣由：html

protocl buffer一種高效的序列化結構。
支持http 2.0標準化協議。

很對人常常拿thrift跟grpc比較，如今先不發表任何見解，後續會深刻thrift進行介紹。node

`http/2`

HTTP/2 enables a more efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple concurrent exchanges on the same connection… Specifically, it allows interleaving of request and response messages on the same connection and uses an efficient coding for HTTP header fields. It also allows prioritization of requests, letting more important requests complete more quickly, further improving performance.
The resulting protocol is more friendly to the network, because fewer TCP connections can be used in comparison to HTTP/1.x. This means less competition with other flows, and longer-lived connections, which in turn leads to better utilization of available network capacity. Finally, HTTP/2 also enables more efficient processing of messages through use of binary message framing.git

http/2帶來了網絡性能的巨大提高，下面列舉一些我的以爲比較重要的細節：github

http/2對每一個源只需建立一個持久鏈接，在這一個鏈接內，能夠並行的處理多個請求和響應，並且作到不相互影響。
容許客戶端和服務端實現本身的數據流和鏈接流控制，這對咱們傳輸大數據很是有幫助。

更多細節，請參考文章末尾的連接，固然，後續也會專門介紹。golang

`準備工做`

你們能夠參考protobuf的介紹，具體包括：web

安裝Go的開發環境，由於後續是基於Go語言的開發項目
安裝protocol-buffers
安裝protoc-gen-go，用於自動生成源碼

生成源碼的命令以下，其中，--go_out用於指定生成源碼的保存路徑；而-I是-IPATH的簡寫，用於指定查找import文件的路徑，能夠指定多個；最後的order是編譯的grpc文件的存儲路徑。apache

protoc -I proto/ proto/order.proto --go_out=plugins=grpc:order

`protocol buffer`

google開發的高效、跨平臺的數據傳輸格式。固然，本質仍是數據傳輸結構。但google賦予了它豐富的功能，好比import、package、消息嵌套等等。import用於引入別的.proto文件；package用於定義命名空間，轉換到go源碼中就是包名；repeated用於定義重複的數據；enum用於定義枚舉類型等。bash

.proto內字段的基本定義：服務器

type name = tag;

Protocol buffer自己不包含類型的描述信息，所以獲取了沒有.proto描述文件的二進制信息是毫無用處的，咱們很難提取出很是有用的信息。Go語言complier生成的文件後綴是.pb.go，它自動生成了set、get以及read、write方法，咱們能夠很方便的序列化數據。restful

下面咱們定義一個建立訂單的.proto文件，歸納的描述：buyerID在device上支付amount買sku商品。

聲明版本爲proto3，package是order。
設備類型定義爲枚舉類型，包括ANDROID和IOS兩種，並且類型被嵌套聲明在OrderParams內。
sku聲明爲repeated，由於用戶可能購買多個商品。
OrderResult爲響應的消息體結構，包括生成的訂單號和處理的響應碼。
service聲明瞭order要提供的服務。當前僅僅實現一個simple RPC：客戶端使用OrderParams參數請求RPC服務器，收到OrderResult做爲響應。

syntax = "proto3";
package order;

service Order {

    //a simple RPC
    //create new order
    rpc Add (OrderParams) returns (OrderResult) {
    }
}

message OrderParams {
    string amount = 1; //訂單金額
    int64 buyerID = 2; //購買用戶ID

    enum Device {
        IOS = 0;
        ANDROID = 1;
    }
    Device device = 3;
    repeated Sku sku = 4;
}

message Sku {
    int32 num = 1;
    string skuId = 2;
    int32 unitPrice = 3;
}

message OrderResult {
    int32 statusCode = 1;
    string orderID = 2;
}

`grpc`接口

經過定義的.proto文件生成grpc client和server端實現的接口類型。生成的內容主要包括：

protocol buffer各類消息類型的序列化操做
grpc client實現的接口類型，以及client實現的grpc方法
grpc server待實現的接口類型

`service`處理流程

第一步. 服務端爲每一個接收的鏈接建立單獨的goroutine進行處理。

第二步. 自動生成的代碼中，聲明瞭服務的具體描述，也是該服務的「路由」。包括服務名稱ServiceName以Methods、Streams。當rpc接收到新的數據時，會根據路由執行對應的方法。由於咱們的設定沒有處理流的場景，因此Streams爲空的結構體。

代碼中的服務名稱被指定爲:order.Order，對應建立訂單的方法是：Add。

var _Order_serviceDesc = grpc.ServiceDesc{
    ServiceName: "order.Order",
    HandlerType: (*OrderServer)(nil),
    Methods: []grpc.MethodDesc{
        {
            MethodName: "Add",
            Handler:    _Order_Add_Handler,
        },
    },
    Streams:  []grpc.StreamDesc{},
    Metadata: "order.proto",
}

第三步. 將路由註冊到rpc服務中。以下所示，就是將上述的路由轉換爲map對應關係的過程。類比restful風格的接口定義，等價於/order/這種請求都由這個service來進行處理。

最終將service註冊到gRPC server上。同時，咱們能夠逆向猜出服務的處理過程：經過請求的路徑獲取service，而後經過MethodName調用相應的處理方法。

srv := &service{
    server: ss,
    md:     make(map[string]*MethodDesc),
    sd:     make(map[string]*StreamDesc),
    mdata:  sd.Metadata,
}
for i := range sd.Methods {
    d := &sd.Methods[i]
    srv.md[d.MethodName] = d
}
for i := range sd.Streams {
    d := &sd.Streams[i]
    srv.sd[d.StreamName] = d
}
s.m[sd.ServiceName] = srv

第四步. gRPC服務處理請求。經過請求的:path，獲取對應的service和MethodName進行處理。

service := sm[:pos]
method := sm[pos+1:]

if srv, ok := s.m[service]; ok {
    if md, ok := srv.md[method]; ok {
        s.processUnaryRPC(t, stream, srv, md, trInfo)
        return
    }
    if sd, ok := srv.sd[method]; ok {
        s.processStreamingRPC(t, stream, srv, sd, trInfo)
        return
    }
}

經過結合protoc自動生成的client端代碼，無需抓包，咱們就能夠推斷出path的格式，以及系統是如何處理路由的。代碼中定義的：/order.Order/Add就是依據。

func (c *orderClient) Add(ctx context.Context, in *OrderParams, opts ...grpc.CallOption) (*OrderResult, error) {
    out := new(OrderResult)
    err := c.cc.Invoke(ctx, "/order.Order/Add", in, out, opts...)
    if err != nil {
        return nil, err
    }
    return out, nil
}

`建立訂單`

爲了簡單起見，咱們只保證訂單的惟一性。這裏咱們實現一個簡易版本，並且也不作過多介紹。感興趣的同窗能夠移步到另外一篇文章：探討分佈式ID生成系統去了解，畢竟不該該是本節的重心。

//上次建立訂單使用的毫秒時間
var lastTimestamp = time.Now().UnixNano() / 1000000
var sequence int64

const MaxSequence = 4096

// 42bit分配給毫秒時間戳
// 12bit分配給序列號，每4096就從新開始循環
// 10bit分配給機器ID
func CreateOrder(nodeId int64) string {
    currentTimestamp := getCurrentTimestamp()
    if currentTimestamp == lastTimestamp {
        sequence = (sequence + 1) % MaxSequence
        if sequence == 0 {
            currentTimestamp = waitNextMillis(currentTimestamp)
        }
    } else {
        sequence = 0
    }

    orderId := currentTimestamp << 22
    orderId |= nodeId << 10
    orderId |= sequence

    return strings.ToUpper(fmt.Sprintf("%x", orderId))
}

func getCurrentTimestamp() int64 {
    return time.Now().UnixNano() / 1000000
}

func waitNextMillis(currentTimestamp int64) int64 {
    for currentTimestamp == lastTimestamp {
        currentTimestamp = getCurrentTimestamp()
    }
    return currentTimestamp
}

`運行系統`

建立服務端代碼。注意：使用grpc提供的默認選項，實際上是很危險的行爲。在生產開發中，被不熟悉的默認選項坑到的狀況比比皆是。這裏的代碼不要做爲後續生產環境開發的參考。服務端的代碼相比客戶端要複雜一點，須要咱們去實現處理請求的接口。

type Order struct {
}

func (o *Order) Add(ctx context.Context, in *order.OrderParams) (*order.OrderResult, error) {
    return &order.OrderResult{
        OrderID: util.CreateOrder(1),
    }, nil
}

func main() {
    lis, err := net.Listen("tcp", "127.0.0.1:10000")
    if err != nil {
        log.Fatalf("Failed to listen: %v", err)
    }

    grpcServer := grpc.NewServer()
    order.RegisterOrderServer(grpcServer, &Order{})
    grpcServer.Serve(lis)
}

客戶端的代碼很是簡單，構造參數，處理返回就Ok了。

func createOrder(client order.OrderClient, params *order.OrderParams) {
    ctx, cancel := context.WithTimeout(context.Background(), 10*time.Second)
    defer cancel()

    orderResult, err := client.Add(ctx, params)
    if err != nil {
        log.Fatalf("%v.GetFeatures(_) = _, %v: ", client, err)
    }

    log.Println(orderResult)
}

func main() {
    conn, err := grpc.Dial("127.0.0.1:10000")
    if err != nil {
        log.Fatalf("fail to dial: %v", err)
    }
    defer conn.Close()

    client := order.NewOrderClient(conn)
    orderParams := &order.OrderParams{
        BuyerID: 10318003,
    }
    createOrder(client, orderParams)
}