发布稳定性-优雅下线

简介: 最近负责的项目已经到达10万 QPS的大关了,这么高的QPS,对系统的稳定性要求也更高了。之前QPS小的时候,系统更新部署很简单,现在不行了,一部署起来,上游应用方就找过来了,说你这应用咋回事,怎么突然抖动厉害了。。。

背景

最近负责的项目已经到达10万 QPS的大关了,这么高的QPS,对系统的稳定性要求也更高了。之前QPS小的时候,系统更新部署很简单,现在不行了,一部署起来,上游应用方就找过来了,说你这应用咋回事,怎么突然抖动厉害了。。。

所以准备写一下关于发布稳定性的经验文章,今天先来说说优雅下线。

为什么需要优雅下线

对于线上应用,特别是高并发的应用来说,在服务更新部署发布过程中保证客户端无感知是开发者必须要解决的问题,即从应用停止到重启恢复服务这个阶段不能影响正常的业务请求。

传统的解决方式是手工摘流量、停止应用、更新重启服务三个步骤,但是人工操作太繁琐且不适用大规模系统。

所以服务需要自动化机制,自动摘流量并确保处理完已经到达的请求,这也就是优雅下线。

适用场景

  • JVM主动关闭(System.exit(int)
  • 应用程序接受SIGTERMSIGINT信号退出

Dubbo服务优雅下线

Dubbo服务的优雅下线是默认开启的,停机等待时间10秒

# Dubbo优雅下线等待时间,默认10秒,这里配置20秒
dubbo.service.shutdown.wait=20000

服务端和客户端下线步骤如图所示:

1.png

实现原理

翻一翻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)方法,查看执行过程,打印日志如下,从日志看,优雅下线是生效的。

2.png

企业级优雅下线

上面那种下线方式还是有一定问题的,开源Dubbo可以通过shutdownHook和QoS实现优雅下线,但是有一定的开发工作量,而且对Dubbo有版本要求,还有一些遗留问题,最终影响正常使用。

阿里云MSE有提供无损上下线的功能,当然可能是收费的啊,但是接入简单,适用于大型系统

MSE配置无损下线

3.png

总结

这篇文章介绍了无损下线,主要目的是防止应用发布部署过程中产生脏数据问题,下篇文章讲无损上线

相关文章
|
7月前
|
存储 Kubernetes API
K8S上生产环境后,90%都会遇到这个故障
K8S上生产环境后,90%都会遇到这个故障
362 0
|
7月前
|
消息中间件 监控 Kafka
蓝绿部署中,如何确保数据一致性?
在蓝绿部署中,确保数据一致性是一个关键问题。以下是一些建议来确保数据一致性: 1. 数据库复制:在蓝绿部署的两个环境中,确保数据库是同步的。这可以通过设置数据库复制或使用数据库集群来实现。这样,在部署过程中,两个环境的数据将保持一致。 2. 数据同步工具:使用数据同步工具(如Apache Kafka、RabbitMQ等)在蓝绿部署的两个环境之间实时同步数据。这样可以确保在部署过程中,两个环境的数据保持一致。 3. 分布式事务:在分布式系统中,使用分布式事务来确保数据一致性。例如,可以使用两阶段提交(2PC)协议或者三阶段提交(3PC)协议来实现分布式事务。 4. 服务幂等性:确保服务具
516 4
|
7月前
上线需求范围不明确该怎么办?
上线需求范围不明确该怎么办?
|
7月前
|
运维 DataWorks 调度
DataWorks运维中心提供了下线节点、优雅下线和下线任务三种下线方式
DataWorks运维中心提供了下线节点、优雅下线和下线任务三种下线方式
214 2
|
Dubbo Java 应用服务中间件
发布稳定性-优雅上线
之前的文章讲了优雅下线,今天讲优雅上线
156 0
发布稳定性-优雅上线
|
消息中间件 存储 运维
线上环境大规模RocketMQ集群不停机优雅升级实践
线上环境大规模RocketMQ集群不停机优雅升级实践
线上环境大规模RocketMQ集群不停机优雅升级实践
|
开发框架 运维 Kubernetes
应用发布新版本如何保障业务流量无损(二)| 学习笔记
快速学习应用发布新版本如何保障业务流量无损
应用发布新版本如何保障业务流量无损(二)| 学习笔记
|
缓存 Kubernetes 容灾
应用发布新版本如何保障业务流量无损(一)| 学习笔记
快速学习应用发布新版本如何保障业务流量无损
应用发布新版本如何保障业务流量无损(一)| 学习笔记
|
Kubernetes Cloud Native Dubbo
应用发布新版本如何保障流量无损
业务的发展需要应用系统不断的迭代,我们无法避免应用频繁变更发版,但是我们可以提升应用升级过程中的稳定性和高可用。
应用发布新版本如何保障流量无损
下一篇
DataWorks