【go】gRPC灰度发布

1.问题:

由于项目需要,使用了gRPC,开发语言Golang,每次重启RPC应用,客户端都会受到影响,比如客户端在插数据,但是服务器端因为改了BUG重启,此时客户端受到影响.我们不允许这样,会损失好多钱.

想问gRPC应用如何灰度发布,有没有成熟的解决方案?重启时将原来的长链接保持住,重启后还可以继续服务.

2.gRPC介绍:

项目地址:

https://github.com/grpc/grpc
https://github.com/grpc/grpc-go

gRPC一开始由google 开发，是一款语言中立、平台中立、开源的远程过程调用(RPC)系统，面向移动和HTTP/2设计。目前提供C、Java和Go语言版本，分别是：grpc,grpc-java,grpc-go.其中C版本支持C,C++,Node.js,Python,Ruby,Objective-C,PHP和C#支持.

gRPC基于HTTP/2标准设计，带来诸如双向流、流控、头部压缩、单TCP连接上的多复用请求等特。这些特性使得其在移动设备上表现更好，更省电和节省空间占用。

gRPC基于以下理念：定义一个服务，指定其能够被远程调用的方法（包含参数和返回类型）。在服务端实现这个接口，并运行一个gRPC服务器来处理客户端调用。在客户端拥有一个存根能够像服务端一样的方法,即调用仿佛就在同一台机器。

可以使用不同语言平台进行开发.

回答

我自己解决了,使用负载均衡方案

所需软件参见docker仓库:https://hub.docker.com/_/hapr...

方案:

1.先自己打包一个

Dockerfile:

FROM haproxy:1.7
MAINTAINER hunterhug <http://github.com/hunterhug>
COPY haproxy.cfg /usr/local/etc/haproxy/haproxy.cfg

docker build -t dhaproxy  -f Dockerfile .

2.跑起haproxy

docker run -it --rm --name my-haproxy dhaproxy -f /usr/local/etc/haproxy/haproxy.cfg

haproxy.cfg如下:

#---------------------------------------------------------------------
# Global settings
#---------------------------------------------------------------------
global
    log    127.0.0.1 local2          ###[err warning info debug]
    #chroot  /usr/local/haproxy-1.7.3
    pidfile  /var/run/haproxy.pid   ###haproxy的pid存放路径,启动进程的用户必须有权限访问此文件
    maxconn  4000                   ###最大连接数，默认4000
    daemon                          ###创建1个进程进入deamon模式运行。此参数要求将运行模式设置为"daemon"
#---------------------------------------------------------------------
# common defaults that all the 'listen' and 'backend' sections will
# use if not designated in their block
#---------------------------------------------------------------------
defaults
    #mode   tcp            ###默认的模式，tcp是4层，http是7层，health只会返回OK 若是混合模式则 mode 不需要设置
    log    global           ###采用全局定义的日志
    option  dontlognull     ###不记录健康检查的日志信息
    option  httpclose       ###每次请求完毕后主动关闭http通道
    option  httplog         ###日志类别http日志格式 混合模式 此处还需要加上 tcplog
    #option  forwardfor      ###如果后端服务器需要获得客户端真实ip需要配置的参数，可以从Http Header中获得客户端ip
    option  redispatch      ###serverId对应的服务器挂掉后,强制定向到其他健康的服务器
    timeout connect 10s   #default 10 second timeout if a backend is not found
    timeout client 10s   ###客户端连接超时
    timeout server 10s   ###服务器连接超时
    maxconn     60000       ###最大连接数
    retries     3           ###3次连接失败就认为服务不可用，也可以通过后面设置
########统计页面配置########
listen admin_stats
    # 监听端口
    bind 0.0.0.0:8089
    # 启用状态监控
    stats enable
    mode http
    log global
    # 统计页面URL
    stats uri /stats
    # 统计页面密码框上提示文本
    stats realm Haproxy\ Statistics
    # 统计页面用户名和密码设置
    stats auth admin:admin
    # 隐藏统计页面上HAProxy的版本信息
    #stats hide-version
    #当通过认证才可管理
    stats admin if TRUE
    #统计页面自动刷新时间
    stats refresh 30s
########GRPC配置#################
listen lb
bind 0.0.0.0:40882
mode tcp
option tcplog
log global
maxconn 3000
balance leastconn
server l-40883 0.0.0.0:40883  weight 1 rise 2 fall 3
server l-40884 0.0.0.0:40884  weight 1 rise 2 fall 3
server l-40885 0.0.0.0:40885  weight 1 rise 2 fall 3

3.启动端口为40883-40885一模一样的服务,然后请求使用Haproxy的监听40882端口,会自动负载均衡.

4.如果要重启gRPC服务,只需一个个替换,因为我们的服务都是docker启动的,所以重启较简单.这样又实现了灰度发布.

打开http://127.0.0.1:8089/stats,帐号密码:admin,我们可以看到服务情况:

【go】gRPC灰度发布
感谢朋友们,因为查了很多资料,都要实现代码, 查看Nginx了文档后,发现现在支持gRPC还不是很好,最后发现TCP支持,Haproxy做得很好.

grpc原生支持负载均衡，目前我也没有接触到很成熟的解决方案，我们这边是这样解决的，通过多个负载，在单机升级的时候利用别的服务器提供服务，实现类似于热更新的功能。当然可能有一些别的更加好的方案，我这里也是提供一个思路。

我们是有多个服务，滚动更新，出现你说的问题的概率比较小，但也是会发生，要看你的是什么样的请求了，如果请求很慢，有可能出现你说的情况

你说的这一个并不是框架的问题，而是运维的问题，常用的解决方案：

  • 分批发布：假如有12台机器,发布分三批，一次发布4台

  • 优雅上下线：等所有请求结束了下线，收到的新请求直接丢弃，并告知前置服务器当前应用要下线。

以上是 【go】gRPC灰度发布 的全部内容， 来源链接： utcz.com/a/105864.html

回到顶部