當(dāng)前位置：首頁 > 科技 > 軟件

在 Kubernetes 環(huán)境中實(shí)現(xiàn) gRPC 負(fù)載均衡

來源：責(zé)編：時間：2023-10-17 09:38:22 296觀看

導(dǎo)讀前言前段時間寫過一篇 gRPC 的入門文章，在最后還留了一個坑沒有填：圖片也就是 gRPC 的負(fù)載均衡問題，因?yàn)楫?dāng)時的業(yè)務(wù)請求量不算大，再加上公司沒有對 Istio 這類服務(wù)網(wǎng)格比較熟悉的大牛，所以我們也就一直拖著沒有解決，依然只

前言

前段時間寫過一篇 gRPC 的入門文章，在最后還留了一個坑沒有填：

圖片

也就是 gRPC 的負(fù)載均衡問題，因?yàn)楫?dāng)時的業(yè)務(wù)請求量不算大，再加上公司沒有對 Istio 這類服務(wù)網(wǎng)格比較熟悉的大牛，所以我們也就一直拖著沒有解決，依然只是使用了 kubernetes 的 service 進(jìn)行負(fù)載，好在也沒有出什么問題。

由于現(xiàn)在換了公司后也需要維護(hù)公司的服務(wù)網(wǎng)格服務(wù)，結(jié)合公司內(nèi)部對 Istio 的使用現(xiàn)在終于不再停留在理論階段了。

所以也終有機(jī)會將這個坑填了。

gRPC 負(fù)載均衡

負(fù)載不均衡

原理

先來回顧下背景，為什么會有 gRPC 負(fù)債不均衡的問題。由于 gRPC 是基于 HTTP/2 協(xié)議的，所以客戶端和服務(wù)端會保持長鏈接，一旦鏈接建立成功后就會一直使用這個連接處理后續(xù)的請求。

圖片

除非我們每次請求之后都新建一個連接，這顯然是不合理的。

所以要解決 gRPC 的負(fù)載均衡通常有兩種方案：

服務(wù)端負(fù)載均衡
客戶端負(fù)載均衡在 gRPC 這個場景服務(wù)端負(fù)載均衡不是很合適，所有的請求都需要經(jīng)過一個負(fù)載均衡器，這樣它就成為整個系統(tǒng)的瓶頸，所以更推薦使用客戶端負(fù)載均衡。

客戶端負(fù)載均衡目前也有兩種方案，最常見也是傳統(tǒng)方案。

圖片

這里以 Dubbo 的調(diào)用過程為例，調(diào)用的時候需要從服務(wù)注冊中心獲取到提供者的節(jié)點(diǎn)信息，然后在客戶端本地根據(jù)一定的負(fù)載均衡算法得出一個節(jié)點(diǎn)然后發(fā)起請求。

換成 gRPC 也是類似的，這里以 go-zero 負(fù)載均衡的原理為例：

圖片

gRPC 官方庫也提供了對應(yīng)的負(fù)載均衡接口，但我們依然需要自己維護(hù)服務(wù)列表然后在客戶端編寫負(fù)載均衡算法，這里有個官方 demo:

https://github.com/grpc/grpc-go/blob/87eb5b7502493f758e76c4d09430c0049a81a557/examples/features/load_balancing/client/main.go

但切換到 kubernetes 環(huán)境中時再使用以上的方式就不夠優(yōu)雅了，因?yàn)槲覀兪褂?kubernetes 的目的就是不想再額外的維護(hù)這個客戶端包，這部分能力最好是由 kubernetes 自己就能提供。

但遺憾的是 kubernetes 提供的 service 只是基于 L4 的負(fù)載，所以我們每次請求的時候都只能將請求發(fā)往同一個 Provider 節(jié)點(diǎn)。

測試

這里我寫了一個小程序來驗(yàn)證負(fù)債不均衡的示例：

// Create gRPC servergo func() {     var port = ":50051"     lis, err := net.Listen("tcp", port)     if err != nil {        log.Fatalf("failed to listen: %v", err)     }     s := grpc.NewServer()     pb.RegisterGreeterServer(s, &server{})     if err := s.Serve(lis); err != nil {        log.Fatalf("failed to serve: %v", err)     } else {        log.Printf("served on %s /n", port)     }  }()// server is used to implement helloworld.GreeterServer.  type server struct {     pb.UnimplementedGreeterServer  }    // SayHello implements helloworld.GreeterServer  func (s *server) SayHello(ctx context.Context, in *pb.HelloRequest) (*pb.HelloReply, error) {     log.Printf("Received: %v", in.GetName())     name, _ := os.Hostname()     // Return hostname of Server   return &pb.HelloReply{Message: fmt.Sprintf("hostname:%s, in:%s", name, in.Name)}, nil  }

使用同一個 gRPC 連接發(fā)起一次 gRPC 請求，服務(wù)端會返回它的 hostname

var (     once sync.Once     c    pb.GreeterClient  )  http.HandleFunc("/grpc_client", func(w http.ResponseWriter, r *http.Request) {     once.Do(func() {        service := r.URL.Query().Get("name")        conn, err := grpc.Dial(fmt.Sprintf("%s:50051", service), grpc.WithInsecure(), grpc.WithBlock())        if err != nil {           log.Fatalf("did not connect: %v", err)        }        c = pb.NewGreeterClient(conn)     })       // Contact the server and print out its response.     name := "world"     ctx, cancel := context.WithTimeout(context.Background(), time.Second)     defer cancel()     g, err := c.SayHello(ctx, &pb.HelloRequest{Name: name})     if err != nil {        log.Fatalf("could not greet: %v", err)     }     fmt.Fprint(w, fmt.Sprintf("Greeting: %s", g.GetMessage()))  })

創(chuàng)建一個 service 用于給 gRPC 提供域名：

apiVersion: v1  kind: Service  metadata:    name: native-tools-2spec:    selector:      app: native-tools-2  ports:      - name: http        port: 8081        targetPort: 8081      - name: grpc        port: 50051        targetPort: 50051

同時將我們的 gRPC server 部署三個節(jié)點(diǎn)，再部署了一個客戶端節(jié)點(diǎn)：

? k get podNAME                                READY   STATUS    RESTARTSnative-tools-2-d6c454689-52wgd      1/1     Running   0              native-tools-2-d6c454689-67rx4      1/1     Running   0              native-tools-2-d6c454689-zpwxt      1/1     Running   0              native-tools-65c5bd87fc-2fsmc       2/2     Running   0

我們進(jìn)入客戶端節(jié)點(diǎn)執(zhí)行多次 grpc 請求：

k exec -it native-tools-65c5bd87fc-2fsmc bashGreeting: hostname:native-tools-2-d6c454689-zpwxt, in:worldistio-proxy@n:/$ curl http://127.0.0.1:8081/grpc_client?name=native-tools-2Greeting: hostname:native-tools-2-d6c454689-zpwxt, in:worldistio-proxy@n:/$ curl http://127.0.0.1:8081/grpc_client?name=native-tools-2Greeting: hostname:native-tools-2-d6c454689-zpwxt, in:worldistio-proxy@n:/$ curl http://127.0.0.1:8081/grpc_client?name=native-tools-2Greeting: hostname:native-tools-2-d6c454689-zpwxt, in:worldistio-proxy@n:/$ curl http://127.0.0.1:8081/grpc_client?name=native-tools-2Greeting: hostname:native-tools-2-d6c454689-zpwxt, in:worldistio-proxy@n:/$ curl http://127.0.0.1:8081/grpc_client?name=native-tools-2Greeting: hostname:native-tools-2-d6c454689-zpwxt, in:worldistio-proxy@n:/$ curl http://127.0.0.1:8081/grpc_client?name=native-tools-2Greeting: hostname:native-tools-2-d6c454689-zpwxt, in:worldistio-proxy@n:/$ curl http://127.0.0.1:8081/grpc_client?name=native-tools-2Greeting: hostname:native-tools-2-d6c454689-zpwxt, in:worldistio-proxy@n:/$ curl http://127.0.0.1:8081/grpc_client?name=native-tools-2

會發(fā)現(xiàn)每次請求的都是同一個節(jié)點(diǎn) native-tools-2-d6c454689-zpwxt，這也就證明了在 kubernetes 中直接使用 gRPC 負(fù)載是不均衡的，一旦連接建立后就只能將請求發(fā)往那個節(jié)點(diǎn)。

使用 Istio

Istio 可以拿來解決這個問題，我們換到一個注入了 Istio 的 namespace 下還是同樣的代碼，同樣的 service 資源進(jìn)行測試。

關(guān)于開啟 namespace 的 Istio 注入會在后續(xù)更新，現(xiàn)在感興趣的可以查看下官方文檔：https://istio.io/latest/docs/setup/additional-setup/sidecar-injection/

Greeting: hostname:native-tools-2-5fbf46cf54-5m7dl, in:worldistio-proxy@n:/$ curl http://127.0.0.1:8081/grpc_client?name=native-tools-2Greeting: hostname:native-tools-2-5fbf46cf54-xprjz, in:worldistio-proxy@n:/$ curl http://127.0.0.1:8081/grpc_client?name=native-tools-2Greeting: hostname:native-tools-2-5fbf46cf54-5m7dl, in:worldistio-proxy@n:/$ curl http://127.0.0.1:8081/grpc_client?name=native-tools-2Greeting: hostname:native-tools-2-5fbf46cf54-5m7dl, in:worldistio-proxy@n:/$ curl http://127.0.0.1:8081/grpc_client?name=native-tools-2Greeting: hostname:native-tools-2-5fbf46cf54-xprjz, in:worldistio-proxy@n:/$ curl http://127.0.0.1:8081/grpc_client?name=native-tools-2Greeting: hostname:native-tools-2-5fbf46cf54-xprjz, in:worldistio-proxy@n:/$ curl http://127.0.0.1:8081/grpc_client?name=native-tools-2Greeting: hostname:native-tools-2-5fbf46cf54-5m7dl, in:worldistio-proxy@n:/$ curl http://127.0.0.1:8081/grpc_client?name=native-tools-2Greeting: hostname:native-tools-2-5fbf46cf54-5m7dl, in:worldistio-proxy@n:/$ curl http://127.0.0.1:8081/grpc_client?name=native-tools-2Greeting: hostname:native-tools-2-5fbf46cf54-nz8h5, in:worldistio-proxy@n:/$ curl http://127.0.0.1:8081/grpc_client?name=native-tools-2Greeting: hostname:native-tools-2-5fbf46cf54-nz8h5, in:worldistio-proxy@n:/$ curl http://127.0.0.1:8081/grpc_client?name=native-tools-2

可以發(fā)現(xiàn)同樣的請求已經(jīng)被負(fù)載到了多個 server 后端，這樣我們就可以不再單獨(dú)維護(hù)一個客戶端 SDK 的情況下實(shí)現(xiàn)了負(fù)載均衡。

原理

其實(shí)本質(zhì)上 Istio 也是客戶端負(fù)載均衡的一種實(shí)現(xiàn)。

圖片

以 Istio 的架構(gòu)圖為例：

每一個 Pod 下會新增一個 Proxy 的 container，所有的流量入口和出口都會經(jīng)過它。
它會從控制平面 Istiod 中拿到服務(wù)的注冊信息，也就是 kubernetes 中的 service。
發(fā)生請求時由 proxy 容器中的 Envoy 進(jìn)行最終的負(fù)載請求。

可以在使用了 Istio 的 Pod 中查看到具體的容器：

? k get pod native-tools-2-5fbf46cf54-5m7dl -n istio-test-2 -o json | jq '.spec.containers[].name'"istio-proxy""native-tools-2"

可以發(fā)現(xiàn)這里存在一個 istio-proxy 的容器，也就是我們常說的 sidecar，這樣我們就可以把原本的 SDK 里的功能全部交給 Istio 去處理。

總結(jié)

當(dāng)然 Istio 的功能遠(yuǎn)不止于此，比如：

統(tǒng)一網(wǎng)關(guān)，處理東西、南北向流量。
灰度發(fā)布
流量控制
接口粒度的超時配置
自動重試等

這次只是一個開胃菜，更多關(guān)于 Istio 的內(nèi)容會在后續(xù)更新，比如會從如何在 kubernetes 集群中安裝 Istio 講起，帶大家一步步使用好 Istio。

本文相關(guān)源碼：https://github.com/crossoverJie/k8s-combat

參考鏈接：

https://istio.io/latest/docs/setup/getting-started/
https://segmentfault.com/a/1190000042295402
https://go-zero.dev/docs/tutorials/service/governance/lb

本文鏈接：http://www.www897cc.com/showinfo-26-13632-0.html在 Kubernetes 環(huán)境中實(shí)現(xiàn) gRPC 負(fù)載均衡

聲明：本網(wǎng)頁內(nèi)容旨在傳播知識，若有侵權(quán)等問題請及時與本網(wǎng)聯(lián)系，我們將在第一時間刪除處理。郵件：2376512515@qq.com

上一篇： C++中的外部鏈接性和內(nèi)部鏈接性：探究其區(qū)別與應(yīng)用

下一篇：一文徹底掌握MQ消息積壓全部解決方案

標(biāo)簽：

熱門焦點(diǎn)

8月總票房已突破10億！《封神》第一：口碑已經(jīng)成了

8月5日消息，據(jù)燈塔專業(yè)版數(shù)據(jù)，截至8月5日9時35分，8月總票房（含預(yù)售）已突破10億。其中，《封神》以大比分的優(yōu)勢領(lǐng)先。根據(jù)官方消息，目前該片總票房已經(jīng)超過14.
多線程開發(fā)帶來的問題與解決方法

使用多線程主要會帶來以下幾個問題：（一）線程安全問題　　線程安全問題指的是在某一線程從開始訪問到結(jié)束訪問某一數(shù)據(jù)期間，該數(shù)據(jù)被其他的線程所修改，那么對于當(dāng)前線程而言，該線程
自律，給不了Keep自由！

來源 | 互聯(lián)網(wǎng)品牌官作者 | 李大為編排 | 又耳審核 | 谷曉輝自律能不能給用戶自由暫時不好說，但大概率不能給Keep自由。近日，全球最大的在線健身平臺Keep正式登陸港交所，努力
機(jī)構(gòu)稱Q2全球智能手機(jī)出貨量同比下滑11% 蘋果份額依舊第2

7月20日消息，據(jù)外媒報(bào)道，研究機(jī)構(gòu)的報(bào)告顯示，由于需求下滑，今年二季度全球智能手機(jī)的出貨量，同比下滑了11%，三星、蘋果等主要廠商的銷量，較去年同期均有下
OPPO K11樣張首曝：千元機(jī)影像“卷”得真不錯！

一直以來，OPPO K系列機(jī)型都保持著較為均衡的產(chǎn)品體驗(yàn)，歷來都是2K價(jià)位的明星機(jī)型，去年推出的OPPO K10和OPPO K10 Pro兩款機(jī)型憑借各自的出色配置，堪稱有
蘋果MacBook Pro 2021測試：仍不支持平滑滾動

據(jù)10月30日9to5 Mac 消息報(bào)道，蘋果新的 14 英寸和 16 英寸 MacBook Pro 2021 上市后獲得了不錯的評價(jià)，亮點(diǎn)包括行業(yè)領(lǐng)先的性能，令人印象深刻的電池續(xù)航，精美豐
三翼鳥智能家居亮相電博會，讓用戶體驗(yàn)更真實(shí)

2021電博會在青島國際會展中心開幕中，三翼鳥直接把“家”搬到了現(xiàn)場，成為了展會的一大看點(diǎn)。這也是三翼鳥繼9月9日發(fā)布了行業(yè)首個一站式定制智慧家平臺后的
世界人工智能大會國際日開幕式活動在世博展覽館開啟

30日上午，世界人工智能大會國際日開幕式活動在世博展覽館開啟，聚集國際城市代表、重量級院士專家、國際創(chuàng)新企業(yè)代表，共同打造人工智能交流平臺。上海市副市
電博會與軟博會實(shí)現(xiàn)"線下+云端"的雙線融合

在本次“電博會”與“軟博會”雙展會利好條件的加持下，既可以發(fā)揮展會拉動人流、信息流、資金流實(shí)現(xiàn)快速交互流動的作用，繼而推動區(qū)域經(jīng)濟(jì)良性發(fā)展；又可以聚

日韩成人免费在线_国产成人一二_精品国产免费人成电影在线观..._日本一区二区三区久久久久久久久不

在 Kubernetes 環(huán)境中實(shí)現(xiàn) gRPC 負(fù)載均衡

前言

gRPC 負(fù)載均衡

負(fù)載不均衡

原理

測試

使用 Istio

原理

總結(jié)

8月總票房已突破10億！《封神》第一：口碑已經(jīng)成了

多線程開發(fā)帶來的問題與解決方法

自律，給不了Keep自由！

機(jī)構(gòu)稱Q2全球智能手機(jī)出貨量同比下滑11% 蘋果份額依舊第2

OPPO K11樣張首曝：千元機(jī)影像“卷”得真不錯！

蘋果MacBook Pro 2021測試：仍不支持平滑滾動

三翼鳥智能家居亮相電博會，讓用戶體驗(yàn)更真實(shí)

世界人工智能大會國際日開幕式活動在世博展覽館開啟

電博會與軟博會實(shí)現(xiàn)"線下+云端"的雙線融合

最新推薦

猜你喜歡

熱門推薦

相關(guān)資訊