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

因为目前公司架构全部切换到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 即可。
下面先说下使用配置：

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

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

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

 @PreDestroy@Overridepublic 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 registeredif (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 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监控方案、异常问题定位等技术栈。多年基础架构经验，擅长基础组件研发，分布式监控系统，热爱技术，热爱分享

Spring Cloud 灰度发布解决方案相关推荐

Spring cloud 灰度发布
Spring Cloud灰度发布之Nepxion Discovery 架构升级,有单体架构升级为微服务架构. 服务的灰度发布,根据访问量逐渐切换用新版本替换老版本,并且能够做到代码零入侵的. Nepx ...
spring cloud灰度发布快速上下线问题解决
因为目前公司架构全部切换到spring cloud 模式,对于服务灰度方面没有dubbo zk的方便了,所以细细研究总结下留作备份.目前业界有几种流行的发布部署策略,从网上资料可以搜索到,不是这次重点 ...
1、Nepxion Discovery：Spring Cloud灰度发布神器
原文地址:http://dockone.io/article/8149 Nepxion Discovery是一款对Spring Cloud服务注册发现和负载均衡的增强中间件,其功能包括灰度发布(包括切 ...
厉害了，Spring Cloud Alibaba 发布 GA 版本！
小马哥 & Josh Long 喜欢写一首诗一般的代码,更喜欢和你共同 code review,英雄的相惜,犹如时间沉淀下来的对话,历久方弥新. 相见如故,@杭州. 4 月 18 日,Josh ...
Spring Cloud Alibaba发布第二个版本，Spring 发来贺电
2019独角兽企业重金招聘Python工程师标准>>> 还是熟悉的面孔,还是熟悉的味道,不同的是,这次的配方升级了. 今年10月底,Spring Cloud联合创始人Spencer ...
Spring Cloud Alibaba发布第二个版本，Spring 发来贺电 1
还是熟悉的面孔,还是熟悉的味道,不同的是,这次的配方升级了. 今年10月底,Spring Cloud联合创始人Spencer Gibb在Spring官网的博客页面宣布:阿里巴巴开源 Spring Cl ...
kafka灰度发布解决方案
Kafka灰度发布解决方案场景设计方案场景由于我们生产环境和灰度环境共用一套kafka,灰度环境主要用于线上验证和紧急问题修复,但是有时灰度发布后,会消费生产环境的kafka数据,影响生产环境 ...
spring boot和spring cloud版本冲突解决方案
spring cloud和springboot版本是需要匹配才能一起使用的.在新建项目的时候,如果两者版本不一致,很有可能会导致项目启动失败. spring cloud和springboot的版本对应 ...
Spring Cloud Alibaba一站式解决方案
一.Spring Cloud Alibaba一站式解决方案在springCloud的基础上延伸出来的微服务技术栈为什么学习spring cloud alibaba? spring cloud多项组 ...

Spring Cloud 灰度发布解决方案