发布稳定性-优雅下线

简介: 最近负责的项目已经到达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

总结

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

相关文章
|
6月前
|
弹性计算 负载均衡 网络协议
这种情况可能是由于阿里云的API服务出现了短暂的故障或者网络波动导致的
【2月更文挑战第20天】这种情况可能是由于阿里云的API服务出现了短暂的故障或者网络波动导致的
135 1
|
Ubuntu 安全 应用服务中间件
使用流量转移完成金丝雀部署
使用流量转移完成金丝雀部署
108 0
|
SQL 监控 网络协议
线上故障如何快速排查?来看这套技巧大全
有哪些常见的线上故障?如何快速定位问题?本文详细总结工作中的经验,从服务器、Java应用、数据库、Redis、网络和业务六个层面分享线上故障排查的思路和技巧。较长,同学们可收藏后再看。
线上故障如何快速排查?来看这套技巧大全
|
3月前
|
存储 缓存 监控
分布式链路监控系统问题之kywalking在后期维护过程中可能会遇到中间件版本升级的问题如何解决
分布式链路监控系统问题之kywalking在后期维护过程中可能会遇到中间件版本升级的问题如何解决
|
4月前
|
分布式计算 监控 测试技术
建设云上稳定性问题之通过SLB转发和健康检查策略后,系统发布过程中的可用性有何改善
建设云上稳定性问题之通过SLB转发和健康检查策略后,系统发布过程中的可用性有何改善
|
6月前
|
消息中间件 监控 Kafka
蓝绿部署中,如何确保数据一致性?
在蓝绿部署中,确保数据一致性是一个关键问题。以下是一些建议来确保数据一致性: 1. 数据库复制:在蓝绿部署的两个环境中,确保数据库是同步的。这可以通过设置数据库复制或使用数据库集群来实现。这样,在部署过程中,两个环境的数据将保持一致。 2. 数据同步工具:使用数据同步工具(如Apache Kafka、RabbitMQ等)在蓝绿部署的两个环境之间实时同步数据。这样可以确保在部署过程中,两个环境的数据保持一致。 3. 分布式事务:在分布式系统中,使用分布式事务来确保数据一致性。例如,可以使用两阶段提交(2PC)协议或者三阶段提交(3PC)协议来实现分布式事务。 4. 服务幂等性:确保服务具
437 4
|
Dubbo Java 应用服务中间件
发布稳定性-优雅上线
之前的文章讲了优雅下线,今天讲优雅上线
148 0
发布稳定性-优雅上线
|
存储 缓存 监控
线上服务发布抖动,该怎么解决呢
之前的文章分别讲了[优雅上线]和 [优雅下线],实际工作中做了优雅上下线后,服务发布后还是会有短暂的“抖动”,接口的响应时间急剧升高后又恢复正常,就和下面的监控图一样
156 0
线上服务发布抖动,该怎么解决呢
|
消息中间件 存储 运维
线上环境大规模RocketMQ集群不停机优雅升级实践
线上环境大规模RocketMQ集群不停机优雅升级实践
线上环境大规模RocketMQ集群不停机优雅升级实践
|
缓存 JSON 运维
如何避免大规模线上故障
如何避免大规模线上故障
170 0