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服务器来处理客户端调用。在客户端拥有一个存根能够像服务端一样的方法,即调用仿佛就在同一台机器。

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

阅读 2.9k
评论 2017-08-30 提问
    4 个回答

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

    所需软件参见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,我们可以看到服务情况:

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

    评论 赞赏 2017-11-23

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

      评论 赞赏 2017-08-31

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

        评论 赞赏 2017-08-31

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

          • 分批发布:假如有12台机器,发布分三批,一次发布4台
          • 优雅上下线:等所有请求结束了下线,收到的新请求直接丢弃,并告知前置服务器当前应用要下线。
          评论 赞赏 2017-08-31
            撰写回答

            登录后参与交流、获取后续更新提醒