Spring Cloud优雅下线+灰度发布
Java研发军团
共 5526字,需浏览 12分钟
·
2022-08-26 18:51
前言
kill PID
和kill -9 PID
都是暴力杀死服务,相对于kill -9 PID
来说,kill PID
就是优雅的。但如果单独拿kill PID
出来说,我们能说它是优雅的下线策略吗?肯定不是啊,就是这个道理。优雅下线
常见的下线方式
方式一:kill PID
Shutdown hook
,应用本身的下线也是优雅的,但如果你的服务发现组件使用的是 Eureka,那么默认最长会有 90 秒的延迟,其他应用才会感知到该服务下线,这意味着:该实例下线后的 90 秒内,其他服务仍然可能调用到这个已下线的实例。因此,该方式是不够优雅的 。方式二:/shutdown端点
/shutdown
端点,可以借助它实现优雅停机。/shutdown
端点:management:
endpoint:
shutdown:
enabled: true
endpoints:
web:
exposure:
include: shutdown
curl -X http://你想停止的服务地址/actuator/shutdown
方式三:/pause端点
/pause
端点,利用该端点可实现优雅下线。/pause
端点:management:
endpoint:
# 启用pause端点
pause:
enabled: true
# 启用restart端点,之所以要启用restart端点,是因为pause端点的启用依赖restart端点的启用
restart:
enabled: true
endpoints:
web:
exposure:
include: pause,restart
/actuator/pause
端点:curl -X POST http://你想停止的服务实例地址/actuator/pause
/pause
端点,将要下线的应用标记为DOWN,但不去真正停止应用;然后过一定的时间(例如 90 秒,或者自己做个监控,看当前实例的流量变成 0 后)再去停止应用,例如kill
应用。方式四:/service-registry端点
/service-registry
端点:management:
endpoints:
web:
exposure:
include: service-registry
/actuator/service-registry
端点:curl -X "POST" "http://localhost:8000/actuator/service-registry?status=DOWN" \
-H "Content-Type: application/vnd.spring-boot.actuator.v2+json;charset=UTF-8"
优雅的下线方式
/service-registry
端点,将服务标记为DOWN,然后监控服务的流量,当流量为 0 时,即可升级该服务。当然,这里假设我们部署了多个服务实例,当一个服务实例DOWN掉之后,其他服务实例仍然是可以提供服务的,如果就部署一台服务的话,那么讨论优不优雅就没那么重要了。EurekaAutoServiceRegistration
对象达到优雅下线的目标。执行 eurekaAutoServiceRegistration.start()
方法时,当前服务向 Eureka 注册中心注册服务;执行 eurekaAutoServiceRegistration.stop()
方法时,当前服务会向 Eureka 注册中心进行反注册,注册中心收到请求后,会将此服务从注册列表中删除。
@RestController
@RequestMapping(value = "/graceful/registry-service")
public class GracefulOffline {
@Autowired
private EurekaAutoServiceRegistration eurekaAutoServiceRegistration;
@RequestMapping("/online")
public String online() {
this.eurekaAutoServiceRegistration.start();
return "execute online method, online success.";
}
@RequestMapping("/offline")
public String offline() {
this.eurekaAutoServiceRegistration.stop();
return "execute offline method, offline success.";
}
}
灰度发布
蓝绿部署
部署集群 1 的应用(初始状态),将所有外部请求的流量都打到这个集群上 部署集群 2 的应用,集群 2 的代码与集群 1 不同,如新功能或者 Bug 修复等 将流量从集群 1 切换到集群 2 如集群 2 测试正常,就删除集群 1 正在使用的资源(例如实例),使用集群 2 对外提供服务
滚动部署
没有一个确定 OK 的环境。使用蓝绿部署,我们能够清晰地知道老版本是 OK 的,而使用滚动发布,我们无法确定。 修改了现有的环境。 如果需要回滚,很困难。举个例子,在某一次发布中,我们需要更新 100 个实例,每次更新 10 个实例,每次部署需要 5 分钟。当滚动发布到第 80 个实例时,发现了问题,需要回滚。这时,我们估计就要疯了。 有的时候,我们还可能对系统进行动态伸缩,如果部署期间,系统自动扩容/缩容了,我们还需判断到底哪个节点使用的是哪个代码。尽管有一些自动化的运维工具,但是依然令人心惊胆战。
金丝雀部署
准备好部署各个阶段的工件,包括:构建工件,测试脚本,配置文件和部署清单文件 从负载均衡列表中移除掉“金丝雀”服务器 升级“金丝雀”应用(切断原有流量并进行部署) 对应用进行自动化测试 将“金丝雀”服务器重新添加到负载均衡列表中(连通性和健康检查) 如果“金丝雀”在线使用测试成功,升级剩余的其他服务器(否则就回滚)
转自:CG国斌
链接:https://blog.csdn.net/qq_35246620/article/details/109166722
评论