背景
最近负责的我的项目曾经达到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配置无损下线
总结
这篇文章介绍了无损下线，次要目标是避免利用公布部署过程中产生脏数据问题，下篇文章讲无损上线