gRPC是一個現代的、高性能、開源的和語言無關的通用RPC框架，基于HTTP2協議設計，序列化使用PB(Protocol Buffer)，PB是一種語言無關的高性能序列化框架，基于HTTP2+PB保證了的高性能，go-zero是一個開源的微服務框架，支持http和rpc協議，其中rpc底層依賴gRPC，本文會結合gRPC和go-zero原始碼從實戰的角度和大家一起分析下服務注冊與發現和負載均衡的實作原理
基本原理
原理流程圖如下：
從圖中可以看出go-zero實作了gRPC的resolver和balancer介面，然后通過gprc.Register方法注冊到gRPC中，resolver模塊提供了服務注冊的功能，balancer模塊提供了負載均衡的功能，當client發起服務呼叫的時候會根據resolver注冊進來的服務串列，使用注冊進來的balancer選擇一個服務發起請求，如果沒有進行注冊gRPC會使用默認的resolver和balancer，服務地址的變更會同步到etcd中，go-zero監聽etcd的變化通過resolver更新服務串列
Resolver模塊
通過resolver.Register方法可以注冊自定義的Resolver，Register方法定義如下，其中Builder為interface型別，因此自定義resolver需要實作該介面，Builder定義如下
// Register 注冊自定義resolver
func Register(b Builder) {
m[b.Scheme()] = b
}
// Builder 定義resolver builder
type Builder interface {
Build(target Target, cc ClientConn, opts BuildOptions) (Resolver, error)
Scheme() string
}
Build方法的第一個引數target的型別為Target定義如下，創建ClientConn呼叫grpc.DialContext的第二個引數target經過決議后需要符合這個結構定義，target定義格式為： scheme://authority/endpoint_name
type Target struct {
Scheme string // 表示要使用的名稱系統
Authority string // 表示一些特定于方案的引導資訊
Endpoint string // 指出一個具體的名字
}
Build方法回傳的Resolver也是一個介面型別，定義如下
type Resolver interface {
ResolveNow(ResolveNowOptions)
Close()
}
流程圖下圖
因此可以看出自定義Resolver需要實作如下步驟：
- 定義target
- 實作resolver.Builder
- 實作resolver.Resolver
- 呼叫resolver.Register注冊自定義的Resolver，其中name為target中的scheme
- 實作服務發現邏輯(etcd、consul、zookeeper)
- 通過resolver.ClientConn實作服務地址的更新
go-zero中target的定義如下，默認的名字為discov
// BuildDiscovTarget 構建target
func BuildDiscovTarget(endpoints []string, key string) string {
return fmt.Sprintf("%s://%s/%s", resolver.DiscovScheme,
strings.Join(endpoints, resolver.EndpointSep), key)
}
// RegisterResolver 注冊自定義的Resolver
func RegisterResolver() {
resolver.Register(&dirBuilder)
resolver.Register(&disBuilder)
}
Build方法的實作如下
func (d *discovBuilder) Build(target resolver.Target, cc resolver.ClientConn, opts resolver.BuildOptions) (
resolver.Resolver, error) {
hosts := strings.FieldsFunc(target.Authority, func(r rune) bool {
return r == EndpointSepChar
})
// 獲取服務串列
sub, err := discov.NewSubscriber(hosts, target.Endpoint)
if err != nil {
return nil, err
}
update := func() {
var addrs []resolver.Address
for _, val := range subset(sub.Values(), subsetSize) {
addrs = append(addrs, resolver.Address{
Addr: val,
})
}
// 呼叫UpdateState方法更新
cc.UpdateState(resolver.State{
Addresses: addrs,
})
}
// 添加監聽，當服務地址發生變化會觸發更新
sub.AddListener(update)
// 更新服務串列
update()
return &nopResolver{cc: cc}, nil
}
那么注冊進來的resolver在哪里用到的呢？當創建客戶端的時候呼叫DialContext方法創建ClientConn的時候回進行如下操作
- 攔截器處理
- 各種配置項處理
- 決議target
- 獲取resolver
- 創建ccResolverWrapper
創建clientConn的時候回根據target決議出scheme，然后根據scheme去找已注冊對應的resolver，如果沒有找到則使用默認的resolver
ccResolverWrapper的流程如下圖，在這里resolver會和balancer會進行關聯，balancer的處理方式和resolver類似也是通過wrapper進行了一次封裝
緊著著會根據獲取到的地址創建htt2的鏈接
到此ClientConn創建程序基本結束，我們再一起梳理一下整個程序，首先獲取resolver，其中ccResolverWrapper實作了resovler.ClientConn介面，通過Resolver的UpdateState方法觸發獲取Balancer，獲取Balancer，其中ccBalancerWrapper實作了balancer.ClientConn介面，通過Balnacer的UpdateClientConnState方法觸發創建連接(SubConn)，最后創建HTTP2 Client
Balancer模塊
balancer模塊用來在客戶端發起請求時進行負載均衡，如果沒有注冊自定義的balancer的話gRPC會采用默認的負載均衡演算法，流程圖如下
在go-zero中自定義的balancer主要實作了如下步驟：
- 實作PickerBuilder，Build方法回傳balancer.Picker
- 實作balancer.Picker，Pick方法實作負載均衡演算法邏輯
- 呼叫balancer.Registet注冊自定義Balancer
- 使用baseBuilder注冊，框架已提供了baseBuilder和baseBalancer實作了Builer和Balancer
Build方法的實作如下
func (b *p2cPickerBuilder) Build(readySCs map[resolver.Address]balancer.SubConn) balancer.Picker {
if len(readySCs) == 0 {
return base.NewErrPicker(balancer.ErrNoSubConnAvailable)
}
var conns []*subConn
for addr, conn := range readySCs {
conns = append(conns, &subConn{
addr: addr,
conn: conn,
success: initSuccess,
})
}
return &p2cPicker{
conns: conns,
r: rand.New(rand.NewSource(time.Now().UnixNano())),
stamp: syncx.NewAtomicDuration(),
}
}
go-zero中默認實作了p2c負載均衡演算法，該演算法的優勢是能彈性的處理各個節點的請求，Pick的實作如下
func (p *p2cPicker) Pick(ctx context.Context, info balancer.PickInfo) (
conn balancer.SubConn, done func(balancer.DoneInfo), err error) {
p.lock.Lock()
defer p.lock.Unlock()
var chosen *subConn
switch len(p.conns) {
case 0:
return nil, nil, balancer.ErrNoSubConnAvailable // 沒有可用鏈接
case 1:
chosen = p.choose(p.conns[0], nil) // 只有一個鏈接
case 2:
chosen = p.choose(p.conns[0], p.conns[1])
default: // 選擇一個健康的節點
var node1, node2 *subConn
for i := 0; i < pickTimes; i++ {
a := p.r.Intn(len(p.conns))
b := p.r.Intn(len(p.conns) - 1)
if b >= a {
b++
}
node1 = p.conns[a]
node2 = p.conns[b]
if node1.healthy() && node2.healthy() {
break
}
}
chosen = p.choose(node1, node2)
}
atomic.AddInt64(&chosen.inflight, 1)
atomic.AddInt64(&chosen.requests, 1)
return chosen.conn, p.buildDoneFunc(chosen), nil
}
客戶端發起呼叫的流程如下，會呼叫pick方法獲取一個transport進行處理
總結
本文主要分析了gRPC的resolver模塊和balancer模塊，詳細介紹了如何自定義resolver和balancer，以及通過分析go-zero中對resolver和balancer的實作了解了自定義resolver和balancer的程序，同時還分析可客戶端創建的流程和呼叫的流程，希望本文能給大家帶來一些幫助
專案地址
https://github.com/tal-tech/go-zero
如果覺得文章不錯，歡迎 github 點個 star ??
專案地址：
https://github.com/tal-tech/go-zero
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/230903.html
標籤：其他
上一篇：29 常用工具類(一)