【229秒 -> 69秒】部署时间缩短69%，ICBU商家技术部应用部署治理实践

公众号新闻

2024-05-15 00:05

阿里妹导读

部署时长不仅影响线上问题的解决恢复能力，也严重影响了我们日常的开发效率。本文记录了作者部署时的一些提效手段和最终的效果。

一、概述

1.1.背景

随着集团安全生产规范，需要达到1,5,10标准（1分钟响应，5分钟定位，10分钟解决），并且故障在5分钟内解决可以降一级。

团队应用部署时长平均接近3分钟，一些历史较久的老应用甚至会突破5分钟，部署时长不仅影响我们线上问题的解决恢复能力，也严重影响了我们日常的开发效率。

1.2.术语与缩写解释

1.3.构建部署流程耗时分布

应用拉上部署流程，会经历编译期和部署期两个大模块，其中还分若干个子步骤。部署耗时的时间统计，是从创建容器开始，到应用自检结束。

整个流程在代码编译、镜像构建、暂停老容器、启动应用等多个模块都可以进行优化，本篇着重对部署耗时进行深入分析，并以omega为样板间进行打造，提升应用的部署效率。

二、应用部署现状一览

这是omega应用1月份预发环境的部署启动时长，平均在229秒，预发环境防单点问题一般会部署2台机器，那omega应用平均每部署一次预发环境就需要7~8分钟，接下来我们来看看这229秒有哪些是可以进行优化的。

三、部署提效手段

3.1.应用启动日志分析

每个应用差异较大，这里以omega应用为例，提供一个分析的视角供参考。

这一步是最直接最有效的，应用越老，不合理内容往往越多。分析应用的启动日志，理解并解释每一行启动日志的背景和含义，看是否有效，是否必要，能否下线，能否优化。

3.1.1.下线liaoyuan中间件

traceId:2024-03-05 18:02:04,957 INFO  Loading XML bean definitions from class path resource [platform/liaoyuan.xml]

omega应用中引入了liaoyuan中间件，用于查询相关菜鸟地址信息，liaoyuan启动耗时是比较多的。经分析发现，omega引入liaoyuan本质上只用在了一个接口上，而这个接口也只有一个上游方，并且请求的QPS流量非常低，如果能将这个去掉，则可以下线整个liaoyuan模块。

经排查，neptunes调了omega的这个接口，但代码中并没有用到该接口的返回值，所以推进neptunes的调用下线，最终在2月27完成了对接口的停止调用，下线omega的liaoyuan模块。

3.1.2.没找到任何后缀名为“.ear”、“.spring”或“.war”的包

启动日志中发现有很多这样的日志，并且类路径带notify，但omega已经把notify全部下线完毕。

原因是项目中还存在NotifyManagerBean对象，并调到了它的init方法，就会检查notify的初始化检测，还有一些文件系统的恢复等。一种可以去除所有NotifyManagerBean对象的（前提是所有notify已下线），或者设置下 NotifyManagerBean#setPreInitializeReliableAsynSendManager(false) 这个可以确保不使用可靠异步发送 NotifyManagerBean#asynSendMessage。

3.1.3.doom初始化失败！

「doom启动失败，请检查启动参数是否正确配置」从启动日志看，前人在omega上可能接过doom模块，但因为各种原因没有完全接入。当下无doom相关使用需求，这里先移除doom相关模块。

3.1.4.No appenders could be found for logger

druid默认用得是log4j，但我们工程统一使用的是slf4j+logback，导致无相应log4j配置文件，而druid本身也支持切换日志组件，这里可以替换为slf4j。

在本地启动需要加上vm启动参数 -Ddruid.logType=slf4j

3.1.5.下线AutoConfig模块

AutoConfig是一个管理应用配置的组件，是webx时代的产物，如今已暂停维护，并且有多个替换产品。

omega已将autoconfig全部迁移至diamond管理，理论上已经不再需要antoconfig。但担心梳理有遗漏，这次暂不做改动，待详细梳理后再做确认。

3.2.应用启动诊断

由ICBU的交易平台团队(砺豪、如驰)和ICBU架构团队共同做了应用启动优化治理平台，可以支持应用启动数据采集插件、应用启动详细数据报表、自动诊断/自动推荐解决方案等，是一个针对应用部署启动优化的平台。借助这个平台。可以帮我们发现更多应用在启动过程中的优化点刑天平台 — 应用启动速度优化一站式解决方案。

3.2.1.aspectjrt 包版本过低导致启动耗时慢

org.springframework.aop.aspectj..AspectJExpressionPointcut方法名：matches总时长=6014ms
-- 作者：焉漪 aspectjrt包版本低

aspectjrt是AspectJ框架的一部分，是一个用于实现面向切面编程（AOP）的工具，在低版本存在启动耗时较高的问题aspectjrt 包版本过低导致启动耗时慢，这里我们按推荐升级到指定版本。

aspectjrt.jar包主要是提供运行时的一些注解，静态方法等内容。
aspectjweaverjar包主要是提供了一个java agent用于在类加载期间织入切面(Load time weaving)，并且提供了对切面语法的相关处理等基础方法，供ajc使用或者供第三方开发使用。

3.2.2.不存在的HsfConsumer

HSF不存在 com.ali...XXX....XXXInterface:1.0.0
-- 作者：焉漪 HSF不存在

HSFProvider下线了但其他应用中配置该HSFConsumer没下线，这种case在老应用的存在比较多，应用启动平台帮我们诊断出了不存在的HSF，为防止意外可以到HSFOPS上搜索一下，确认完后这里逐项进行去除，减少HSFConsumer的创建HSF 服务不存在的几种处理方式。

3.3.启动数据报表

除了显而易见能诊断出的问题，应用启动优化平台中还帮我们列出了整体的启动数据报表，可以有针对性的进行治理和优化。

3.3.1.RPC初始化注册失败

经验证，这些注册失败的，HSFprovider都已经下线，这里将这些已经不存在provider的consumer进行删除。

3.3.2.SpringBean初始化耗时详情

所有springbean的加载耗时都有记录，其中x.x.x.x.UserCacheService这个bean初始化时间很长，代码分析后发现这个bean并没有被工程所使用，这里将该bean的声明进行删除。

x.x.x.x.Mysql、x.x.x.x.Manager、x.x.x.x.CacheManager等，为mysql、TDDL、myBatis等相关bean，耗时较多，但不易优化。特别是针对tddl分库分表，库实例表实例较多，整体耗时也相应增加。

3.3.3.Spring Bean 异步化创建

async-bean-startup-starter是ICBU交易团队砺豪、如驰同学开发的一款Spring Bean异步化创建组件。若发现有部分bean创建耗时较长，并且该bean不在启动过程中需要，可以考虑配置为异步化。

实在不知道该如何优化，就看看能不能做成异步，可使用官方的异步化starter
-- 应用启动优化治理平台

这里不盲目使用异步化，首先考虑的是如何降低bean的创建耗时，以及该bean是否需要存在，若实在无法优化，并且以及该bean的使用场景不在启动过程中依赖，则可以尝试异步化组件。

3.3.4.CBU代码迁移

在B2B时代，omega是CBU和ICBU共用的应用。随着BU、BG的拆分，CBU团队完成了迁移不再依赖omega，但流量迁走了，代码一直还在。部分bean虽然不会使用，但一直在创建，同样也包括它直接间接依赖进来的二方库等。

3.4.启动脚本诊断

项目构建完后进入启动阶段，本质上是调用应用中配置在docker-config中的相关sh脚本文件进行启动，若脚本文件存在不合理配置，也会影响应用部署时长。

3.4.1.offline_hsf重复执行

SHELL脚本:start.sh 二级脚本:appctl.sh 三级脚本:null 方法名:offline_hsf 总时长=40s
-- 作者：焉漪 offline_hsf重复执行

可以看到执行应用暂停了调了offline_hsf执行了40s，在应用启动时又调了offline_hsf，又执行了40s，offline_hsf耗时较久且重复执行，治理参考应用启动Shell脚本观测官方文档（持续更新）。

Note:有的应用dockerfile在打镜像的时候，会把bin文件夹下的脚本文件全部打进去，这样改完脚本文件后，需要重新构建镜像，不然会不生效。校验办法是到机器上打开对应对应，看改动是否生效。

瞬间应用启动有质的上升！！

四、最终效果

4.1.部署提速69%

废话不多说，咱们直接上结果。omega的部署启动时长，优化前在229秒，优化后在69.71秒，加速提效69%。

微信扫码关注该文公众号作者

戳这里提交新闻线索和高质量文章给我们。

来源: qq

点击查看作者最近其他文章