Spring Cloud 灰度发布解决方案

绝地灬酷狼 2022-05-24 07:58 546阅读 0赞

> 文章已收录 [架构技术专栏][Link 1] 收藏不迷路，点击获取更多视频资料福利

> 因为目前公司架构全部切换到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服务即可使用，简单易懂。

关注公众号获取更多视频资料：

> 原创不易，专注于分享技术干货文章的地方，可关注我获取更多神秘资料、视频资料，wx搜索:架构技术专栏

> 专注于分享技术干货文章的地方，内容涵盖java基础、中间件、分布式、apm监控方案、异常问题定位等技术栈。多年基础架构经验，擅长基础组件研发，分布式监控系统，热爱技术，热爱分享  
> ![这里写图片描述][70]

[Link 1]: https://www.jiagoujishu.com
[eureka rest api]: /images/20220524/42bf87d7cf254b2cae0dbc8e08df9047.png
[eureka]: /images/20220524/223b53690620479980b0fb9748352298.png
[70]: /images/20220524/7ccf4889466947aca21137d05a8bd009.png