下线英文

SpringCloud优雅下线以及灰度发布

在⽣产环境中，如何保证在服务升级的时候，不影响⽤户的体验，这个是⼀个⾮常重要的问题。如果在我们升级服务的时候，会造成⼀段时

间内的服务不可⽤，这就是不够优雅的。那什么是优雅的呢？主要就是指在服务升级的时候，不中断整个服务，让⽤户⽆感知，进⽽不会影

响⽤户的体验，这就是优雅的。

实际上，优雅下线是⽬标，⽽不是⼿段，它是⼀个相对的概念，例如killPID和kill-9PID都是暴⼒杀死服务，相对于kill-9PID来说，killPID

就是优雅的。但如果单独拿killPID出来说，我们能说它是优雅的下线策略吗？肯定不是啊，就是这个道理。

因此，本⽂讲述的优雅下线仅能称之为“相对的优雅下线”，但相对于暴⼒的杀死服务，已经⾜够优雅了。常见的优雅解决⽅案，主要包括优

雅下线和灰度发布。⽽实际上，灰度发布的范围就已经包含优雅下线了。最后，在本⽂中，我们主要讲述基于SpringCloud和Euraka的优

雅下线以及灰度发布。

优雅下线

常见的下线⽅式

⽅式⼀：killPID

使⽤⽅式：killjava进程ID

该⽅式借助的是SpringBoot应⽤的Shutdownhook，应⽤本⾝的下线也是优雅的，但如果你的服务发现组件使⽤的是Eureka，那么默认

最长会有90秒的延迟，其他应⽤才会感知到该服务下线，这意味着：该实例下线后的90秒内，其他服务仍然可能调⽤到这个已下线的实

例。因此，该⽅式是不够优雅的。

⽅式⼆：/shutdown端点

SpringBoot提供了/shutdown端点，可以借助它实现优雅停机。

使⽤⽅式：在想下线应⽤的applicationyml中添加如下配置，从⽽启⽤并暴露/shutdown端点：

management:

endpoint:

shutdown:

enabled:true

endpoints:

web:

exposure:

include:shutdown

发送POST请求到/shutdown端点

curl-X你想停⽌的服务地址/actuator/shutdown

该⽅式本质和⽅式⼀是⼀样的，也是借助SpringBoot应⽤的Shutdownhook去实现的。

⽅式三：/pau端点

SpringBoot应⽤提供了/pau端点，利⽤该端点可实现优雅下线。

使⽤⽅式：在想下线应⽤的中添加配置，从⽽启⽤并暴露/pau端点：

management:

endpoint:

#启⽤pau端点

pau:

enabled:true

#启⽤restart端点，之所以要启⽤restart端点，是因为pau端点的启⽤依赖restart端点的启⽤

restart:

enabled:true

endpoints:

web:

exposure:

include:pau,restart

发送POST请求到/actuator/pau端点：

curl-XPOST你想停⽌的服务实例地址/actuator/pau

执⾏后的效果类似下图：

如图所⽰，该应⽤在EurekaServer上的状已被标记为DOWN，但是应⽤本⾝其实依然是可以正常对外服务的。在SpringCloud

中，Ribbon做负载均衡时，只会负载到标记为UP的实例上。利⽤这两点，你可以：先⽤/pau端点，将要下线的应⽤标记为DOWN，但不

去真正停⽌应⽤；然后过⼀定的时间（例如90秒，或者⾃⼰做个监控，看当前实例的流量变成0后）再去停⽌应⽤，例如kill应⽤。

缺点&局限

缺点描述不同的版本配置不⼤⼀样早期的SpringCloud版本中，pau端点是不依赖restart端点的⽆法和Eureka的健康检查配合使⽤如果

你的服务发现组件⽤的是Eureka，并且你的应⽤开启了健康检查

d=true，那么/pau端点⽆效

⽅式四：/rvice-registry端点

使⽤⽅式：在想下线应⽤的中添加配置，从⽽暴露/rvice-registry端点：

management:

endpoints:

web:

exposure:

include:rvice-registry

发送POST请求到/actuator/rvice-registry端点：

curl-X"POST""localhost:8000/actuator/rvice-registry?status=DOWN"

-H"Content-Type:application/or.v2+json;chart=UTF-8"

实⾏后的效果类似如下图：

优雅的下线⽅式

在上⽂中，我们讲述了四种常见的下线⽅式，对⽐来看，⽅式四是⼀种⽐较优雅的下线⽅式。

在实际项⽬中，我们可以先使⽤/rvice-registry端点，将服务标记为DOWN，然后监控服务的流量，当流量为0时，即可升级该服务。当

然，这⾥假设我们部署了多个服务实例，当⼀个服务实例DOWN掉之后，其他服务实例仍然是可以提供服务的，如果就部署⼀台服务的话，

那么讨论优不优雅就没那么重要了。

除了上述的下线⽅式之外，还有⼀种利⽤EurekaAutoServiceRegistration对象达到优雅下线的⽬标。

执⾏()⽅法时，当前服务向Eureka注册中⼼注册服务；

执⾏()⽅法时，当前服务会向Eureka注册中⼼进⾏反注册，注册中⼼收到请求后，会将此服务从

注册列表中删除。

⽰例代码如下：

@RestController

@RequestMapping(value="/graceful/registry-rvice")

publicclassGracefulOffline{

@Autowired

privateEurekaAutoServiceRegistrationeurekaAutoServiceRegistration;

@RequestMapping("/online")

publicStringonline(){

();

return"executeonlinemethod,onlinesuccess.";

}

@RequestMapping("/offline")

publicStringoffline(){

();

return"executeofflinemethod,offlinesuccess.";

}

}

到这⾥，我们已经介绍了两种相对优雅的下线⽅式了。具体如何操作，我们可以根据实际上情况进⾏包装，或者利⽤⾃动化的脚本来实现更

加优雅的下线⽅式。

灰度发布

蓝绿部署

蓝绿部署，英⽂名为BlueGreenDeployment，是⼀种可以保证系统在不间断提供服务的情况下上线的部署⽅式。

如何保证系统不间断提供服务呢？那就是同时部署两个集群，但仅对外提供⼀个集群的服务，当需要升级时，切换集群进⾏升级。蓝绿部署

⽆需停机，并且风险较⼩。其⼤致步骤为：

1.部署集群1的应⽤（初始状态），将所有外部请求的流量都打到这个集群上

2.部署集群2的应⽤，集群2的代码与集群1不同，如新功能或者Bug修复等

3.将流量从集群1切换到集群2

4.如集群2测试正常，就删除集群1正在使⽤的资源（例如实例），使⽤集群2对外提供服务

因为在使⽤蓝绿部署的⽅式时，我们需要控制流量，所以我们需要借助路由服务，如Nginx等。

滚动部署

滚动部署，英⽂名为RollingUpdate，同样是⼀种可以保证系统在不间断提供服务的情况下上线的部署⽅式。和蓝绿部署不同的是，滚动部

署对外提供服务的版本并不是⾮此即彼，⽽是在更细的粒度下平滑完成版本的升级。

如何做到细粒度平滑升级版本呢？滚动部署只需要⼀个集群，集群下的不同节点可以独⽴进⾏版本升级。⽐如在⼀个12节点的集群中，我

们每次升级4个节点，并将升级后的节点重新投⼊使⽤，周⽽复始，直到集群中所有的节点都更新为新版本。

这种部署⽅式相对于蓝绿部署，更加节约资源，因为它不需要运⾏两个集群。但这种⽅式也有很多缺点，例如：

1.没有⼀个确定OK的环境。使⽤蓝绿部署，我们能够清晰地知道⽼版本是OK的，⽽使⽤滚动发布，我们⽆法确定。

2.修改了现有的环境。

3.如果需要回滚，很困难。举个例⼦，在某⼀次发布中，我们需要更新100个实例，每次更新10个实例，每次部署需要5分钟。当滚

动发布到第80个实例时，发现了问题，需要回滚。这时，我们估计就要疯了。

4.有的时候，我们还可能对系统进⾏动态伸缩，如果部署期间，系统⾃动扩容/缩容了，我们还需判断到底哪个节点使⽤的是哪个代码。

尽管有⼀些⾃动化的运维⼯具，但是依然令⼈⼼惊胆战。

并不是说滚动发布不好，滚动发布也有它⾮常合适的场景。

⾦丝雀部署

⾦丝雀部署⼜称灰度部署（或者，灰度发布），英⽂名为CanaryDeployment，是指在⿊与⽩之间，能够平滑过渡的⼀种发布⽅式。

⾦丝雀的名称来源于「矿井中的⾦丝雀」，早在17世纪，英国矿井⼯⼈发现，⾦丝雀对⽡斯这种⽓体⼗分敏感，空⽓中哪怕有极其微量的

⽡斯，⾦丝雀也会停⽌歌唱；⽽当⽡斯含量超过⼀定限度时，虽然鲁钝的⼈类毫⽆察觉，⾦丝雀却早已毒发⾝亡。当时在采矿设备相对简陋

的条件下，⼯⼈们每次下井都会带上⼀只⾦丝雀作为“⽡斯检测指标”，以便在危险状况下紧急撤离。

我们来看⼀下⾦丝雀部署的步骤：

1.准备好部署各个阶段的⼯件，包括：构建⼯件，测试脚本，配置⽂件和部署清单⽂件

2.从负载均衡列表中移除掉“⾦丝雀”服务器

3.升级“⾦丝雀”应⽤（切断原有流量并进⾏部署）

4.对应⽤进⾏⾃动化测试

5.将“⾦丝雀”服务器重新添加到负载均衡列表中（连通性和健康检查）

6.如果“⾦丝雀”在线使⽤测试成功，升级剩余的其他服务器（否则就回滚）

在⾦丝雀部署中，常常按照⽤户量设置路由权重，例如90%的⽤户维持使⽤⽼版本，10%的⽤户尝鲜新版本。不同版本应⽤共存，经常与

A/B测试⼀起使⽤，⽤于测试选择多种⽅案。⾦丝雀部署⽐较典型的例⼦，就是我们在使⽤某个应⽤的时候，该应⽤邀请我们进⾏“内测”或

者“新版本体验”，如果我们同意了，那么我们就成了⾦丝雀。

【免责声明：本⽂图⽚及⽂字信息均由千锋重庆Java的⼩编转载⾃⽹络，旨在分享提供阅读，版权归原作者所有，如有侵权请联系我们进⾏

删除。】