背景

• 开发过程中，在使用测试环境的时候发布验证的时候，我们往往希望快速迭代，快速验证，但是每次改完一个feature发布验证都要经过十几分钟的话，效率是非常低下的。

• 在线上发布过程中，如果遇到机器数量非常多的应用，那么一次发布，一批一批的部署下来，耗费的时间非常长，很容易超出发布窗口，带来线上风险。

构建部署耗时分析

idle-local项目耗时统计

注：

1. mtop是我们项目的api层

2. hsf是阿里的RPC框架

3. pandora是一个的轻量级的隔离容器，用来隔离Webapp和中间件的依赖

重点优化分析

1. 部署过程中，启动应用是最主要的耗时项，也是最容易随着应用迭代膨胀的部分，其中启动应用的主要耗时是bean的初始化。

2. 构建过程中，代码编译是主要的耗时项，理论上存在较大的优化空间。

3. 镜像中最后一层打包内容的大小会影响镜像push和pull的耗时，如果能够将变动范围分层优化，会有较大的收益。

4. 停止应用的过程中，为了处理RPC服务HSF优雅下线和应用优雅关闭，花了比较多的时间，在非生产环境可以省略

构建部署速度治理方案

应用启动加速-Spring Bean异步初始化的原理与落地

孤立的Bean

暂时孤立的Bean

1. 孤立的Bean一定是被spring通过遍历的方式创建的

2. 被spring通过遍历的方式创建的bean不一定是孤立的Bean，他可能被后来的bean依赖并注入

3. 被spring通过遍历的方式创建的bean有较大概率是孤立的Bean

4. 被spring通过遍历的方式创建的bean的初始化距离它被其他的Bean依赖并注入，有一些时间差

暂时不被使用的Bean

FactoryBean的处理

1. 如果这个Bean是一个单例并且没有被创建过，那么就会进入createBean，并且在其中完成初始化。

2. 如果这个Bean是一个FactoryBean，那么createBean返回的不是bean本身，而是一个factory，真正的bean要在之后的getInstance方法中获取。

编译加速-module依赖关系优化

1. mtop层在依赖service层的时候，排除service层的所有间接依赖，仅针对mtop层自身也需要依赖的内容进行手动引入。

2. start层依赖mtop和service，这里不能再做排除，因为项目是在start层进行打包的，如果排除，则会导致依赖包没有被正常打包到项目中而无法启动。

3. 按照这种方式优化，能够节省在mtop层解析service依赖树的开销，往往有几十秒之多。

1. mtop层是对service提供的服务进行mtop接口级别的封装，尽量仅依赖应用内service层和common定义的服务和对象，不处理复杂的中间件逻辑

2. 对于外部服务的使用和中间件定义的服务和对象的使用，尽量在service层封装，同时不宜将外部服务和中间件定义的对象直接透给mtop层，造成依赖扩散

3. 这约定之后，清晰mtop层与service层的边界，mtop层就是操作service层定义的方法和对象来完成接口，涉及外部定义的方法和对象的，收口到service。

镜像治理-分层构建

应用停止过程加速

效果及展望