成人免费xxxxx在线视频软件_久久精品久久久_亚洲国产精品久久久_天天色天天色_亚洲人成一区_欧美一级欧美三级在线观看

寫給Go開發者的gRPC教程-服務發現與負載均衡

開發 前端
用通俗易懂的方式來解釋下什么是服務發現。通常情況下客戶端需要知道服務端的IP+端口號才能建立連接,但服務端的IP和端口號并不是那么容易記憶。還有更重要的,在云部署的環境中,服務端的IP和端口可能隨時會發生變化。

對于一個客戶端創建請求的過程

conn, err := grpc.Dial("example:8009", grpc.WithInsecure())
if err != nil {
  panic(err)
}
  1. gRPC客戶端通過服務發現解析請求,將名稱解析為一個或多個IP地址,以及服務配置
  2. 客戶端使用上一步的服務配置、ip列表、實例化負載均衡策略
  3. 負載均衡策略為每個服務器地址創建一個子通道(channel),并監測每一個子通道狀態
  4. 當有rpc請求時,負載均衡策略決定那個子通道即gRPC服務器將接收請求,當可用服務器為空時客戶端的請求將被阻塞

gRPC官方提供了基本的服務發現和負載均衡邏輯,并提供了接口供擴展用于開發自定義的服務發現與負載均衡

服務發現

用通俗易懂的方式來解釋下什么是服務發現。通常情況下客戶端需要知道服務端的IP+端口號才能建立連接,但服務端的IP和端口號并不是那么容易記憶。還有更重要的,在云部署的環境中,服務端的IP和端口可能隨時會發生變化。

所以我們可以給某一個服務起一個名字,客戶端通過名字創建與服務端的連接,客戶端底層使用服務發現系統,解析這個名字來獲取真正的IP和端口,并在服務端的IP和端口發生變化時,重新建立連接。這樣的系統通常也會被叫做name-system(名字服務)

gRPC 中的默認name-system是 DNS,同時在客戶端以插件形式提供了自定義name-system的機制。

名字格式

gRPC采用的名字格式遵循的RFC 3986中定義的URI語法

scheme:[//[user[:password]@]host[:port]][/path][?query][#fragment]

例如

URI示例URI示例

gRPC關注其中兩部分

  • URI scheme:第一個:前面的標識。對于gRPC客戶端來說,它指示要使用的服務發現解析器,如果未指定前綴或方案未知,則默認使用DNS方案
  • URI path:指示要解析的名字

大部分gRPC實現默認支持以下的URI schemes

  • dns:[//authority/]host[:port] -- DNS (default)
  • unix:path, unix://absolute_path -- Unix domain sockets (Unix systems only)
  • unix-abstract:abstract_path -- Unix domain socket in abstract namespace (Unix systems only)

服務的服務注冊

如果gRPC服務端的地址是靜態的,可以在客戶端服務發現時直接解析為靜態的地址

如果gRPC服務端的地址是動態的,可以有兩種選擇

  • 自注冊:當gRPC的服務啟動后,向一個集中的注冊中心進行注冊
  • 平臺的服務發現:使用k8s平臺時,平臺會感知gPRC實例的變化

關于服務注冊這里不在做更多介紹了

客戶端的服務發現

自定義服務發現需要在客戶端啟動前,注冊一個服務解析器(Resolve)

Golang中使用google.golang.org/grpc/resolver.Register(resolver.Builder)注冊,這個函數不是直接接收一個解析器,而是使用工廠模式接收一個解析器的構造器

type Builder interface {
 // Build creates a new resolver for the given target.
 //
 // gRPC dial calls Build synchronously, and fails if the returned error is
 // not nil.
 Build(target Target, cc ClientConn, opts BuildOptions) (Resolver, error)
 // Scheme returns the scheme supported by this resolver.
 // Scheme is defined at https://github.com/grpc/grpc/blob/master/doc/naming.md.
 Scheme() string
}

? Scheme()需要返回的就是名字格式中提到的URI scheme

? Build(...)需要返回一個服務發現解析器google.golang.org/grpc/resolver.Resolver

??cc ClientConn代表客戶端與服務端的連接,其擁有的cc.UpdateState(State) error可以讓我們更新鏈接的狀態

type Resolver interface {
 // ResolveNow will be called by gRPC to try to resolve the target name
 // again. It's just a hint, resolver can ignore this if it's not necessary.
 //
 // It could be called multiple times concurrently.
  // ResolveNow 嘗試再一次對域名進行解析,在個人實踐中,服務端進程掛掉會觸發該調用
 ResolveNow(ResolveNowOptions)
  // Close closes the resolver.
  // 資源釋放。
 Close()
}

解析器需要有能力從注冊中心獲取解析結果,并更新客戶端中連接(cc ClientConn)的信息。還可以持續watch一個名字的解析結果,實時的更新客戶端中連接的信息

  • 解析出來的地址列表(包含ip和port)
  • 針對連接的服務配置,如負載均衡等,來想覆蓋全局的負責均衡配置
  • 每一個地址可以包含一系列的屬性(kv),他們可以用來支持后續的負載均衡策略

示例代碼

gRPC resolver 原理

?? 在 init() 階段時

  • 創建并注冊Builder 實例,將其注冊到 grpc 內部的 resolveBuilder 表中(其實是一個全局 map,key 為協議名;value 為構造的 resolveBuilder)

?? 客戶端啟動時通過自定義Dail()方法構造grpc.ClientConn單例

  • grpc.DialContext() 方法內部解析 URI,分析協議類型,并從 resolveBuilder 表中查找協議對應的 resolverBuilder
  • 將地址作為 Target 、conn單例作為resolver.ClientConn參數調用 resolver.Build 方法實例化出 Resolver
  • 用戶 Resolver實現中調用 cc.UpdateState 傳入 State.Addresses 地址,gRPC使用這個地址建立連接,傳入State.ServiceConfig,gRPC使用這份服務配置覆蓋默認配置

name-reslover原理name-reslover原理

代碼

# builder.go
package resolver

import "google.golang.org/grpc/resolver"

var _ resolver.Builder = Builder{}

type Builder struct {
 addrsStore map[string][]string
}

func NewResolverBuilder(addrsStore map[string][]string) *Builder {
 return &Builder{addrsStore: addrsStore}
}

func (b Builder) Build(target resolver.Target, cc resolver.ClientConn, opts resolver.BuildOptions) (resolver.Resolver, error) {
 r := &Resolver{
  target:     target,
  cc:         cc,
  addrsStore: b.addrsStore,
 }
 r.Start()
 return r, nil
}

func (b Builder) Scheme() string {
 return "example"
}
# resolver.go
package resolver

import (
 "google.golang.org/grpc/resolver"
)

var _ resolver.Resolver = &Resolver{}

// impl google.golang.org/grpc/resolver.Resolver
type Resolver struct {
 target resolver.Target
 cc     resolver.ClientConn

 addrsStore map[string][]string
}

func (r *Resolver) Start() {
 // 在靜態路由表中查詢此 Endpoint 對應 addrs
 var addrs []resolver.Address
 for _, addr := range r.addrsStore[r.target.URL.Opaque] {
  addrs = append(addrs, resolver.Address{Addr: addr})
 }

 r.cc.UpdateState(resolver.State{
  Addresses: addrs,
    // 設置負載均衡策略為round_robin
  ServiceConfig: r.cc.ParseServiceConfig(
    `{"loadBalancingPolicy":"round_robin"}`),
 })
}

func (r *Resolver) ResolveNow(resolver.ResolveNowOptions) {

}

func (r *Resolver) Close() {

}
# main.go
package main

import (
 "context"
 "log"

 rs "github.com/liangwt/note/grpc/name_resolver_lb_example/client/resolver"
 pb "github.com/liangwt/note/grpc/name_resolver_lb_example/ecommerce"
 "google.golang.org/grpc"
 "google.golang.org/grpc/resolver"
)

func main() {
 resolver.Register(rs.NewResolverBuilder(map[string][]string{
  "cluster@callee": {
   "127.0.0.1:8009",
  },
 }))

 conn, err := grpc.Dial("example:cluster@callee", grpc.WithInsecure())
 if err != nil {
  panic(err)
 }
  
 // ...
}

負載均衡

同樣來通俗易懂的解釋下什么負載均衡。為了提高系統的負載能力和穩定性,我們的服務端往往具有多臺服務器,負載均衡的目的就是希望請求能分散到不同的服務器,從服務器列表中選擇一臺服務器的算法就是負載均衡的策略,常見的輪循、加權輪詢等

負載均衡器要在多臺服務器之間選擇,所以通常情況下負載均衡器是具備服務發現的能力的

根據負載均衡實現所在的位置不同,通常可分為以下三種解決方案:

1、集中式負載均衡(Proxy Model)

在客戶端和服務端之間有一個獨立的LB,通常是專門的硬件設備如 F5,或者基于軟件如 LVS,HAproxy,Nginx等實現。LB使用負載均衡策略將請求轉發到目標服務

因為所有服務調用流量都經過LB,當服務數量和調用量大的時候,LB容易成為瓶頸;一旦LB發生故障影響整個系統;客戶端、服務端之間增加了一級,有一定性能開銷

圖片集中式負載均衡

2、客戶端負載均衡(Balancing-aware Client)

客戶端負載將LB的功能集成到客戶端進程里,然后使用負載均衡策略選擇一個目標服務地址,向目標服務發起請求。LB能力被分散到每一個服務消費者的進程內部,同時服務消費方和服務提供方之間是直接調用,沒有額外開銷,性能比較好。

但如果有多種不同的語言棧,就要配合開發多種不同的客戶端,有一定的研發和維護成本;后續如果要對客戶庫進行升級,勢必要求服務調用方修改代碼并重新發布,升級較復雜。

圖片客戶端負載均衡

3、獨立負載均衡進程(External Load Balancing Service)

將LB從進程內移出來,變成主機上的一個獨立進程。主機上的一個或者多個服務要訪問目標服務時,他們都通過同一主機上的獨立LB進程做負載均衡

此方案有兩種模式

第一種是直接由LB進行轉發請求,被稱為sidecar方案

第二種是從LB獲取到IP后依舊由客戶端發起請求,gRPC曾經支持過此方案叫lookaside方案,目前已廢棄

該方案也是一種分布式方案沒有單點問題,一個LB進程掛了只影響該主機上的客戶端;客戶端和LB之間是本地調用調用性能好;同時該方案還簡化了客戶端,不需要為不同語言開發客戶庫,LB的升級不需要服務調用方改代碼。該方案主要問題:部署較復雜,環節多,出錯調試排查問題不方便

獨立負載均衡進程獨立負載均衡進程


gRPC的負載均衡

上文介紹的三種負載均衡方式,集中式負載均衡和gRPC無關,屬于外部的基礎設施,因此我們不再介紹

gRPC中的負載平衡是以每次調用為基礎,而不是以每個連接為基礎。換句話說,即使所有的請求都來自一個客戶端,它仍能在所有的服務器上實現負載平衡

gRPC目前內置四種策略

?? pick_first:默認策略,選擇第一個

?? round_robin:輪詢

使用默認的負載均衡器很簡單,只需要在建立連接的時候指定負載均衡策略即可。

?? 注意

舊版本gRPC使用 grpc.WithBalancerName("round_robin"),已經被廢棄,使用grpc.WithDefaultServiceConfig。

grpc.WithDefaultServiceConfig可以被上文服務發現中提到的cc.UpdateState(State) error覆蓋配置

conn, err := grpc.Dial("example:cluster@callee",
  grpc.WithInsecure(),
  grpc.WithDefaultServiceConfig(
   `{"loadBalancingPolicy":"round_robin"}`,
  ),
 )

?? grpclb:已廢棄

它屬于上文介紹的負載均衡中獨立負載均衡進程第二種。不必直接在客戶端中添加新的LB策略,而只實現諸如round-robin之類的簡單算法,任何更復雜的算法都將由lookaside負載平衡器提供

gRPC的grpclb方案gRPC的grpclb方案

?? xDS

如果接觸過servicemesh那么對xDS并不會陌生,xDS 本身是Envoy中的概念,現在已經發展為用于配置各種數據平面軟件的標準,最新版本的gRPC已經支持xDS。不同于單純的負載均衡策略,xDS在gRPC包含了服務發現和負載均衡的概念

這里簡單的理解下xDS,本質上xDS就是一個標準的協議

它規定了xDS客戶端和xDS服務端的交互流程,即API調用的順序

我們在xDS 服務端實現服務發現,配置負載均衡策略等等,支持xDS的客戶端連接到xDS 服務端并通過xDS api來獲取各種需要的數據和配置

xDS主要應用于servicemesh中,在mesh中由sidecar連接到xDS server進行數據交互,同時由sidecar來控制流量的分發。也就是上文提到的獨立負載均衡進程的第一種模式

servicemesh的負載均衡servicemesh的負載均衡

gRPC使用xDS是一種無proxy的客戶端負載均衡方案。對比Mesh方案,性能更好。我們把servicemesh的負載均衡和grpc的xds負載均衡放在一起感受下區別

gRPC的xDS的方案

?? 這意味著,grpclb廢棄后,gRPC內置的pick_first、round_robin、xDS三種模式都屬于客戶端的負載均衡模式。pick_first、round_robin是單純的負載均衡策略;xDS包含了服務發現等一系列能力,并且還在不斷拓展中,而我們控制gRPC的行為也被轉移到了xDS server上了。

xDS模式的使用

xDS內容較多,又比較新,單獨開個章節介紹下xDS的使用

gRPC xDS架構中出現了三個服務

  • xDS server:它是我們的控制面
  • gRPC client:它既是gRPC服務的客戶端,同時也是xDS的客戶端
  • gRPC server:它是gRPC服務的服務端,它需要具備被xDS server發現的能力

我們可以使用 Envoy go-control-plane庫來實現xDS server,這部分的開發類似于servicemesh,就不介紹太多了,如果位于k8s平臺內可以參考下istio中控制面的實現

gRPC server需要自注冊或者托管到k8s平臺,如果托管到k8s則可以繼續參考istio中控制面的實現

因為xDS也包含了服務發現的部分,因此對于client來說第一步需要先開發自定義的服務發現和負載均衡配置。幸運的是gRPC官方已經為我們開發了對應實現,只需要引入包即可,在init階段會注冊xDS的解析器和負載均衡器

_ "google.golang.org/grpc/xds" // To install the xds resolvers and balancers.

隨后只需要把gRPC client連接到xDs server即可,這部分與非xDS并無不同。只是目標服務的地址的URI scheme為xds

conn, err := grpc.Dial("xds:///localhost:50051", grpc.WithTransportCredentials(creds))
if err != nil {
  panic(err)
}

ctx, cancelFn := context.WithCancel(context.Background())
defer cancelFn()

c := pb.NewOrderManagementClient(conn)
res, err := c.AddOrder(ctx, &order)

完整代碼可以參考:https://github.com/grpc/grpc-go/tree/master/examples/features/xds

自定義負載均衡器

自定義負載均衡器需要使用google.golang.org/grpc/balancer.Register提前注冊,此函數和服務發現一樣接受工廠函數

// Builder creates a balancer.
type Builder interface {
 // Build creates a new balancer with the ClientConn.
 Build(cc ClientConn, opts BuildOptions) Balancer
 // Name returns the name of balancers built by this builder.
 // It will be used to pick balancers (for example in service config).
 Name() string
}

? Name()是負載均衡策略的名字

? Build(...)需要返回負載均衡器

?? cc ClientConn代表客戶端與服務端的連接,其擁有一系列函數可以讓我們更新鏈接的狀態

type Balancer interface {
 // UpdateClientConnState is called by gRPC when the state of the ClientConn
 // changes.  If the error returned is ErrBadResolverState, the ClientConn
 // will begin calling ResolveNow on the active name resolver with
 // exponential backoff until a subsequent call to UpdateClientConnState
 // returns a nil error.  Any other errors are currently ignored.
 UpdateClientConnState(ClientConnState) error
 // ResolverError is called by gRPC when the name resolver reports an error.
 ResolverError(error)
 // UpdateSubConnState is called by gRPC when the state of a SubConn
 // changes.
 UpdateSubConnState(SubConn, SubConnState)
 // Close closes the balancer. The balancer is not required to call
 // ClientConn.RemoveSubConn for its existing SubConns.
 Close()
}

負載均衡器需要實現一系列的函數用于gRPC在不同場景下調用

類RR算法負載均衡器

如果要實現一個類round_robin的負載均衡策略,gRPC官方實現提供了一個baseBuilder,它已經實現了大部Balancer接口,可以大幅簡化了我們創建RR策略的邏輯。使用google.golang.org/grpc/balancer/base.NewBalancerBuilder創建負載均衡的工廠

func NewBalancerBuilder(name string, pb PickerBuilder, config Config) balancer.Builder
  • name string負載均衡器的名字
  • pb PickerBuilder是我們要實現的負載均衡策略邏輯的地方
  • config Config可以配置是否要進行健康檢查
// PickerBuilder creates balancer.Picker.
type PickerBuilder interface {
 // Build returns a picker that will be used by gRPC to pick a SubConn.
 Build(info PickerBuildInfo) balancer.Picker
}
type Picker interface {
  // 子連接選擇
 Pick(info PickInfo) (PickResult, error)
}

于是借助base.NewBalancerBuilder我們僅需要實現Picker一個函數即可實現類RR的負載均衡策略了

代碼

利用Picker接口來實現一個隨機選擇策略

# builder.go
package balancer

import (
 "google.golang.org/grpc/balancer"
 "google.golang.org/grpc/balancer/base"
)

var _ base.PickerBuilder = &Builder{}

type Builder struct {
}

func NewBalancerBuilder() balancer.Builder {
 return base.NewBalancerBuilder("random_picker", &Builder{}, base.Config{HealthCheck: true})
}

func (b *Builder) Build(info base.PickerBuildInfo) balancer.Picker {
 if len(info.ReadySCs) == 0 {
  return base.NewErrPicker(balancer.ErrNoSubConnAvailable)
 }

 var scs []balancer.SubConn
 for subConn := range info.ReadySCs {
  scs = append(scs, subConn)
 }

 return &Picker{
  subConns: scs,
 }
}
// picker.go
package balancer

import (
 "math/rand"

 "google.golang.org/grpc/balancer"
)

var _ balancer.Picker = &Picker{}

type Picker struct {
 subConns []balancer.SubConn
}

func (p *Picker) Pick(info balancer.PickInfo) (balancer.PickResult, error) {
 index := rand.Intn(len(p.subConns))
 sc := p.subConns[index]
 return balancer.PickResult{SubConn: sc}, nil
}
#client.go
package main

import (
 "context"
 "log"

 bl "github.com/liangwt/note/grpc/name_resolver_lb_example/client/balancer"
 rs "github.com/liangwt/note/grpc/name_resolver_lb_example/client/resolver"
 pb "github.com/liangwt/note/grpc/name_resolver_lb_example/ecommerce"
 "google.golang.org/grpc"
 "google.golang.org/grpc/balancer"
 "google.golang.org/grpc/resolver"
)

func main() {
 resolver.Register(rs.NewResolverBuilder(map[string][]string{
  "cluster@callee": {
   "127.0.0.1:8009",
   "127.0.0.1:8010",
  },
 }))

 balancer.Register(bl.NewBalancerBuilder())

 conn, err := grpc.Dial("example:cluster@callee",
  grpc.WithInsecure(),
  grpc.WithDefaultServiceConfig(
   `{"loadBalancingPolicy":"random_picker"}`,
  ),
 )
 if err != nil {
  panic(err)
 }
 
  ....
}

參考資料

[1]URI語法: https://zh.wikipedia.org/wiki/%E7%BB%9F%E4%B8%80%E8%B5%84%E6%BA%90%E6%A0%87%E5%BF%97%E7%AC%A6

[2]go-control-plane: https://github.com/envoyproxy/go-control-plane

[3]gRPC Name Resolution: https://github.com/grpc/grpc/blob/master/doc/naming.md

[4]Load Balancing in gRPC: https://github.com/grpc/grpc/blob/master/doc/load-balancing.md

[5]https://github.com/grpc/grpc-go: https://github.com/grpc/grpc-go

[6]gRPC Go 服務發現與負載均衡: https://blog.cong.moe/post/2021-03-06-grpc-go-discovery-lb/

[7][轉]gRPC服務發現&負載均衡: https://colobu.com/2017/03/25/grpc-naming-and-load-balance/

[8]淺淡 xDS 協議在 gRPC 中的應用: http://limeng.org/2020/03/08/xds-in-grpc.html

責任編輯:武曉燕 來源: 涼涼的知識庫
相關推薦

2020-04-15 22:18:55

架構負載均衡分布式

2011-02-22 14:07:52

2013-11-26 09:43:36

開發日志博客

2019-09-19 09:03:13

Docker負載均衡服務

2022-01-12 18:20:36

GoJava開發

2013-03-28 10:22:33

數據庫關系型數據庫數據庫設計

2019-09-19 14:57:27

Docker語言技術

2012-06-13 01:23:30

開發者程序員

2021-12-16 20:12:37

后端開發Sentry

2012-11-03 21:03:37

2022-04-22 14:15:59

Go開發者受訪者

2019-11-29 08:05:26

連接池負載均衡互聯網架構

2023-10-17 08:08:37

Dubbo服務注冊中心

2023-10-27 12:36:37

gRPCKubernetes

2019-02-21 09:18:27

服務路由負載均衡微服務

2019-06-09 09:13:14

Istio負載均衡架構

2011-04-18 15:38:15

喬布斯佩奇開發者

2016-07-11 15:22:50

華為開發者
點贊
收藏

51CTO技術棧公眾號

主站蜘蛛池模板: 一区二区三区国产 | 国产日韩免费观看 | 一级做a爰片性色毛片 | 美国十次成人欧美色导视频 | 久久久精品综合 | www.三级 | 亚洲一区二区在线视频 | 亚洲精品观看 | 一级毛片视频在线观看 | 免费同性女女aaa免费网站 | 久久看片| 久久久国产精品入口麻豆 | 中文字幕日韩一区 | 日韩精品免费一区二区在线观看 | 黄视频免费观看 | 国内久久精品 | 在线观看国产 | 精品国产一区二区三区成人影院 | 欧美精品a∨在线观看不卡 国产精品久久国产精品 | 精品久久久久久中文字幕 | 精品亚洲一区二区三区 | 欧美福利专区 | a久久久久久 | 精品欧美一区二区在线观看欧美熟 | 久久久久国产一区二区 | 欧美精品一区二区在线观看 | www.日日干| 91精品在线播放 | 亚洲激精日韩激精欧美精品 | 国产日韩一区二区 | 99reav| 久久久久久久国产 | 国产成人精品免高潮在线观看 | 日韩视频1| 久久毛片 | 在线播放日韩 | 91综合网 | 成人av电影在线 | 国产一区二区在线免费 | www.国产精品 | 亚洲一一在线 |