背景
最近负责的项目已经到达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有提供无损上下线的功能，当然可能是收费的啊，但是接入简单，适用于大型系统
总结
这篇文章介绍了无损下线，主要目的是防止应用发布部署过程中产生脏数据问题，下篇文章讲无损上线
