前段時間寫過一篇 gRPC 的入門文章,在最后還留了一個坑沒有填:
圖片
也就是 gRPC 的負載均衡問題,因為當時的業務請求量不算大,再加上公司沒有對 Istio 這類服務網格比較熟悉的大牛,所以我們也就一直拖著沒有解決,依然只是使用了 kubernetes 的 service 進行負載,好在也沒有出什么問題。
由于現在換了公司后也需要維護公司的服務網格服務,結合公司內部對 Istio 的使用現在終于不再停留在理論階段了。
所以也終有機會將這個坑填了。
先來回顧下背景,為什么會有 gRPC 負債不均衡的問題。由于 gRPC 是基于 HTTP/2 協議的,所以客戶端和服務端會保持長鏈接,一旦鏈接建立成功后就會一直使用這個連接處理后續的請求。
圖片
除非我們每次請求之后都新建一個連接,這顯然是不合理的。
所以要解決 gRPC 的負載均衡通常有兩種方案:
客戶端負載均衡目前也有兩種方案,最常見也是傳統方案。
圖片
這里以 Dubbo 的調用過程為例,調用的時候需要從服務注冊中心獲取到提供者的節點信息,然后在客戶端本地根據一定的負載均衡算法得出一個節點然后發起請求。
換成 gRPC 也是類似的,這里以 go-zero 負載均衡的原理為例:
圖片
gRPC 官方庫也提供了對應的負載均衡接口,但我們依然需要自己維護服務列表然后在客戶端編寫負載均衡算法,這里有個官方 demo:
https://github.com/grpc/grpc-go/blob/87eb5b7502493f758e76c4d09430c0049a81a557/examples/features/load_balancing/client/main.go
但切換到 kubernetes 環境中時再使用以上的方式就不夠優雅了,因為我們使用 kubernetes 的目的就是不想再額外的維護這個客戶端包,這部分能力最好是由 kubernetes 自己就能提供。
但遺憾的是 kubernetes 提供的 service 只是基于 L4 的負載,所以我們每次請求的時候都只能將請求發往同一個 Provider 節點。
這里我寫了一個小程序來驗證負債不均衡的示例:
// 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 連接發起一次 gRPC 請求,服務端會返回它的 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())) })
創建一個 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 部署三個節點,再部署了一個客戶端節點:
? 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
我們進入客戶端節點執行多次 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
會發現每次請求的都是同一個節點 native-tools-2-d6c454689-zpwxt,這也就證明了在 kubernetes 中直接使用 gRPC 負載是不均衡的,一旦連接建立后就只能將請求發往那個節點。
Istio 可以拿來解決這個問題,我們換到一個注入了 Istio 的 namespace 下還是同樣的 代碼,同樣的 service 資源進行測試。
關于開啟 namespace 的 Istio 注入會在后續更新,現在感興趣的可以查看下官方文檔: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
可以發現同樣的請求已經被負載到了多個 server 后端,這樣我們就可以不再單獨維護一個客戶端 SDK 的情況下實現了負載均衡。
其實本質上 Istio 也是客戶端負載均衡的一種實現。
圖片
以 Istio 的架構圖為例:
可以在使用了 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"
可以發現這里存在一個 istio-proxy 的容器,也就是我們常說的 sidecar,這樣我們就可以把原本的 SDK 里的功能全部交給 Istio 去處理。
當然 Istio 的功能遠不止于此,比如:
這次只是一個開胃菜,更多關于 Istio 的內容會在后續更新,比如會從如何在 kubernetes 集群中安裝 Istio 講起,帶大家一步步使用好 Istio。
本文相關源碼:https://github.com/crossoverJie/k8s-combat
參考鏈接:
本文鏈接:http://www.tebozhan.com/showinfo-26-13632-0.html在 Kubernetes 環境中實現 gRPC 負載均衡
聲明:本網頁內容旨在傳播知識,若有侵權等問題請及時與本網聯系,我們將在第一時間刪除處理。郵件:2376512515@qq.com
上一篇: C++中的外部鏈接性和內部鏈接性:探究其區別與應用
下一篇: 一文徹底掌握MQ消息積壓全部解決方案