部署时长不仅影响线上问题的解决恢复能力，也严重影响了我们日常的开发效率。本文记录了作者部署时的一些提效手段和最终的效果。
随着集团安全生产规范，需要达到1,5,10标准（1分钟响应，5分钟定位，10分钟解决），并且故障在5分钟内解决可以降一级。
团队应用部署时长平均接近3分钟，一些历史较久的老应用甚至会突破5分钟，部署时长不仅影响我们线上问题的解决恢复能力，也严重影响了我们日常的开发效率。
应用拉上部署流程，会经历编译期和部署期两个大模块，其中还分若干个子步骤。部署耗时的时间统计，是从创建容器开始，到应用自检结束。
整个流程在代码编译、镜像构建、暂停老容器、启动应用等多个模块都可以进行优化，本篇着重对部署耗时进行深入分析，并以omega为样板间进行打造，提升应用的部署效率。
这是omega应用1月份预发环境的部署启动时长，
平均在229秒
，预发环境防单点问题一般会部署2台机器，那omega应用平均每部署一次预发环境就需要7~8分钟，接下来我们来看看这229秒有哪些是可以进行优化的。
每个应用差异较大，这里以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。但担心梳理有遗漏，这次暂不做改动，待详细梳理后再做确认。
由ICBU的交易平台团队(砺豪、如驰)和ICBU架构团队共同做了
应用启动优化治理平台
，可以支持应用启动数据采集插件、应用启动详细数据报表、自动诊断/自动推荐解决方案等，是一个针对应用部署启动优化的平台。借助这个平台。可以帮我们发现更多应用在启动过程中的优化点
刑天平台 — 应用启动速度优化一站式解决方案
。
3.2.1.aspectjrt 包版本过低导致启动耗时慢
org.springframework.aop.aspectj..AspectJExpressionPointcut方法名：matches总时长=6014ms
aspectjrt是AspectJ框架的一部分，是一个用于实现面向切面编程（AOP）的工具，在低版本存在启动耗时较高的问题
aspectjrt 包版本过低导致启动耗时慢
，这里我们按推荐升级到指定版本。
3.2.2.不存在的HsfConsumer
HSF不存在 com.ali...XXX....XXXInterface:1.0.0
HSFProvider下线了但其他应用中配置该HSFConsumer没下线，这种case在老应用的存在比较多，应用启动平台帮我们诊断出了不存在的HSF，为防止意外可以到HSFOPS上搜索一下，确认完后这里逐项进行去除，减少HSFConsumer的创建
HSF 服务不存在的几种处理方式
。
除了显而易见能诊断出的问题，应用启动优化平台中还帮我们列出了整体的启动数据报表，可以有针对性的进行治理和优化。
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分库分表，库实例表实例较多，整体耗时也相应增加。
