Kubernetes生产实践系列之十七：ServiceMesh之gRPC基本原理和实践

绝地灬酷狼 2023-03-12 14:28 48阅读 0赞

## **一、前言** ##

gRPC是一款高效的RPC框架，基于HTTP/2进行设计并支持ProtoBuf序列化协议。gRPC使用长连接和单连接内部高并发来提高性能，这对于数据中心内部服务之间横向调用意义巨大。当前服务在启动的时候可以启动到多个gRPC服务端的长连接，并在连接内部进行大批量的数据并发调用，极大提升了内部东西向调用性能：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Nsb3VkdnRlY2g_size_16_color_FFFFFF_t_70][] gRPC服务调用

转载自https://blog.csdn.net/cloudvtech

## **二、gRPC负载均衡问题和方案** ##

### 2.1 问题 ###

基于gRPC的服务通过加强七层链接的使用率提升调用性能。具体来说，gRPC使用HTTP/2.0协议建立单一长TCP连接(single long-lived TCP connection)，并在该连接上能准并发(交叉)传递请求/响应(multiple requests can be active on the same connection at any point in time)，消灭单transaction连接建立时间并且在热链路上即时进行数据收发。这样的数据传输特性意味着长连接内部状态在7层才能获得，很多基于四层的流量管理机制都会失效，四层的负载均衡将由于长TCP连接的存在而失去效果，所有的后续gRPC请求都会被发送到这一个长TCP连接对应的后端。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Nsb3VkdnRlY2g_size_16_color_FFFFFF_t_70 1][] 四层LB无法均衡gRPC调用

这里可以再进一步聊一下HTTP/1.1也是基于长连接的协议，为什么进行四层LB负载均衡没有问题？其实由于HTTP/1.1的特性，导致这个问题没有那么明显，对于实际的业务没有太大的影响：

*  HTTP/1.1 不会进行请求的交叉发送，任何时候在一个连接上只有一个请求，只有等当前的请求处理完了才能进行下一个请求
 *  如果有很多并发请求，需要启动更多的长连接进行处理
 *  每个长连接会有确定的过期时间

这几个点组合起来最后会导致对于有大量并发的系统而言，会建立足够多的长连接，只要长连接的数量足够多，就能保证到所有的后端都有连接，所以看起来整体是负载均衡的：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Nsb3VkdnRlY2g_size_16_color_FFFFFF_t_70 2][] HTTP/1.1的四层“负载均衡”

### 2.2 gRPC流量负载均衡方案 ###

抽象的讲，负载均衡方案有如下几个选择：

*  专用集中式LB，比如Nginx、Envoy、HAProxy、IPVS、公有云厂商的ELB
 *  客户端分布式LB
    
     *  客户端进程内自主负载均衡，比如客户端的SDK感知所有服务端，然后有调用流程按照负载均衡方案选择调用客户端
     *  客户端独立进程负载均衡，在客户端所在的主机部署LB进程同一负载均衡，类似Kubernetes部署的Istio/Linkerd的sidecard方案

根据灵活性、独立性、稳定性等不同的要求，可以选择不同的方案，在我们的业务场景中，集中式和客户端分布式LB都有使用，比如通过Envoy集中式暴露gRPC服务(具体细节参看下一节内容：**三、gRPC负载均衡实验**)或者通过服务注册和发现机制让客户端感知后端服务然后进行自主负载均衡：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Nsb3VkdnRlY2g_size_16_color_FFFFFF_t_70 3][] 基于Etcd的服务发现和客户端负载均衡方案

在这种方案中，etcd集群被用于服务注册和发现，每个gRPC客户端都会获取当前存活的注册到etcd的服务列表，然后在进行请求时按照负载均衡策略选择合理的后端发起请求。

## **三、gRPC负载均衡实验** ##

本节通过配置gRPC客户端进行长连接和短连接不同模式尝试来验证gRPC的特性，这里使用能感知gRPC协议的七层代理Envoy作为集中式负载均衡器：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Nsb3VkdnRlY2g_size_16_color_FFFFFF_t_70 4][] 基于Envoy的集中式gRPC负载均衡方案

###  3.1 准备工作 ###

Install go and gRPC lib on centos

#https://grpc.io/docs/quickstart/go/
    
    yum install epel-release -y
    yum install golang -y
    
    go get -u google.golang.org/grpc
    go get -u github.com/golang/protobuf/{proto,protoc-gen-go}

### 3.2 运行例子 ###

#/root/go/src/google.golang.org/grpc/examples/helloworld
    
    go run greeter_server/main.go 
    go run greeter_client/main.go

并分别在两个VM启动两个gRPC服务：

> 172.3.0.17:50051
> 
> 172.3.0.11:50051

### 3.3 按照Envoy作为LB ###

#https://www.envoyproxy.io/docs/envoy/latest/start/start#using-the-envoy-docker-image
    
    docker pull envoyproxy/envoy

Envoy config file: envoy-grpc.yaml

admin:
      access_log_path: /tmp/admin_access.log
      address:
        socket_address:
          address: 0.0.0.0
          port_value: 9901
    static_resources:
      listeners:
        -
          name: listener_0
          address:
            socket_address:
              address: 0.0.0.0
              port_value: 10000
          filter_chains:
            -
              filters:
                -
                  name: envoy.http_connection_manager
                  config:
                    stat_prefix: ingress_http
                    codec_type: AUTO
                    route_config:
                      name: local_route
                      virtual_hosts:
                        -
                          name: local_service
                          domains:
                            - '*'
                          routes:
                            -
                              match:
                                prefix: /
                              route:
                                cluster: service_grpc
                    http_filters:
                      -
                        name: envoy.router
      clusters:
        -
          name: service_grpc
          connect_timeout: 25s
          type: STATIC
          lb_policy: ROUND_ROBIN
          dns_lookup_family: V4_ONLY
          http2_protocol_options: {}
          hosts:
            -
              socket_address:
                address: 172.3.0.17
                port_value: 50051
            -
              socket_address:
                address: 172.3.0.11
                port_value: 50051

将配置构建如镜像：Dockerfile

FROM envoyproxy/envoy
    COPY envoy-grpc.yaml /etc/envoy/envoy.yaml

进行构建：

docker build -t envoy:v1 .

Run the envoy as proxy：

docker run -d --name envoy -p 9901:9901 -p 10000:10000
    #9901 as admin port and 10000 as envoy service port

### 3.4 使用长连接访问Envoy LB以及后端服务 ###

修改客户端代码如下：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Nsb3VkdnRlY2g_size_16_color_FFFFFF_t_70 5][]

结果如下，在这个例子中，我们的两个gRPC服务端分别在两个VM(km2/km3)上，客户端发送的请求也会被Envoy使用RR策略轮流调度到不同的后端：

![20200509221730166.png][]

整个过程都只有一个到envoy的链接：

> tcp  0  47 172.3.0.17:45918  172.3.0.17:10000  ESTABLISHED 25429/main1

如果使用gRPC短连接访问服务则会占用大量端口：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Nsb3VkdnRlY2g_size_16_color_FFFFFF_t_70 6][]

转载自https://blog.csdn.net/cloudvtech

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Nsb3VkdnRlY2g_size_16_color_FFFFFF_t_70]: /images/20230312/7cc5e5fa3d1d40b2ab70a1c6a4df3532.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Nsb3VkdnRlY2g_size_16_color_FFFFFF_t_70 1]: /images/20230312/2f9f0dbfe59245e1a0abc662d89fbdda.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Nsb3VkdnRlY2g_size_16_color_FFFFFF_t_70 2]: /images/20230312/bee9bc5ed1f3452ea78b152d3ac39480.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Nsb3VkdnRlY2g_size_16_color_FFFFFF_t_70 3]: /images/20230312/b04c29d128804b19822854dc2188f896.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Nsb3VkdnRlY2g_size_16_color_FFFFFF_t_70 4]: /images/20230312/c60d35b0aad44c22a7b01b91786ba114.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Nsb3VkdnRlY2g_size_16_color_FFFFFF_t_70 5]: /images/20230312/747cf7c63dd64156a76f8a4664d73cd6.png
[20200509221730166.png]: /images/20230312/250966cad9714687bf944b6c5aa57d79.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Nsb3VkdnRlY2g_size_16_color_FFFFFF_t_70 6]: /images/20230312/a21c976ae83446f699d46d40f8321209.png