grpc-go client 代码分析

Doris232 · 发表于 2021-10-26 07:48

序列化方式

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

回包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

		自动登录	找回密码
密码			立即注册

grpc-go client 代码分析

本帖子中包含更多资源