grpc-java k8s下的負載均衡處理方法

2022-02-21 13:01:52

前言

grpc 因為是長連線的，所以負載均衡處理起來沒有 rest 介面那麼容易。常見的 grpc 負載均衡方法分為兩類，一類是使用者端側實現負載邏輯，一類是代理側實現負載邏輯，對使用者端側是透明的。在容器化的網路環境裡， grpc-java 使用者端側的負載均衡有兩種常見的實現路徑。

1、基於 dns 實現，

2、基於外部的服務註冊中心實現(ZooKeeper/Etcd/Consul/Eureka)。

本文旨在，在容器化的網路環境下，通過測驗尋找一種改造成本最小的實現負載均衡的途徑

現狀

在 k8s 的網路環境下，一個 grpc 的服務，同一個 namespace 下，可以直接通過 service 存取，不同的 namespace 可以通過 service.namespace 存取。但是，經驗證，這種直連的方式沒法做到負載均衡，也就意味著 server 端無論開啟了多少個 pod 範例，使用者端也只能連線一個pod 。所以，在使用者端和伺服器端數量不對等時，打到 server 側的流量會非常的不均衡，如果數量對等，情況稍微好些。本次測驗只測試了 java 連結 java 的 grpc 服務，生產環境的實際呼叫場景會更復雜，包含了 php 、go、java 三種 grpc 服務的相互呼叫

負載均衡的方案

一、使用者端 dns 模式

dns 的模式是 grpc-java 實現複雜均衡改造成本最小的。應該也是最通用的，各個語言的 grpc 應該都有支援。主要改動兩個地方，

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

改動後，可以通過 service 的名稱解析到 pod 的 ip 列表

2、設定的 grpc 連結協定頭加上 dns 協定，如：

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

二、使用者端註冊中心模式

使用者端註冊中心模式相比較 dns 模式，實現方式上相對複雜點，但是靈活度更高了，有了註冊中心後，服務治理相關的也就都可以做了。但是在多語言的場景下，這種方式的普及難度會更高，無論選擇哪個註冊中心實現，都必須要求其他語言也要對應實現。這裡只簡要闡述 grpc-java 的實現途徑

。grpc-java 使用者端提供了 NameResolver 、NameResolverProvider 、NameResolverRegistry 等實現服務註冊發現的擴充套件類。結合註冊中心 ZooKeeper/Etcd/Consul/Eureka ，很容易實現一個基於註冊中心的帶服務治理的 grpc 。

三、代理端走 ingress

nginx-ingress-controller 從 0.30.0 版本開始支援 grpc 的流量代理，經測驗，在 nginx-ingress 代理模式下，grpc 的流量是負責均衡的。這種改動方式也比較簡單，服務方只需要新增一個 ingress 代理 grpc 流量即可，使用者端連結是無感的，不需要做任何改動。因為走了一層代理，效能上會比dns 模式差點

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 等服務網格架構。這種模式，對於多語言微服務環境是非常友好的，可以遮蔽各種語言基礎服務治理的實現細節，應該是最終目標方案。

結語

短期而言，需要解決 grpc 負載均衡問題，最快速、最無感的方案是基於 ingress 的代理負載模式。改動小、效能好的方案應該是使用者端基於 dns 的模式。最複雜、最靈活、可控度最高的應該是基於使用者端註冊中心的實現方式。綜合起來看，service mesh 的方式才是最終的目標，不僅解決服務負載問題，流量觀測、服務治理也統統解決了

參考：

以上就是grpc-java k8s下的負載均衡處理方法的詳細內容，更多關於grpc-java k8s負載均衡的資料請關注it145.com其它相關文章！