前言

grpc 因?yàn)槭情L(zhǎng)連接的，所以負(fù)載均衡處理起來(lái)沒(méi)有 rest 接口那么容易。常見(jiàn)的 grpc 負(fù)載均衡方法分為兩類(lèi)，一類(lèi)是客戶(hù)端側(cè)實(shí)現(xiàn)負(fù)載邏輯，一類(lèi)是代理側(cè)實(shí)現(xiàn)負(fù)載邏輯，對(duì)客戶(hù)端側(cè)是透明的。在容器化的網(wǎng)絡(luò)環(huán)境里， grpc-java 客戶(hù)端側(cè)的負(fù)載均衡有兩種常見(jiàn)的實(shí)現(xiàn)路徑。

1、基于 dns 實(shí)現(xiàn)，

2、基于外部的服務(wù)注冊(cè)中心實(shí)現(xiàn)(ZooKeeper/Etcd/Consul/Eureka)。

本文旨在，在容器化的網(wǎng)絡(luò)環(huán)境下，通過(guò)測(cè)驗(yàn)尋找一種改造成本最小的實(shí)現(xiàn)負(fù)載均衡的途徑

現(xiàn)狀

在 k8s 的網(wǎng)絡(luò)環(huán)境下，一個(gè) grpc 的服務(wù)，同一個(gè) namespace 下，可以直接通過(guò) service 訪問(wèn)，不同的 namespace 可以通過(guò) service.namespace 訪問(wèn)。但是，經(jīng)驗(yàn)證，這種直連的方式?jīng)]法做到負(fù)載均衡，也就意味著 server 端無(wú)論開(kāi)啟了多少個(gè) pod 實(shí)例，客戶(hù)端也只能連接一個(gè)pod 。所以，在客戶(hù)端和服務(wù)端數(shù)量不對(duì)等時(shí)，打到 server 側(cè)的流量會(huì)非常的不均衡，如果數(shù)量對(duì)等，情況稍微好些。本次測(cè)驗(yàn)只測(cè)試了 java 鏈接 java 的 grpc 服務(wù)，生產(chǎn)環(huán)境的實(shí)際調(diào)用場(chǎng)景會(huì)更復(fù)雜，包含了 php 、go、java 三種 grpc 服務(wù)的相互調(diào)用

負(fù)載均衡的方案

一、客戶(hù)端 dns 模式

dns 的模式是 grpc-java 實(shí)現(xiàn)復(fù)雜均衡改造成本最小的。應(yīng)該也是最通用的，各個(gè)語(yǔ)言的 grpc  應(yīng)該都有支持。主要改動(dòng)兩個(gè)地方，

1、修改 Service 的 spec.clusterIP 為 ”None“,如：

apiVersion: v1
kind: Service
metadata:
  namespace: tap-prod
  name: queuing-rpc
  labels:
    app: queuing-rpc
spec:
  clusterIP: None
  ports:
    - port: 8030
      targetPort: 8030
      name: grpc
  selector:
    app: queuing-rpc

改動(dòng)后，可以通過(guò) service 的名稱(chēng)解析到 pod 的 ip 列表

2、配置的 grpc 鏈接協(xié)議頭加上 dns 協(xié)議，如：

grpc.client.store.address = dns:///store-rpc:8020

 二、客戶(hù)端注冊(cè)中心模式

客戶(hù)端注冊(cè)中心模式相比較 dns 模式，實(shí)現(xiàn)方式上相對(duì)復(fù)雜點(diǎn)，但是靈活度更高了，有了注冊(cè)中心后，服務(wù)治理相關(guān)的也就都可以做了。但是在多語(yǔ)言的場(chǎng)景下，這種方式的普及難度會(huì)更高，無(wú)論選擇哪個(gè)注冊(cè)中心實(shí)現(xiàn)，都必須要求其他語(yǔ)言也要對(duì)應(yīng)實(shí)現(xiàn)。這里只簡(jiǎn)要闡述 grpc-java 的實(shí)現(xiàn)途徑

。grpc-java 客戶(hù)端提供了 NameResolver 、NameResolverProvider 、NameResolverRegistry 等實(shí)現(xiàn)服務(wù)注冊(cè)發(fā)現(xiàn)的擴(kuò)展類(lèi)。結(jié)合注冊(cè)中心 ZooKeeper/Etcd/Consul/Eureka ，很容易實(shí)現(xiàn)一個(gè)基于注冊(cè)中心的帶服務(wù)治理的 grpc 。

三、代理端走 ingress

nginx-ingress-controller 從 0.30.0 版本開(kāi)始支持 grpc 的流量代理，經(jīng)測(cè)驗(yàn)，在 nginx-ingress 代理模式下，grpc 的流量是負(fù)責(zé)均衡的。這種改動(dòng)方式也比較簡(jiǎn)單，服務(wù)方只需要新增一個(gè) ingress 代理 grpc 流量即可，客戶(hù)端鏈接是無(wú)感的，不需要做任何改動(dòng)。因?yàn)樽吡艘粚哟?，性能上?huì)比dns 模式差點(diǎn)

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  namespace: tap-prod
  name: store-rpc
  annotations:
    kubernetes.io/ingress.class: nginx-intranet-grpc
    nginx.ingress.kubernetes.io/backend-protocol: "GRPC"
spec:
  rules:
    - host: store-rpc.xx.com
      http:
        paths:
          - backend:
              serviceName: store-rpc
              servicePort: 8020

四、代理端 service mesh

需要引入 istio 等服務(wù)網(wǎng)格架構(gòu)。這種模式，對(duì)于多語(yǔ)言微服務(wù)環(huán)境是非常友好的，可以屏蔽各種語(yǔ)言基礎(chǔ)服務(wù)治理的實(shí)現(xiàn)細(xì)節(jié)，應(yīng)該是最終目標(biāo)方案。

結(jié)語(yǔ)

短期而言，需要解決 grpc 負(fù)載均衡問(wèn)題，最快速、最無(wú)感的方案是基于 ingress 的代理負(fù)載模式。改動(dòng)小、性能好的方案應(yīng)該是客戶(hù)端基于 dns 的模式。最復(fù)雜、最靈活、可控度最高的應(yīng)該是基于客戶(hù)端注冊(cè)中心的實(shí)現(xiàn)方式。綜合起來(lái)看，service mesh 的方式才是最終的目標(biāo)，不僅解決服務(wù)負(fù)載問(wèn)題，流量觀測(cè)、服務(wù)治理也統(tǒng)統(tǒng)解決了

參考：

• https://grpc.io/blog/grpc-load-balancing/
• https://kubernetes.github.io/ingress-nginx/examples/grpc/

以上就是grpc-java k8s下的負(fù)載均衡處理方法的詳細(xì)內(nèi)容，更多關(guān)于grpc-java k8s負(fù)載均衡的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！