美文网首页JAVA相关
spring cloud灰度发布快速上下线问题解决

spring cloud灰度发布快速上下线问题解决

作者: 架构技术专栏 | 来源:发表于2018-05-23 16:32 被阅读305次

    因为目前公司架构全部切换到spring cloud 模式,对于服务灰度方面没有dubbo zk的方便了,所以细细研究总结下留作备份。目前业界有几种流行的发布部署策略,从网上资料可以搜索到,不是这次重点贴出来看看就行了。

    目前部署的几种策略

    蓝绿部署

    蓝绿部署无需停机,并且风险较小。
    (1) 部署版本1的应用(一开始的状态)
    所有外部请求的流量都打到这个版本上。
    (2) 部署版本2的应用
    版本2的代码与版本1不同(新功能、Bug修复等)。
    (3) 将流量从版本1切换到版本2。
    (4) 如版本2测试正常,就删除版本1正在使用的资源(例如实例),从此正式用版本2。

    滚动发布

    滚动发布,一般是取出一个或者多个服务器停止服务,执行更新,并重新将其投入使用。周而复始,直到集群中所有的实例都更新成新版本。
    这种部署方式相对于蓝绿部署,更加节约资源——它不需要运行两个集群、两倍的实例数。我们可以部分部署,例如每次只取出集群的20%进行升级。
    这种方式也有很多缺点,例如:
    (1) 没有一个确定OK的环境。使用蓝绿部署,我们能够清晰地知道老版本是OK的,而使用滚动发布,我们无法确定。
    (2) 修改了现有的环境。
    (3) 如果需要回滚,很困难。举个例子,在某一次发布中,我们需要更新100个实例,每次更新10个实例,每次部署需要5分钟。当滚动发布到第80个实例时,发现了问题,需要回滚。此时,脾气不好的程序猿很可能想掀桌子,因为回滚是一个痛苦,并且漫长的过程。
    (4) 有的时候,我们还可能对系统进行动态伸缩,如果部署期间,系统自动扩容/缩容了,我们还需判断到底哪个节点使用的是哪个代码。尽管有一些自动化的运维工具,但是依然令人心惊胆战。
    并不是说滚动发布不好,滚动发布也有它非常合适的场景。

    灰度发布

    我们来看一下金丝雀部署的步骤:
    (1) 准备好部署各个阶段的工件,包括:构建工件,测试脚本,配置文件和部署清单文件。
    (2) 从负载均衡列表中移除掉“金丝雀”服务器。
    (3) 升级“金丝雀”应用(排掉原有流量并进行部署)。
    (4) 对应用进行自动化测试。
    (5) 将“金丝雀”服务器重新添加到负载均衡列表中(连通性和健康检查)。
    (6) 如果“金丝雀”在线使用测试成功,升级剩余的其他服务器。(否则就回滚)
    灰度发布中,常常按照用户设置路由权重,例如90%的用户维持使用老版本,10%的用户尝鲜新版本。不同版本应用共存,经常与A/B测试一起使用,用于测试选择多种方案。灰度发布比较典型的例子,是阿里云那个“新版本”,点击“进入新版本”,我们就成了金丝雀

    下面进入正题,针对于spring cloud 灰度发布可以分为几个点:
    1、优雅停机
    2、服务快速注册
    3、服务快速订阅
    下面针对于这三个点进行梳理

    一、优雅停机

    你如果使用kill -9 那肯定不算优雅停机了,内部没执行完的线程全部搞死了。所以,优雅停机的关键点:反注册当前服务阻挡前端路由流量、等待应用内部线程执行完毕、反注册内部各种监听器、关闭应用。cloud 可以说为我们提供了两种模式,一种是基于端点的shutdown 接口,另一种就是基于eureka rest api 的模式。

    1、基于shutdown 接口
    其实细细观察这两种模式实现是一样的,先说shutdown 这种模式非常简单。直接执行http://localhost:8080/shutdown 即可。
    下面先说下使用配置:

    1. 加入spring-boot-starter-actuator 模块,反注册基于此模块的shutdown端点接口。
    2. 启用shutdown endpoints.shutdown.enabled=true

    2、基于eureka rest api 进行服务下线配置
    这个其实是eureka 为我们提供好的接口,可以对服务进行各种简单的上下线操作。
    官方地址:https://github.com/Netflix/eureka/wiki/Eureka-REST-operations

    eureka rest api

    这两种方式都可以实现服务快速下线,下面贴下服务shutdown 的源码以供学习参考,此代码为DiscoveryClient 从改类进行各种操作:

     @PreDestroy
        @Override
        public synchronized void shutdown() {
            if (isShutdown.compareAndSet(false, true)) {
                logger.info("Shutting down DiscoveryClient ...");
    
                if (statusChangeListener != null && applicationInfoManager != null) {
                    applicationInfoManager.unregisterStatusChangeListener(statusChangeListener.getId());
                }
    
                cancelScheduledTasks();
    
                // If APPINFO was registered
                if (applicationInfoManager != null && clientConfig.shouldRegisterWithEureka()) {
                    applicationInfoManager.setInstanceStatus(InstanceStatus.DOWN);
                    unregister();
                }
    
                if (eurekaTransport != null) {
                    eurekaTransport.shutdown();
                }
    
                heartbeatStalenessMonitor.shutdown();
                registryStalenessMonitor.shutdown();
    
                logger.info("Completed shut down of DiscoveryClient");
            }
        }
    

    二、服务快速注册与快速订阅

    针对于这一点可是比较恶心的,因为eureka的注册订阅都是HTTP的,不像dubbo使用了zk可以进行监听,默认的配置也可以使用,但是可能导致一些小问题,比如最主要的就是注册了服务好一会发现不了一直报connection refused.究其原因就是因为cloud 的各种缓存机制的问题。
    先看下问题:

    服务正常注册,最大可能会有120s滞后

    • 30(首次注册 init registe) + 30(readOnlyCacheMap)+30(client fetch interval)+30(ribbon)=120
    • 如果是在Spring Cloud环境下使用这些组件(Eureka, Ribbon),不会有首次注册30秒延迟的问题,服务启动后会马上注册,所以从注册到发现,最多可能是90s。

    服务异常下线:最大可能会有270s滞后

    • 定时清理任务每eureka.server. evictionIntervalTimerInMs(默认60)执行一次清理任务
    • 每次清理任务会把90秒(3个心跳周期,eureka.instance.leaseExpirationDurationInSeconds)没收到心跳的踢除,但是根据官方的说法 ,因为代码实现的bug,这个时间其实是两倍,即180秒,也就是说如果一个客户端因为网络问题或者主机问题异常下线,可能会在180秒后才剔除
    • 读取端,因为readOnlyCacheMap以及客户端缓存的存在,可能会在30(readOnlyCacheMap)+30(client fetch interval)+30(ribbon)=90
    • 所以极端情况最终可能会是180+90=270

    从网上套了一个图给大家看看:


    eureka

    究其原因无非可以分为三个点:
    【服务端缓存】

    • eureka server 缓存,一个ReadWriteMap一个ReadOnlyMap,定期会从ReadWriteMap 把数据同步到ReadOnlyMap 据说这样可以增大吞吐量。
    • 读默认client是从readOnlyCacheMap读取数据,读不到的话再从readWriterCacheMap,还没有再从registry读
    • readOnlyCacheMap 有开关可以关闭useReadOnlyResponseCache

    【客户端缓存】

    • 由eureka.client.registryFetchIntervalSeconds控制,默认30秒。
    • 服务提供者注册服务后会定时心跳,默认如果连续三次心跳失败,同时没有处于保护模式下将进行服务剔除操作,这些参数可在client配置。
    • 因为eureka 会本地缓存配置,所以一般每次定时会从服务端增量拉去。

    【Ribbon缓存】

    • 如果你采用Ribbon来访问服务,那么这里会有个缓存(他的数据来源是本地Eureka Client缓存)

    生产环境配置

    Eureka Server 端配置

    中小规模下,自我保护模式坑比好处多,所以关闭它
    eureka.server.enableSelfPreservation=false
    主动失效检测间隔,配置成5秒
    eureka.server.eviction-interval-timer-in-ms=5000
    禁用readOnlyCacheMap(中小集群可以直接关闭,但在大集群中建议还是开启,使用eureka.server.responseCacheUpdateInvervalMs=3000进行配置)
    eureka.server.use-read-only-response-cache=false

    Eureka 服务提供方配置

    服务过期时间配置,超过这个时间没有接收到心跳EurekaServer就会将这个实例剔除
    注意,EurekaServer一定要设置eureka.server.eviction-interval-timer-in-ms否则这个配置无效,这个配置一般为服务刷新时间配置的三倍,默认90s
    eureka.instance.lease-expiration-duration-in-seconds=15
    服务刷新时间配置,每隔这个时间会主动心跳一次,默认30s
    eureka.instance.lease-renewal-interval-in-seconds=5

    Eureka 服务调用方配置

    定时刷新本地缓存时间
    eureka.client.registry-fetch-interval-seconds=5
    ribbon缓存刷新时间
    ribbon.ServerListRefreshInterval=3000

    至此,cloud简单的灰度发布基本完成,不用担心上下线大面积报错的问题了,但如果需要流量切换,A/B测试等功能要求那就是另说了。
    最后总结下:使用shutdown 接口进行下线操作,然后重启新应用进行上线操作,最长8s服务即可使用,简单易懂。

    关注

    相关文章

      网友评论

      本文标题:spring cloud灰度发布快速上下线问题解决

      本文链接:https://www.haomeiwen.com/subject/uvmrjftx.html