这篇文章给大家聊聊关于实操：大规模微服务架构下的优雅停机-微服务优雅下线，以及对应的知识点，希望对各位有所帮助，不要忘了收藏本站哦。

大规模微服务改造后，白天重启或扩缩容服务实例时，系统经常会出现“无法连接到服务器”的错误（该错误是微服务框架抛出的异常，表明客户端无法连接到服务器）访问服务器）。到指定的服务器），导致部分用户无法接受服务，影响用户感知。

[[339209]]

问题分析我们生产环境的微服务框架是通过向Zookeeper进行服务注册来发现的。如下图1所示：

图1：服务注册调用流程图

其主要调用逻辑为：

生成容器，并在容器中启动服务；注册到服务路由器（Zookeeper）；服务调用者订阅服务路由器；服务路由器发生注册变化，通知服务调用者获取新的注册列表；服务调用方根据获取的服务端列表获取新的注册列表进行服务调用。但当服务器实例停止时，由于服务器不会主动更改业务路由器上的注册信息，因此客户端需要40秒（目前应用于Zookeeper的会话超时配置）来消除此异常配置。在这40秒内应用程序仍然会继续尝试访问这个不存在的实例，从而导致大量的业务错误。

这也与每次实例重启后错误的持续时间一致。并且由于微服务的特性，每个实际业务请求都会根据业务需求多次调用同一个服务，这就增加了每个业务请求访问异常实例的可能性，加剧了业务失败的概率。

所以这是微服务架构下由服务实例暴力停止导致并因单个业务请求多次访问而放大的问题。

解决方案由于这是服务实例暴力关闭导致的问题，所以我们开始研究基于微服务的优雅关闭方法。

微服务架构中应用程序的优雅关闭主要是指应用程序实例有计划地平滑退出（即不进行任何需要处理的动作或产生异常错误）。主要有两种方式：

方法一：通过微服务框架的检测能力来实现。例如，在Spring Cloud微服务框架中，提供了执行器组件的/health端点。客户端需要实现一个自定义的HealthCheckHandler，它将应用程序的健康状态保存在内存中。只需要使用curl向服务器发送关闭命令即可。一旦状态发生变化，就会重新向服务器注册。方法二：通过注册JDK的ShutdownHook（钩子）来实现。当系统收到exit命令时，首先将自己从Zookeeper注册服务器上注销，并停止接收新消息。然后处理积压的请求，最后调用资源。回收接口销毁资源，最后各个线程退出执行。由于我们的生产环境没有采用开源的通用微服务架构，并且应用都是基于JAVA开发的，所以我们采用第二种方法：注册JDK的ShutdownHook（关机钩子）来实现优雅关闭。

shutdown hook本质上是一个线程（也称为Hook线程），用于监视JVM的关闭。关闭钩子可以通过Runtime 的addShutdownHook 注册到JVM。 Hook线程只有在JVM正常关闭时才会执行，强制关闭时不会执行。

JVM正常关闭的场景主要有以下几种：

Java程序正常运行退出时会被调用；当在终端中按ctrl-c 终止命令时将调用它；当JVM 由于OutOfMemory 退出时会调用它；当Java程序中执行System.exit()时会调用它；操作系统关闭时会调用；当Linux通过kill pid（或kill -15 pid）结束进程时会调用它。 JDK中ShutdownHook相关源码如下图2所示：

图2：添加和删除实现

ShutdownHook是如何调用的？使用java.lang.Runtime.addShutdownHook方法，可以注册一个JVM关闭钩子（线程），如下图3所示。我们希望程序在JVM退出时完成的各种完成任务，例如关闭资源、在服务路由器上注销注册信息、等待传输中的请求处理完成等都可以添加到这个线程中。

图3：注册JVM 关闭挂钩的示例

当然，优雅退出需要超时控制机制。如果达到超时时间，退出前的资源回收等操作仍未完成，则关闭脚本直接调用KILL -9 PID或调用强制关闭进程的代码强制退出。否则，可能会等待。长期以来，影响了我们正常的启停操作。

其它注意事项1、以下场景会直接停止JVM进程。 JVM没有机会执行关闭钩子线程时的清理工作，无法实现正常关闭：

Kill -9（SIGKILL 信号）；调用java.lang.runtime.halt() 方法；主机直接崩溃；主机直接关机；主机内存（或容器内存）不足，触发操作系统OOM-KILLER。 2、hook线程会延迟JVM的关闭时间，所以尽量减少执行时间，控制好超时。

效果代码优化后，通过测试环境验证和固定场景实际生产演练，容器销毁或正常重启时没有出现“无法连接到服务器”的错误，也解决了业务感知问题。解决了这个问题之后，在大规模微服务架构的场景下，容器的自动自愈、扩缩容等功能就可以再次使用了。

总结微服务的优雅关闭没有最优的解决方案。只要抓住核心思想并进行设计即可。如果你使用的框架中有这样的方案，建议直接使用，因为它的适应性肯定是最高的。在微服务架构中，我们可以遵循以下推荐规则来设计微服务的优雅关闭机制：

所有微服务应用都应该支持优雅关闭；优先注销注册中心注册的服务实例；被关闭的服务应用程序的接入点被标记为拒绝服务；上游服务支持因正常关闭而被拒绝的服务的故障转移；还根据具体业务提供适当的关机接口。

好了，本文到此结束，如果可以帮助到大家，还望关注本站哦！