gRPC-go源码（2）：ClientConn
摘要
在上一篇文章中，我们聊了聊gRPC是怎么管理一条从Client到Server的连接的。
我们聊到了gRPC拥有Resolver，用来解析地址；拥有Balancer，用来做负载均衡。
在这一篇文章中，我们将从代码的角度来分析gRPC是怎么设计Resolver和Balancer的，并会从头到尾的梳理一遍连接是怎么建立的。
1 DialContext
DialContext是客户端建立连接的入口函数，我们看看在这个函数里面做了哪些事情：
func DialContext(ctx context.Context, target string, opts ...DialOption) (conn *ClientConn, err error) {
// 1.创建ClientConn结构体
cc := &ClientConn{
target: target,
...
}
// 2.解析target
cc.parsedTarget = grpcutil.ParseTarget(cc.target, cc.dopts.copts.Dialer != nil)
// 3.根据解析的target找到合适的resolverBuilder
resolverBuilder := cc.getResolver(cc.parsedTarget.Scheme)
// 4.创建Resolver
rWrapper, err := newCCResolverWrapper(cc, resolverBuilder)
// 5.完事
return cc, nil
}
显而易见，在省略了亿点点细节之后，我们发现建立连接的过程其实也很简单，我们梳理一遍：
因为gRPC没有提供服务注册，服务发现的功能，所以需要开发者自己编写服务发现的逻辑：也就是Resolver——解析器。
在得到了解析的结果，也就是一连串的IP地址之后，需要对其中的IP进行选择，也就是Balancer。
其余的就是一些错误处理、兜底策略等等，这些内容不在这一篇文章中讲解。
2 Resolver的获取
我们从Resolver开始讲起。
cc.parsedTarget = grpcutil.ParseTarget(cc.target, cc.dopts.copts.Dialer != nil)
关于ParseTarget的逻辑我们用简单一句话来概括：获取开发者传入的target参数的地址类型，在后续查找适合这种类型地址的Resolver。
然后我们来看查找Resolver的这部分操作，这部分代码比较简单，我在代码中加了一些注释：
resolverBuilder := cc.getResolver(cc.parsedTarget.Scheme)
func (cc *ClientConn) getResolver(scheme string) resolver.Builder {
// 先查看是否在配置中存在resolver
for _, rb := range cc.dopts.resolvers {
if scheme == rb.Scheme() {
return rb
}
}
// 如果配置中没有相应的resolver，再从注册的resolver中寻找
return resolver.Get(scheme)
}
// 可以看出，ResolverBuilder是从m这个map里面找到的
func Get(scheme string) Builder {
if b, ok := m[scheme]; ok {
return b
}
return nil
}
看到这里我们可以推测：对于每个ResolverBuilder，是需要提前注册的。
我们找到Resolver的代码中，果然发现他在init()的时候注册了自己。
func init() {
resolver.Register(&passthroughBuilder{})
}
// 注册Resolver，即是把自己加入map中
func Register(b Builder) {
m[b.Scheme()] = b
}
至此，我们已经研究完了Resolver的注册和获取。
3 ResolverWrapper的创建
回到ClientConn的创建过程中，在获取到了ResolverBuilder之后，进行下一步的操作：
rWrapper, err := newCCResolverWrapper(cc, resolverBuilder)
gRPC为了实现插件式的Resolver，因此采用了装饰器模式，创建了一个ResolverWrapper。
我们看看在创建ResolverWrapper的细节：
func newCCResolverWrapper(cc *ClientConn, rb resolver.Builder) (*ccResolverWrapper, error) {
ccr := &ccResolverWrapper{
cc: cc,
done: grpcsync.NewEvent(),
}
// 根据传入的Builder，创建resolver，并放入wrapper中
ccr.resolver, err = rb.Build(cc.parsedTarget, ccr, rbo)
return ccr, nil
}
好，到了这里我们可以暂停一下。
我们停下来思考一下我们需要实现的功能：为了解耦Resolver和Balancer，我们希望能够有一个中间的部分，接收到Resolver解析到的地址，然后对它们进行负载均衡。因此，在接下来的代码阅读过程中，我们可以带着这个问题：Resolver和Balancer的通信过程是什么样的？
再看上面的代码，ClientConn的创建已经结束了。那么我们可以推测，剩下的逻辑就在rb.Build(cc.parsedTarget, ccr, rbo)这一行代码里面。
4 Resolver的创建
其实，Build并不是一个确定的方法，他是一个接口。
type Builder interface {
Build(target Target, cc ClientConn, opts BuildOptions) (Resolver, error)
}
在创建Resolver的时候，我们需要在Build方法里面初始化Resolver的各种状态。并且，因为Build方法中有一个target的参数，我们会在创建Resolver的时候，需要对这个target进行解析。
也就是说，创建Resolver的时候，会进行第一次的域名解析。并且，这个解析过程，是由开发者自己设计的。
到了这里我们会自然而然的接着考虑，解析之后的结果应该保存为什么样的数据结构，又应该怎么去将这个结果传递下去呢？
我们拿最简单的passthroughResolver来举例：
func (*passthroughBuilder) Build(target resolver.Target, cc resolver.ClientConn, opts resolver.BuildOptions) (resolver.Resolver, error) {
r := &passthroughResolver{
target: target,
cc: cc,
}
// 创建Resolver的时候，进行第一次的解析
r.start()
return r, nil
}
// 对于passthroughResolver来说，正如他的名字，直接将参数作为结果返回
func (r *passthroughResolver) start() {
r.cc.UpdateState(resolver.State{Addresses: []resolver.Address{{Addr: r.target.Endpoint}}})
}
我们可以看到，对于一个Resolver，需要将解析出的地址，传入resolver.State中，然后调用r.cc.UpdateState方法。
那么这个r.cc.UpdateState又是什么呢？
他就是我们上面提到的ccResolverWrapper。
这个时候逻辑就很清晰了，gRPC的ClientConn通过调用ccResolverWrapper来进行域名解析，而具体的解析过程则由开发者自己决定。在解析完毕后，将解析的结果返回给ccResolverWrapper。
5 Balancer的选择
我们因此也可以进行推测：在ccResolverWrapper中，会将解析出的结果以某种形式传递给Balancer。
我们接着往下看：
func (ccr *ccResolverWrapper) UpdateState(s resolver.State) {
...
// 将Resolver解析的最新状态保存下来
ccr.curState = s
// 对状态进行更新
ccr.poll(ccr.cc.updateResolverState(ccr.curState, nil))
}
关于poll方法这里就不提了，重点我们看ccr.cc.updateResolverState(ccr.curState, nil)这部分。
这里的ccr.cc中的cc，就是我们创建的ClientConn对象。
也就是说，此时Resolver解析的结果，最终又回到了ClientConn中。
注意，对于updateResolverState方法，在源码中逻辑比较深，主要是为了处理各种情况。在这里我直接把核心的那部分贴出来，所以这部分的代码你可以理解为是伪代码实现，和原本的代码是有出入的。如果你希望看到具体的实现，你可以去阅读gRPC的源码。
func (cc *ClientConn) updateResolverState(s resolver.State, err error) error {
var newBalancerName string
// 假设已经配置好了balancer，那么使用配置中的balancer
if cc.sc != nil && cc.sc.lbConfig != nil {
newBalancerName = cc.sc.lbConfig.name
}
// 否则的话，遍历解析结果中的地址，来判断应该使用哪种balancer
else {
var isGRPCLB bool
for _, a := range addrs {
if a.Type == resolver.GRPCLB {
isGRPCLB = true
break
}
}
if isGRPCLB {
newBalancerName = grpclbName
} else if cc.sc != nil && cc.sc.LB != nil {
newBalancerName = *cc.sc.LB
} else {
newBalancerName = PickFirstBalancerName
}
}
// 具体的balancer逻辑
cc.switchBalancer(newBalancerName)
// 使用balancerWrapper更新Client的状态
bw := cc.balancerWrapper
uccsErr := bw.updateClientConnState(&balancer.ClientConnState{ResolverState: s, BalancerConfig: balCfg})
return ret
}
我们再来康康switchBalancer到底做了什么：
func (cc *ClientConn) switchBalancer(name string) {
...
builder := balancer.Get(name)
cc.curBalancerName = builder.Name()
cc.balancerWrapper = newCCBalancerWrapper(cc, builder, cc.balancerBuildOpts)
}
是不是有一种似曾相识的感觉？
没错，这部分的代码，跟ResolverWrapper的创建过程很接近。都是获取到对应的Builder Name，然后通过name来获取对应的Builder，然后创建wrapper。
func newCCBalancerWrapper(cc *ClientConn, b balancer.Builder, bopts balancer.BuildOptions) *ccBalancerWrapper {
ccb := &ccBalancerWrapper{
cc: cc,
scBuffer: buffer.NewUnbounded(),
done: grpcsync.NewEvent(),
subConns: make(map[*acBalancerWrapper]struct{}),
}
go ccb.watcher()
ccb.balancer = b.Build(ccb, bopts)
return ccb
}
这里的ccb.watcher我们先不管他，这个是跟连接的状态有关的内容，我们将在下一篇文章在进行分析。
同样的，Build具体的Balancer的过程，也是由开发者自己决定的。
在Balancer的创建过程中，涉及到了连接的管理。我们同样的把这部分内容放在下一篇中。在这篇文章中我们的主线任务还是Resolver和Balancer的交互是怎么样的。
在创建完相应的BalancerWrapper之后，就来到了bw.updateClientConnState这行了。
注意，这里的bw就是我们上面创建的balancer。也就是说这里又来到了真正的Balancer逻辑。
但是这其中的代码我们在这篇文章中先不进行介绍，gRPC对于真正的HTTP/2连接的管理逻辑也比较的复杂，我们下篇文章见。
6 小结
到这里我们来总结一下：创建ClientConn的时候创建ResolverWrapper，由ClientConn通知ResolverWrapper进行域名解析。
此时，ResolverWrapper会将这个请求交给真正的Resolver，由真正的Resolver来处理域名解析。
解析完毕后，Resolver会将结果保存在ResolverWrapper中，ResolverWrapper再将这个结果返回给ClientConn。
当ClientConn发现解析的结果发生了改变，那么他就会去通知BalancerWrapper，重新进行负载均衡。
此时BalancerWrapper又会去让真正的Balancer做这件事，最终将结果返回给ClientConn。
我们画张图来展示这个过程：
写在最后
首先，谢谢你能看到这里。
这是一篇纯源码解读的文章，作为上一篇纯理论文章的补充。建议两篇文章配合一起食用：）
如果在这个过程中，你有任何的疑问，都可以留言给我，或者在公众号“红鸡菌”中找到我。
在下一篇文章中，我将向你介绍Balancer中的具体细节，也就是gRPC的底层连接管理。同样的，我应该也会用一篇文章来介绍应该怎么设计，然后再用一篇文章来介绍具体的实现，我们下篇文章再见。
再次感谢你的阅读！
