IT团队需要更好地了解云部署的4个方面

其主要调用逻辑为：

• 生成容器，服务在容器内启动;
• 注册到服务路由器(Zookeeper);
• 服务调用者订阅服务路由器;
• 服务路由器上发生注册变动，通知服务调用者重新获取新的注册列表;
• 服务调用者根据获取到的服务端列表，进行服务调用。

但是当服务端实例停止后，由于服务端不会主动去更改服务路由器上的注册信息，客户端需要40秒(目前应用到Zookeeper的会话超时时间配置)才能剔除这个异常配置，在这40秒内应用还是会不断的尝试访问这个不存在的实例，导致产生大量业务报错。

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

所以这是一个由于服务实例暴力停止，并被微服务架构下单笔业务请求多次访问的倍数放大后，产生的问题。

解决方案

既然这是由于服务实例暴力停机导致的问题，所以我们开始研究基于微服务的优雅停机方式。

微服务架构中的应用优雅停机，主要是指应用实例有计划而平滑(即不产生需要处理的动作或不产生异常报错)的退出方式。主要有两种方式：

• 方式一：通过微服务框架自带的检测能力来实现，如在Spring Cloud微服务框架中，提供了actuator组件的/health端点来实现。客户端需要实现一个自定义的HealthCheckHandler，它将应用的健康状态保存到内存中，只需在服务器上利用curl发送shutdown命令，状态一旦发生改变，就会重新向服务器进行注册。
• 方式二：通过注册JDK的ShutdownHook(钩子)来实现，当系统接收到退出指令后，首先把自己从Zookeeper注册服务器上下线，不再接收新的消息，然后将积压的请求处理完，最后调用资源回收接口将资源销毁，最后各线程退出执行。

由于我们生产环境未采用开源通用型微服务架构，且应用都是基于JAVA开发，因此我们采用的是方式二：通过注册JDK的ShutdownHook(关闭钩子)来实现优雅停机方式。

关闭钩子本质是一个线程(也称为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所示：

（编辑：南昌站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!