发布稳定性-优雅下线

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

总结

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

相关文章
|
人工智能 搜索推荐 机器人
在Dify on DMS上搭建专属版Deep Research Agent
Deep Research Agent 不只是为了让你工作快一点那么简单。它更像一场知识工作的革命,彻底把我们从没完没了的“信息搬运”和“大海捞针”中解放出来。想想看,当那些繁琐的、重复性的搜集和整理工作都交给AI后,我们可以把宝贵的时间和脑力,真正用在刀刃上:去提出更一针见血的问题,去构思更有远见的战略,或者干脆去创造一个前所未有的新东西。本文将教你如何在Dify on DMS上,构建企业专属版Deep Research Agent。 
|
4月前
|
机器学习/深度学习 人工智能 算法
AI 基础知识从 0.6 到 0.7—— 彻底拆解深度神经网络训练的五大核心步骤
本文以一个经典的PyTorch手写数字识别代码示例为引子,深入剖析了简洁代码背后隐藏的深度神经网络(DNN)训练全过程。
840 56
|
存储 机器学习/深度学习 负载均衡
清华发布SmartMoE:一键实现高性能MoE稀疏大模型分布式训练
清华发布SmartMoE:一键实现高性能MoE稀疏大模型分布式训练
1589 0
|
3月前
|
安全 关系型数据库 MySQL
MySQL安全最佳实践:保护你的数据库
本文深入探讨了MySQL数据库的安全防护体系,涵盖认证安全、访问控制、网络安全、数据加密、审计监控、备份恢复、操作系统安全、应急响应等多个方面。通过具体配置示例,为企业提供了一套全面的安全实践方案,帮助强化数据库安全,防止数据泄露和未授权访问,保障企业数据资产安全。
|
3月前
|
人工智能 Kubernetes 安全
重塑云上 AI 应用“运行时”,函数计算进化之路
回顾历史,电网的修建,深刻地改变了世界的经济地理和创新格局。今天,一个 AI 原生的云端运行时的进化,其意义也远不止于技术本身。这是一次设计哲学的升华:从“让应用适应平台”到“让平台主动理解和适应智能应用”的转变。当一个强大、易用、经济且安全的 AI 运行时成为像水电一样的基础设施时,它将极大地降低创新的门槛。一个独立的开发者、一个小型创业团队,将有能力去创造和部署世界级的 AI 应用。这才是技术平权的真谛,是激发全社会创新潜能的关键。
|
12月前
|
人工智能 运维 监控
阿里云联合中国信通院等单位发布首个云计算智能化可观测性能力成熟度模型标准
推动行业智能化落地,阿里云联合中国信通院及国内头部云厂商、观测厂商、各行业建设方,历时近 5 个月,共同编制《云计算智能化可观测性能力成熟度模型》,以规范和指导云计算环境下的智能可观测性建设实践,为企业实施云环境下的智能化可观测能力建设提供指导。
479 90
|
存储 索引 Python
Python教程:深入了解 Python 中 Dict、List、Tuple、Set 的高级用法
Python 中的 Dict(字典)、List(列表)、Tuple(元组)和 Set(集合)是常用的数据结构,它们各自有着不同的特性和用途。在本文中,我们将深入了解这些数据结构的高级用法,并提供详细的说明和代码示例。
1019 2
|
人工智能 容器 运维
活动回顾丨AI 原生应用架构专场·北京站 PPT 下载
5 月 24 日,飞天技术沙龙首个 AI 原生应用架构专场在北京举办。
723 96
|
数据采集 存储 运维
物联网设备的数据处理与分析技术探讨
【7月更文挑战第2天】探索物联网(IoT)数据处理技术,涵盖数据采集(传感器、无线通信)、存储(分布式系统、NoSQL)、处理(清洗、压缩、转换)和分析(描述性、聚类、分类、异常检测)。未来趋势涉及AI集成、边缘计算、多模态处理和系统自主化。随着技术演进,期待更智能、高效的解决方案。
|
存储 缓存 安全
https跳过SSL认证时是不是就是不加密的,相当于http?
https跳过SSL认证时是不是就是不加密的,相当于http?
698 0

热门文章

最新文章