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

标签: | 发表时间:2020-02-16 00:04 | 作者:
出处:https://www.jianshu.com

因为目前公司架构全部切换到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 灰度] 推荐:

Spring Cloud版本控制和灰度starter-spring-cloud-gray

- -
Spring Cloud Gray - 微服务灰度中间件. Spring Cloud Gray 是一套开源的微服务灰度路由解决方案,它由spring-cloud-gray-client,spring-cloud-gray-client-netflix 和 spring-cloud-tray-server,spring-cloud-gray-webui组成.

大话 Spring Cloud

- - IT瘾-dev
研究了一段时间spring boot了准备向spirng cloud进发,公司架构和项目也全面拥抱了Spring Cloud. 在使用了一段时间后发现Spring Cloud从技术架构上降低了对大型系统构建的要求,使我们以非常低的成本(技术或者硬件)搭建一套高效、分布式、容错的平台,但Spring Cloud也不是没有缺点,小型独立的项目不适合使用.

Spring Cloud限流详解 | Spring Cloud|周立

- -
限流往往是一个绕不开的话题. 本文详细探讨在Spring Cloud中如何实现限流. Zuul上实现限流是个不错的选择,只需要编写一个过滤器就可以了,关键在于如何实现限流的算法. 常见的限流算法有漏桶算法以及令牌桶算法. https://www.cnblogs.com/LBSer/p/4083131.html,写得通俗易懂,你值得拥有,我就不拽文了.

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

- -
因为目前公司架构全部切换到spring cloud 模式,对于服务灰度方面没有dubbo zk的方便了,所以细细研究总结下留作备份. 目前业界有几种流行的发布部署策略,从网上资料可以搜索到,不是这次重点贴出来看看就行了. 蓝绿部署无需停机,并且风险较小. (1) 部署版本1的应用(一开始的状态). 所有外部请求的流量都打到这个版本上.

Spring Cloud Kubernetes指南

- -
当我们构建微服务解决方案时,SpringCloud和Kubernetes都是最佳解决方案,因为它们为解决最常见的挑战提供组件. 但是,如果我们决定选择Kubernetes作为我们的解决方案的主要容器管理器和部署平台,我们仍然可以主要通过SpringCloudKubernetes项目使用SpringCloud的有趣特性.

Spring Cloud实践:降级、限流、滚动、灰度、AB、金丝雀的实现思路

- - 程序猿DD | 博客
之前在我博客的 问答平台和 Spring4All社区均有关于Spring Cloud的发布策略实现问题. 虽然大家都给力很多不错的思路和建议,但是都没有 Charles He的这篇文章详细. 因此经得作者同意,在这里转载了该篇内容,为了更好的阅读体验,稍作一些格式调整,分享给更多Spring Cloud爱好者.

spring cloud 实践-降级、限流、滚动、灰度、AB、金丝雀等等等等 - 简书

- -
spring cloud 实践. 源码地址:https://github.com/charlesvhe/spring-cloud-practice. 端口:8888,方便起见直接读取配置文件,生产环境可以读取git. application-dev.properties为全局配置. 先启动配置中心,所有服务的配置(包括注册中心的地址)均从配置中心读取.

Spring Cloud 快速入门

- - IT瘾-tuicool
Spring Cloud 是一套完整的微服务解决方案,基于 Spring Boot 框架,准确的说,它不是一个框架,而是一个大的容器,它将市面上较好的微服务框架集成进来,从而简化了开发者的代码量. 本课程由浅入深带领大家一步步攻克 Spring Cloud 各大模块,接着通过一个实例带领大家了解大型分布式微服务架构的搭建过程,最后深入源码加深对它的了解.

Deploy the spring cloud project using jenkins

- - Telami
先简单记录下Jenkins部署maven聚合工程要点. Root pom配置成项目根目录的pom.xml. maven命令单独install 欲构建的项目. 选项后可跟随{groupId}:{artifactId}或者所选模块的相对路径(多个模块以逗号分隔). 表示同时处理选定模块所依赖的模块. 表示同时处理依赖选定模块的模块.

Spring Cloud Gateway(限流) | Wind Mt

- -
限流可以保障我们的 API 服务对所有用户的可用性,也可以防止网络攻击. 一般开发高并发系统常见的限流有:限制总并发数(比如数据库连接池、线程池)、限制瞬时并发数(如 nginx 的 limit_conn 模块,用来限制瞬时并发连接数)、限制时间窗口内的平均速率(如 Guava 的 RateLimiter、nginx 的 limit_req 模块,限制每秒的平均速率);其他还有如限制远程接口调用速率、限制 MQ 的消费速率.