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 的，而使用滚动发布，我们无法确定。

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数HarmonyOS鸿蒙开发工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年HarmonyOS鸿蒙开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上HarmonyOS鸿蒙开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新

如果你觉得这些内容对你有帮助，可以添加VX：vip204888 （备注鸿蒙获取）

一个人可以走的很快，但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎扫码加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

888 （备注鸿蒙获取）**
[外链图片转存中…(img-yLetnZGr-1712701103574)]

一个人可以走的很快，但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎扫码加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！