共计 1653 个字符，预计需要花费 5 分钟才能阅读完成。
背景
最近负责的我的项目曾经达到 10 万 QPS 的大关了，这么高的 QPS，对系统的稳定性要求也更高了。之前 QPS 小的时候，零碎更新部署很简略，当初不行了，一部署起来，上游利用方就找过去了，说你这利用咋回事，怎么忽然抖动厉害了。。。
所以筹备写一下对于公布稳定性的教训文章，明天先来说说优雅下线。
为什么须要优雅下线
对于线上利用，特地是高并发的利用来说，在服务更新部署公布过程中保障客户端无感知是开发者必须要解决的问题，即从利用进行到重启复原服务这个阶段不能影响失常的业务申请。
传统的解决形式是手工摘流量、进行利用、更新重启服务三个步骤，然而人工操作太繁琐且不实用大规模零碎。
所以服务须要自动化机制，主动摘流量并确保解决完曾经达到的申请，这也就是优雅下线。
实用场景
- JVM 被动敞开（
System.exit(int)） - 应用程序承受
SIGTERM或SIGINT信号退出
Dubbo 服务优雅下线
Dubbo 服务的优雅下线是默认开启的，停机等待时间 10 秒
# Dubbo 优雅下线等待时间，默认 10 秒，这里配置 20 秒
dubbo.service.shutdown.wait=20000服务端和客户端下线步骤如图所示：
实现原理
翻一翻 Dubbo 的源码查问下线过程
1. 在服务启动加载类 org.apache.dubbo.config.AbstractConfig 时，就会调用 DubboShutdownHook.getDubboShutdownHook().register() 将 ShutdownHook 钩子注册下来
/**
* Register the ShutdownHook
*/
public void register() {if (!registered.get() && registered.compareAndSet(false, true)) {Runtime.getRuntime().addShutdownHook(getDubboShutdownHook());
}
}2. 每个 ShutdownHook 都是一个独自线程，承受到敞开利用 kill 信号量时，触发执行 DubboShutdownHook 中的 run 办法，接着执行 doDestroy 办法销毁所有注册服务和协定。
@Override
public void run() {if (logger.isInfoEnabled()) {logger.info("Run shutdown hook now.");
}
doDestroy();}
/**
* Destroy all the resources, including registries and protocols.
*/
public void doDestroy() {if (!destroyed.compareAndSet(false, true)) {return;}
// destroy all the registries
AbstractRegistryFactory.destroyAll();
// destroy all the protocols
destroyProtocols();}这一步过程：
- 从注册核心销毁所有已公布服务，勾销订阅，断开与注册核心的连贯
- 执行 Protocol 的 destroy()办法，销毁所有 Invoker 和 Exporter，敞开 Server
- 敞开 JVM
理论测试
理论测试 Dubbo 的优雅下线性能，如下面的图，设置 Nacos 注册核心、Dubbo 服务方和生产方，生产方始终调用一个接口，服务方执行 System.exit(-1) 办法，查看执行过程，打印日志如下，从日志看，优雅下线是失效的。
企业级优雅下线
下面那种下线形式还是有肯定问题的，开源 Dubbo 能够通过 shutdownHook 和 QoS 实现优雅下线，然而有肯定的开发工作量，而且对 Dubbo 有版本要求，还有一些遗留问题，最终影响失常应用。
阿里云 MSE 有提供无损高低线的性能，当然可能是免费的啊，然而接入简略，实用于大型零碎
MSE 配置无损下线
总结
这篇文章介绍了无损下线，次要目标是避免利用公布部署过程中产生脏数据问题，下篇文章讲无损上线
