Spring Cloud 优雅下线以及灰度发布实现

前言

在生产环境中,如何保证在服务升级的时候,不影响用户的体验,这个是一个非常重要的问题。如果在我们升级服务的时候,会造成一段时间内的服务不可用,这就是不够优雅的。那什么是优雅的呢?主要就是指在服务升级的时候,不中断整个服务,让用户无感知,进而不会影响用户的体验,这就是优雅的。

实际上,优雅下线是目标,而不是手段,它是一个相对的概念,例如kill PIDkill -9 PID都是暴力杀死服务,相对于kill -9 PID来说,kill PID就是优雅的。但如果单独拿kill PID出来说,我们能说它是优雅的下线策略吗?肯定不是啊,就是这个道理。

因此,本文讲述的优雅下线仅能称之为“相对的优雅下线”,但相对于暴力的杀死服务,已经足够优雅了。常见的优雅解决方案,主要包括优雅下线和灰度发布。而实际上,灰度发布的范围就已经包含优雅下线了。最后,在本文中,我们主要讲述基于 Spring Cloud 和 Euraka 的优雅下线以及灰度发布。

优雅下线

常见的下线方式

方式一:kill PID

使用方式:kill java进程ID

该方式借助的是 Spring Boot 应用的 Shutdown hook,应用本身的下线也是优雅的,但如果你的服务发现组件使用的是 Eureka,那么默认最长会有 90 秒的延迟,其他应用才会感知到该服务下线,这意味着:该实例下线后的 90 秒内,其他服务仍然可能调用到这个已下线的实例。因此,该方式是不够优雅的 。

方式二:/shutdown端点

Spring Boot 提供了/shutdown端点,可以借助它实现优雅停机。

使用方式:在想下线应用的applicationyml中添加如下配置,从而启用并暴露/shutdown端点:

management:
 endpoint:
  shutdown:
   enabled: true
 endpoints:
  web:
   exposure:
    include: shutdown

发送 POST 请求到/shutdown端点

curl -X http://你想停止的服务地址/actuator/shutdown

该方式本质和方式一是一样的,也是借助 Spring Boot 应用的 Shutdown hook 去实现的。

方式三:/pause端点

Spring Boot 应用提供了/pause端点,利用该端点可实现优雅下线。

使用方式:在想下线应用的application.yml中添加配置,从而启用并暴露/pause端点:

management:
 endpoint:
  # 启用pause端点
  pause:
   enabled: true
  # 启用restart端点,之所以要启用restart端点,是因为pause端点的启用依赖restart端点的启用
  restart:
   enabled: true
 endpoints:
  web:
   exposure:
    include: pause,restart

发送 POST 请求到/actuator/pause端点:

curl -X POST http://你想停止的服务实例地址/actuator/pause

执行后的效果类似下图:

如图所示,该应用在 Eureka Server 上的状已被标记为DOWN,但是应用本身其实依然是可以正常对外服务的。在 Spring Cloud 中,Ribbon 做负载均衡时,只会负载到标记为UP的实例上。利用这两点,你可以:先用/pause端点,将要下线的应用标记为DOWN,但不去真正停止应用;然后过一定的时间(例如 90 秒,或者自己做个监控,看当前实例的流量变成 0 后)再去停止应用,例如kill应用。

缺点 & 局限

缺点 描述
不同的版本配置不大一样 早期的 Spring Cloud 版本中,pause端点是不依赖restart端点的
无法和 Eureka 的健康检查配合使用 如果你的服务发现组件用的是 Eureka,并且你的应用开启了健康检查eureka.client.healthcheck.enabled = true,那么/pause端点无效

方式四:/service-registry端点

使用方式:在想下线应用的application.yml中添加配置,从而暴露/service-registry端点:

management:
 endpoints:
  web:
   exposure:
    include: service-registry

发送 POST 请求到/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.";
  }
}

到这里,我们已经介绍了两种相对优雅的下线方式了。具体如何操作,我们可以根据实际上情况进行包装,或者利用自动化的脚本来实现更加优雅的下线方式。

灰度发布

蓝绿部署

蓝绿部署,英文名为 Blue Green Deployment,是一种可以保证系统在不间断提供服务的情况下上线的部署方式。

如何保证系统不间断提供服务呢?那就是同时部署两个集群,但仅对外提供一个集群的服务,当需要升级时,切换集群进行升级。蓝绿部署无需停机,并且风险较小。其大致步骤为:

  1. 部署集群 1 的应用(初始状态),将所有外部请求的流量都打到这个集群上
  2. 部署集群 2 的应用,集群 2 的代码与集群 1 不同,如新功能或者 Bug 修复等
  3. 将流量从集群 1 切换到集群 2
  4. 如集群 2 测试正常,就删除集群 1 正在使用的资源(例如实例),使用集群 2 对外提供服务

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

滚动部署

滚动部署,英文名为 Rolling Update,同样是一种可以保证系统在不间断提供服务的情况下上线的部署方式。和蓝绿部署不同的是,滚动部署对外提供服务的版本并不是非此即彼,而是在更细的粒度下平滑完成版本的升级。

如何做到细粒度平滑升级版本呢?滚动部署只需要一个集群,集群下的不同节点可以独立进行版本升级。比如在一个 12 节点的集群中,我们每次升级 4 个节点,并将升级后的节点重新投入使用,周而复始,直到集群中所有的节点都更新为新版本。

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

  1. 没有一个确定 OK 的环境。使用蓝绿部署,我们能够清晰地知道老版本是 OK 的,而使用滚动发布,我们无法确定。
  2. 修改了现有的环境。
  3. 如果需要回滚,很困难。举个例子,在某一次发布中,我们需要更新 100 个实例,每次更新 10 个实例,每次部署需要 5 分钟。当滚动发布到第 80 个实例时,发现了问题,需要回滚。这时,我们估计就要疯了。
  4. 有的时候,我们还可能对系统进行动态伸缩,如果部署期间,系统自动扩容/缩容了,我们还需判断到底哪个节点使用的是哪个代码。尽管有一些自动化的运维工具,但是依然令人心惊胆战。

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

金丝雀部署

金丝雀部署又称灰度部署(或者,灰度发布),英文名为 Canary Deployment,是指在黑与白之间,能够平滑过渡的一种发布方式。

金丝雀的名称来源于「矿井中的金丝雀」,早在 17 世纪,英国矿井工人发现,金丝雀对瓦斯这种气体十分敏感,空气中哪怕有极其微量的瓦斯,金丝雀也会停止歌唱;而当瓦斯含量超过一定限度时,虽然鲁钝的人类毫无察觉,金丝雀却早已毒发身亡。当时在采矿设备相对简陋的条件下,工人们每次下井都会带上一只金丝雀作为“瓦斯检测指标”,以便在危险状况下紧急撤离。

我们来看一下金丝雀部署的步骤:

  1. 准备好部署各个阶段的工件,包括:构建工件,测试脚本,配置文件和部署清单文件
  2. 从负载均衡列表中移除掉“金丝雀”服务器
  3. 升级“金丝雀”应用(切断原有流量并进行部署)
  4. 对应用进行自动化测试
  5. 将“金丝雀”服务器重新添加到负载均衡列表中(连通性和健康检查)
  6. 如果“金丝雀”在线使用测试成功,升级剩余的其他服务器(否则就回滚)

在金丝雀部署中,常常按照用户量设置路由权重,例如 90% 的用户维持使用老版本,10% 的用户尝鲜新版本。不同版本应用共存,经常与 A/B 测试一起使用,用于测试选择多种方案。金丝雀部署比较典型的例子,就是我们在使用某个应用的时候,该应用邀请我们进行“内测”或者“新版本体验”,如果我们同意了,那么我们就成了金丝雀。

参考资料

实用技巧:Spring Cloud中,如何优雅下线微服务?
Spring cloud系列20 实现服务优雅上下线
Spring Cloud 灰度发布解决方案
一文搞懂蓝绿部署和金丝雀发布
微服务部署:蓝绿部署、滚动部署、灰度发布、金丝雀发布

到此这篇关于Spring Cloud 优雅下线以及灰度发布实现的文章就介绍到这了,更多相关Spring Cloud 优雅下线及灰度发布内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们!

(0)

相关推荐

  • Spring Cloud Eureka 服务上下线监控的实现

    之前我们有介绍通过Spring Boot Admin来检测服务的上下线,然后进行通知功能. https://www.jb51.net/article/130943.htm 今天为大家介绍另外一种实现的方式,在Eureka服务中进行检测通知,Eureka中提供了事件监听的方式来支持扩展. EurekaInstanceCanceledEvent 服务下线事件 EurekaInstanceRegisteredEvent 服务注册事件 EurekaInstanceRenewedEvent 服务续约事件

  • SpringCloud服务的平滑上下线的方法

    吐槽 以前都是手撸RPC,最近接触SpringCloud,深感痛心.主要有以下几点: 1)代码量巨大,找BUG时间长,超级复杂的设计 2)版本管理混乱,经常出现莫名其妙的配置错误(所以2.0是打死不敢上生产啊) 3)Netflix公司的有些代码,实在是让人费解,根本就不考虑扩展性 4)生态链庞大,学习成本大 建议准备上微服务的同学,固定下一个版本,不要随意更新或降级.拿tomcat的basedir来说,1.5.8到1.5.13到1.5.16版本是换来换去,不小心点会出事故的. server: p

  • 细说Springcloud eureka的几种主动下线服务的方式

    本文会介绍几种eureka 注册中心服务下线的方式 补充:在启动eureka服务的时候发现控制台有以下的输出 由此猜想可以通过改接口下线服务, 于是尝试了一下 果然能从注册中心中移除该实例 1. 直接停掉服务. 默认情况下,如果Eureka Server在90秒没有收到Eureka客户的续约,它会将实例从其注册表中删除.但这种做法的不好之处在于, 客户端已经停止了运行,但仍然在注册中心的列表中. 虽然通过一定的负载均衡策略或使用熔断器可以让服务正常进行,但有没有方法让注册中心马上知道服务已经下线

  • Spring Cloud 优雅下线以及灰度发布实现

    前言 在生产环境中,如何保证在服务升级的时候,不影响用户的体验,这个是一个非常重要的问题.如果在我们升级服务的时候,会造成一段时间内的服务不可用,这就是不够优雅的.那什么是优雅的呢?主要就是指在服务升级的时候,不中断整个服务,让用户无感知,进而不会影响用户的体验,这就是优雅的. 实际上,优雅下线是目标,而不是手段,它是一个相对的概念,例如kill PID和kill -9 PID都是暴力杀死服务,相对于kill -9 PID来说,kill PID就是优雅的.但如果单独拿kill PID出来说,我们

  • 浅谈Spring Cloud Netflix-Ribbon灰度方案之Zuul网关灰度

    Eureka默认集成了Ribbon,所以Ribbon的灰度实现原理就是借助服务注册到Eureka中的eureka.instance.metadata-map的内容来进行匹配的. Zuul网关的灰度实现也是借助了一个Ribbon的插件来实现,相对比较简单. 项目环境说明:有两个eureka的服务端(eureka-server),有两个相同的后端服务(service-sms),有一个网关服务(cloud-zuul). 1.网关的依赖: <?xml version="1.0" enco

  • Spring Cloud Alibaba 本地调试介绍及方案设计

    目录 1 本地调试介绍 2 框架环境 3 方案设计 4 实现要点 5. 总结 附:工具方法 1 本地调试介绍 本地调试: 这里是指在开发环境中,部署了一整套的某个项目或者产品的服务,开发人员开发时,本地会起一个或多个服务,这些服务和开发环境中部署的服务是相同的,这种情况下,一个服务就会有多个实例,大多数微服务中的默认负载均衡策略都是轮询,这些实例会轮流被调用. 为了方便 本地调试,需要提供一种策略,可以指定在负载均衡时,选择哪个实例进行调用.在使用 Nacos 作为注册中心时,可以通过 上线和下

  • 详解Spring Cloud Zuul 服务网关

    有了Eureka服务注册发现.Hystrix断路器.Ribbon服务调用负载均衡,以及spring cloud config 集群配置中心,似乎一个微服务框架已五脏俱全,last but not least,一个服务网关却不可或缺. Spring Cloud Zuul路由是微服务架构的不可或缺的一部分,提供动态路由,监控,弹性,安全等的边缘服务.Zuul是Netflix出品的一个基于JVM路由和服务端的负载均衡器. Zuul介绍 在整个Spring Cloud微服务框架里,Zuul扮演着"智能网

  • Spring Cloud 请求重试机制核心代码分析

    场景 发布微服务的操作一般都是打完新代码的包,kill掉在跑的应用,替换新的包,启动. spring cloud 中使用eureka为注册中心,它是允许服务列表数据的延迟性的,就是说即使应用已经不在服务列表了,客户端在一段时间内依然会请求这个地址.那么就会出现请求正在发布的地址,而导致失败. 我们会优化服务列表的刷新时间,以提高服务列表信息的时效性.但是无论怎样,都无法避免有那么一段时间是数据不一致的. 所以我们想到一个办法就是重试机制,当a机子在重启时,同个集群的b是可以正常提供服务的,如果有

  • 利用Spring Cloud Config结合Bus实现分布式配置中心的步骤

    概述 假设现在有个需求: 我们的应用部署在10台机器上,当我们调整完某个配置参数时,无需重启机器,10台机器自动能获取到最新的配置. 如何来实现呢?有很多种,比如: 1.将配置放置到一个数据库里面,应用每次读取配置都是直接从DB读取.这样的话,我们只需要做一个DB变更,把最新的配置信息更新到数据库即可.这样无论多少台应用,由于都从同一个DB获取配置信息,自然都能拿到最新的配置. 2.每台机器提供一个更新配置信息的updateConfig接口,当需要修改配置时,挨个调用服务器的updateConf

  • Spring Cloud Alibaba 之 Nacos教程详解

    Nacos 技术讲解 一提到分布式系统就不的不提一下 CAP 原则 Nacos简介 Nacos是阿里的一个开源产品,它是针对微服务架构中的服务发现.配置管理.服务治理的综合性解决方案. 官方介绍是这样的: Nacos致力于帮助您发现.配置和管理微服务.Nacos提供了一组简单易用的特性集,帮助您实现动态服务发现.服务配置管理.服务及流量管理.Nacos帮助您更敏捷和容易地构建.交付和管理微服务平台.Nacos是构建以"服务"为中心的现代应用架构的服务基础设施. 什么是CAP CAP原则

  • Spring Cloud详细讲解zuul集成Eureka流程

    目录 zuul集成Eureka Zuul路由配置 1. 指定具体服务路由 2. 路由前缀 Zuul过滤器 过滤器类型 使用过滤器 zuul集成Eureka 通过刚才的示例,我们已经可以简单地使用 Zuul 进行路由的转发了,在实际使用中我们通常是用 Zuul 来代理请求转发到内部的服务上去,统一为外部提供服务.内部服务的数量会很多,而且可以随时扩展,我们不可能每增加一个服务就改一次路由的配置,所以也得通过结合 Eureka 来实现动态的路由转发功能.首先需要添加 Eureka 的依赖,代码如下所

  • spring cloud 之 Feign 使用HTTP请求远程服务的实现方法

    一.Feign 简介 在spring Cloud Netflix栈中,各个微服务都是以HTTP接口的形式暴露自身服务的,因此在调用远程服务时就必须使用HTTP客户端.我们可以使用JDK原生的URLConnection.Apache的Http Client.Netty的异步HTTP Client, Spring的RestTemplate.但是,用起来最方便.最优雅的还是要属Feign了. Feign是一种声明式.模板化的HTTP客户端.在Spring Cloud中使用Feign, 我们可以做到使用

  • 详解spring cloud config实现datasource的热部署

    关于spring cloud config的基本使用,前面的博客中已经说过了,如果不了解的话,请先看以前的博客 spring cloud config整合gitlab搭建分布式的配置中心 spring cloud config分布式配置中心的高可用 今天,我们的重点是如何实现数据源的热部署. 1.在客户端配置数据源 @RefreshScope @Configuration// 配置数据源 public class DataSourceConfigure { @Bean @RefreshScope

随机推荐