5分钟学会 gRPC

原创

crossoverJie 2022-09-07 21:28:13 ©著作权

文章标签 服务端客户端负载均衡 文章分类 虚拟化云计算

©著作权归作者所有：来自51CTO博客作者crossoverJie的原创作品，请联系作者获取转载授权，否则将追究法律责任

5分钟学会 gRPC_客户端

介绍

我猜测大部分长期使用 Java 的开发者应该较少会接触 gRPC，毕竟在 Java 圈子里大部分使用的还是 Dubbo/SpringClound 这两类服务框架。

我也是近段时间有机会从零开始重构业务才接触到 gRPC 的，当时选择 gRPC 时也有几个原因：

5分钟学会 gRPC_负载均衡_02

基于云原生的思路开发部署项目，而在云原生中gRPC 几乎已经是标准的通讯协议了。
开发语言选择了 Go，在 Go 圈子中gRPC 显然是更好的选择。
公司内部有部分业务使用的是Python 开发，在多语言兼容性上 gRPC 支持的非常好。

经过线上一年多的平稳运行，可以看出 gRPC 还是非常稳定高效的；rpc 框架中最核心的几个要点：

序列化
通信协议
IDL（接口描述语言）

这些在 gRPC 中分别对应的是：

基于Protocol Buffer 序列化协议，性能高效。
基于HTTP/2 标准协议开发，自带 stream、多路复用等特性；同时由于是标准协议，第三方工具的兼容性会更好（比如负载均衡、监控等）
编写一份.proto 接口文件，便可生成常用语言代码。

HTTP/2

学习 gRPC 之前首先得知道它是通过什么协议通信的，我们日常不管是开发还是应用基本上接触到最多的还是 HTTP/1.1 协议。

5分钟学会 gRPC_客户端_03

由于 HTTP/1.1 是一个文本协议，对人类非常友好，相反的对机器性能就比较低。

需要反复对文本进行解析，效率自然就低了；要对机器更友好就得采用二进制，HTTP/2 自然做到了。

除此之外还有其他优点：

多路复用：可以并行的收发消息，互不影响
HPACK 节省 header 空间，避免 HTTP1.1 对相同的 header 反复发送。

Protocol

gRPC 采用的是 Protocol 序列化，发布时间比 gRPC 早一些，所以也不仅只用于 gRPC，任何需要序列化 IO 操作的场景都可以使用它。

它会更加的省空间、高性能；之前在开发 https://github.com/crossoverJie/cim 时就使用它来做数据交互。

package order.v1;

service OrderService{

  rpc Create(OrderApiCreate) returns (Order) {}

  rpc Close(CloseApiCreate) returns (Order) {}

  // 服务端推送
  rpc ServerStream(OrderApiCreate) returns (stream Order) {}

  // 客户端推送
  rpc ClientStream(stream OrderApiCreate) returns (Order) {}

  // 双向推送
  rpc BdStream(stream OrderApiCreate) returns (stream Order) {}
}

message OrderApiCreate{
  int64 order_id = 1;
  repeated int64 user_id = 2;
  string remark = 3;
  repeated int32 reason_id = 4;
}

使用起来也是非常简单的，只需要定义自己的 .proto 文件，便可用命令行工具生成对应语言的 SDK。

具体可以参考官方文档：https://grpc.io/docs/languages/go/generated-code/

调用

 protoc --go_out=. --go_opt=paths=source_relative \
    --go-grpc_out=. --go-grpc_opt=paths=source_relative \
    test.proto

5分钟学会 gRPC_服务端_04 生成代码之后编写服务端就非常简单了，只需要实现生成的接口即可。

func (o *Order) Create(ctx context.Context, in *v1.OrderApiCreate) (*v1.Order, error) {
 // 获取 metadata
 md, ok := metadata.FromIncomingContext(ctx)
 if !ok {
  return nil, status.Errorf(codes.DataLoss, "failed to get metadata")
 }
 fmt.Println(md)
 fmt.Println(in.OrderId)
 return &v1.Order{
  OrderId: in.OrderId,
  Reason:  nil,
 }, nil
}

5分钟学会 gRPC_服务端_05

客户端也非常简单，只需要依赖服务端代码，创建一个 connection 然后就和调用本地方法一样了。

这是经典的 unary(一元)调用，类似于 http 的请求响应模式，一个请求对应一次响应。

5分钟学会 gRPC_负载均衡_06

Server stream

gRPC 除了常规的 unary 调用之外还支持服务端推送，在一些特定场景下还是很有用的。

5分钟学会 gRPC_负载均衡_07

func (o *Order) ServerStream(in *v1.OrderApiCreate, rs v1.OrderService_ServerStreamServer) error {
 for i := 0; i < 5; i++ {
  rs.Send(&v1.Order{
   OrderId: in.OrderId,
   Reason:  nil,
  })
 }
 return nil
}

服务端的推送如上所示，调用 Send 函数便可向客户端推送。

 for {
  msg, err := rpc.RecvMsg()
  if err == io.EOF {
   marshalIndent, _ := json.MarshalIndent(msgs, "", "\t")
   fmt.Println(msg)
   return
  }
 }

客户端则通过一个循环判断当前接收到的数据包是否已经截止来获取服务端消息。

为了能更直观的展示这个过程，优化了之前开发的一个 gRPC 客户端，可以直观的调试 stream 调用。

5分钟学会 gRPC_负载均衡_08

上图便是一个服务端推送示例。

Client Stream

5分钟学会 gRPC_服务端_09

除了支持服务端推送之外，客户端也支持。

客户端在同一个连接中一直向服务端发送数据，服务端可以并行处理消息。


// 服务端代码
func (o *Order) ClientStream(rs v1.OrderService_ClientStreamServer) error {
 var value []int64
 for {
  recv, err := rs.Recv()
  if err == io.EOF {
   rs.SendAndClose(&v1.Order{
    OrderId: 100,
    Reason:  nil,
   })
   log.Println(value)
   return nil
  }
  value = append(value, recv.OrderId)
  log.Printf("ClientStream receiv msg %v", recv.OrderId)
 }
 log.Println("ClientStream finish")
 return nil
}

 // 客户端代码
 for i := 0; i < 5; i++ {
  messages, _ := GetMsg(data)
  rpc.SendMsg(messages[0])
 }
 receive, err := rpc.CloseAndReceive()

代码与服务端推送类似，只是角色互换了。

5分钟学会 gRPC_客户端_10

Bidirectional Stream

5分钟学会 gRPC_负载均衡_11

同理，当客户端、服务端同时都在发送消息也是支持的。

// 服务端
func (o *Order) BdStream(rs v1.OrderService_BdStreamServer) error {
 var value []int64
 for {
  recv, err := rs.Recv()
  if err == io.EOF {
   log.Println(value)
   return nil
  }
  if err != nil {
   panic(err)
  }
  value = append(value, recv.OrderId)
  log.Printf("BdStream receiv msg %v", recv.OrderId)
  rs.SendMsg(&v1.Order{
   OrderId: recv.OrderId,
   Reason:  nil,
  })
 }
 return nil
}
// 客户端
 for i := 0; i < 5; i++ {
  messages, _ := GetMsg(data)
  // 发送消息
  rpc.SendMsg(messages[0])
  // 接收消息
  receive, _ := rpc.RecvMsg()
  marshalIndent, _ := json.MarshalIndent(receive, "", "\t")
  fmt.Println(string(marshalIndent))
 }
 rpc.CloseSend()

其实就是将上诉两则合二为一。

5分钟学会 gRPC_服务端_12

通过调用示例很容易理解。

元数据

gRPC 也支持元数据传输，类似于 HTTP 中的 header。

 // 客户端写入
 metaStr := `{"lang":"zh"}`
 var m map[string]string
 err := json.Unmarshal([]byte(metaStr), &m)
 md := metadata.New(m)
 // 调用时将 ctx 传入即可
 ctx := metadata.NewOutgoingContext(context.Background(), md)
 
 // 服务端接收
 md, ok := metadata.FromIncomingContext(ctx)
 if !ok {
  return nil, status.Errorf(codes.DataLoss, "failed to get metadata")
 }
 fmt.Println(md)