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