grpc-go client 代码分析

Doris232

序列化方式


grpc 一般在tcp 之上传输数据，tcp 是流式协议，需要定义协议来 规定接收端如何切流（从tcp data flow 拿到一个完整的包）。

一般是通过tlv 的格式来处理，类似下面的格式。
|-----type(2bytes)------|--------length(4bytes)--------|-------value(payload)------|
抓包看下 grpc 数据序列化的格式 ，可以看到除了header 外，实际的请求/响应payload 部分 是通过data 类型的frame  来发送数据的，其中 data frame 的核心 payload 部分又是通过 protobuf 序列化请求 or 响应body  ，protobuf 在这里只是一种序列化算法，换成 msgpack /json 也是可以的，当然这里更多是性能考量选择protobuf 。

frame 的序列化格式如下，
+-----------------------------------------------+|                 Length (24)                   |+---------------+---------------+---------------+|   Type (8)    |   Flags (8)   |+-+-------------+---------------+-------------------------------+|R|                 Stream Identifier (31)                      |+=+=============================================================+|                   Frame Payload (0...)                      ...+---------------------------------------------------------------+发送req

image.png

image.png

回包rsp

image.png

更细致的wire protocol 可以参考 wiki
client 端


client 端的核心是 服务发现 和 负载均衡。 其中resolver 抽象了 名字解析的接口，可以很方便的实现不同的服务发现，例如基于etcd/zk 等。

balancer 抽象了 客户端负载均衡的接口。

从对象关系维度看， grpc.ccResolverWrapper 实现了 resolver.ClientConn 接口， grpc.ccBalancerWrapper实现了 balancer.ClientConn 接口。
resolver pkg


<img width="1146" alt="图片" src="https://user-images.githubusercontent.com/44366103/132989206-05fc0863-2649-45f9-be30-c5d68c6bbe77.png">
balancer pkg


[站外图片上传中...(image-981fae-1635171550712)]
grpc  pkg


[站外图片上传中...(image-cf0ad3-1635171550712)]
后端实例上下线的数据流向


以 基于ectd  实现的服务发现为例，看看 后端实例上下线 的行为，在client端是如何处理的。从读（rpc invoke 获取某个实例）和 写 (实例上下线，) 2个方面看。以etcd resolver 和 roundrobin balancer 为例来分析。
读

image

写


[站外图片上传中...(image-e78657-1635171550712)]
subConn / addrConn  对象状态维护


[站外图片上传中...(image-56bbb2-1635171550712)]
refs


https://pingcap.com/zh/blog/grpc