在阿里集团的大部分应用都是依赖了各种中间件的Java应用，通过对核心中间件的集中优化，提升了各Java应用的整体启动时间，提速8%。
1. Dubbo3启动优化
1) 现状
Dubbo3作为阿里巴巴使用最为广泛的分布式服务框架，服务集团内数万个应用，它的重要性自然不言而喻；但是随着业务的发展，应用依赖的Jar包和HSF服务也变得越来越多，导致应用启动速度变得越来越慢，接下来我们将看一下Dubbo3如何优化启动速度。
2) Dubbo3为什么会慢
Dubbo3作为一个优秀的RPC服务框架，当然能够让用户能够进行灵活扩展，因此Dubbo3框架提供各种各样的扩展点一共200+个。
Dubbo3的扩展点机制有点类似Java标准的SPI机制，但是Dubbo3设置了3个不同的加载路径，具体的加载路径如下：
META-INF/dubbo/internal/ META-INF/dubbo/ META-INF/services/
也就是说，一个SPI的加载，一个classLoader就需要扫描这个classLoader下所有的Jar包3次。
以热点应用A为例，总的业务bundle classLoader数达到582个左右，那么所有的SPI加载需要的次数为：200（spi）*3（路径）*582（classloader）=349200次。
可以看到扫描次数接近35万次!并且整个过程是串行扫描的，而我们知道java.lang.ClassLoader#getResources是一个比较耗时的操作，因此整个SPI加载过程耗时是非常久的。
3) SPI加载慢的解决方法
由我们前面的分析可以知道，要想减少耗时，第一是需要减少SPI扫描的次数，第二是提升并发度，减少无效等待时间。
第一个减少SPI扫描的次数，我们经过分析得知，在整个集团的业务应用中，使用到的SPI集中在不到10个SPI，因此我们疏理出一个SPI列表，在这个SPI列表中，默认只从Dubbo3框架所在classLoader的限定目录加载，这样大大下降了扫描次数，使热点应用A总扫描计数下降到不到2万次，占原来的次数5%这样。
第二个提升了对多个classLoader扫描的效率，采用并发线程池的方式来减少等待的时间，具体代码如下：
CountDownLatch countDownLatch = new CountDownLatch(classLoaders.size()); for (ClassLoader classLoader : classLoaders) { GlobalResourcesRepository.getGlobalExecutorService().submit(() -> { resources.put(classLoader, loadResources(fileName, classLoader)); countDownLatch.countDown(); }); }
4) 其他优化手段
• 去除启动关键链路的非必要同步耗时动作，转成异步后台处理。
• 缓存启动过程中查询第三方可缓存的结果，反复重复使用。
5) 优化结果
热点应用A启动时间从603秒下降到220秒，总体时间下降了383秒。
2. TairClient启动优化
背景介绍：
• tair：阿里巴巴内部的缓存服务，类似于公有云的redis。
• diamond：阿里巴巴内部配置中心，目前已经升级成MSE，和公有云一样的中间件产品。
1) 现状
目前中台基础服务使用的tair集群均使用独立集群，独立集群中使用多个NS（命名空间）来区分不同的业务域，同时部分小的业务也会和其他业务共享一个公共集群内单个NS。
早期tair的集群是通过configID进行初始化，后来为了容灾及设计上的考虑，调整为使用username进行初始化访问，但username内部还是会使用configid来确定需要链接的集群。整个tair初始化过程中读取的diamond配置的流程如下：
a) 根据userName获取配置信息，从配置信息中可以获得TairConfigId信息，用于标识所在集群。
• Dataid：ocs.userinfo.{username}
• Group：DEFAULT_GROUP
b) 根据ConfigId信息，获取当前tair的路由规则，规定某一个机房会访问的集群信息。
• dataId：{tairConfigId}
• group：{tairConfigId}.TGROUP
通过该配置可以确定当前机房会访问的目标集群配置，以na610为例，对应的配置集群tair.mdb.mc.uic.NA61。
c) 获取对应集群的信息，确定tair集群的cs列表。
• Dataid：{tairConfigId} // tair.mdb.mc.uic
• Group：{tairClusterConfig} // tair.mdb.mc.uic.NA61
从上面的分析来看，在每次初始化的过程中，都会访问相同的diamond配置，在初始化多个同集群的namespace的时候，部分关键配置就会多次访问。但实际这部分diamond配置的数据本身是完全一致。
由于diamond本身为了保护自身的稳定性，在客户端对访问单个配置的频率做了控制，超过一定的频率会进入等待超时阶段，这一部分导致了应用的启动延迟。
• 在一分钟的时间窗口内，限制单个diamond配置的访问次数低于-DlimitTime配置，默认配置为5，对于超过限制的配置会进入等待状态。
2) 优化方案
tair客户端进行改造，启动过程中，对Diamond的配置数据做缓存，配置监听器维护缓存的数据一致性，tair客户端启动时，优先从缓存中获取配置，当缓存获取不到时，再重新配置Diamond配置监听及获取Diamond配置信息。
3. SwitchCenter启动优化
背景介绍：
SwitchCenter：阿里巴巴集团内部的开关平台，对应阿里云AHAS云产品：https://help.aliyun.com/document_detail/155939.html
1) 现状
All methods add synchronized made this class to be thread safe. switch op is not frequent, so don't care about performance here.
这是switch源码里存放各个switch bean的SwitchContainer中的注释，可见当时的作者认为switch bean只需初始化一次，本身对性能的影响不大。但没有预料到随着业务的增长，switch bean的初始化可能会成为应用启动的瓶颈。
业务平台的定位导致了平台启动期间有大量业务容器初始化，由于switch中间件的大部分方法全部被synchronized修饰，因此所有应用容器初始化到了加载开关配置时（入口为com.taobao.csp.switchcenter.core.SwitchManager#init()）就需要串行执行，严重影响启动速度。
2) 解决方案
去除了关键路径上的所有锁。
3) 原理
本次升级将存放配置的核心数据结构修改为了ConcurrentMap，并基于putIfAbsent等j.u.c API做了小重构。值得关注的是修改后原先串行的对diamond配置的获取变成了并行，触发了diamond服务端限流，在大量获取相同开关配置的情况下有很大概率抛异常启动失败。
（如上：去锁后，配置获取的总次数不变，但是请求速率变快）
为了避免上述问题：
• 在本地缓存switch配置的获取。
• diamond监听switch配置的变更，确保即使switch配置被更新，本地的缓存依然是最新的。
4. TDDL启动优化
背景介绍：
TDDL：基于Java语言的分布式数据库系统，核心能力包括：分库分表、透明读写分离、数据存储平滑扩容、成熟的管控系统。
1) 现状
TDDL在启动过程，随着分库分表规则的增加，启动耗时呈线性上涨趋势，在国际化多站点的场景下，耗时增长会特别明显，未优化前，我们一个核心应用TDDL启动耗时为120秒+（6个库），单个库启动耗时20秒+，且通过多个库并行启动，无法有效降低耗时。
2) 解决方案
通过工具分析，发现将分库分表规则转成groovy脚本，并生成groovy的class，这块逻辑总耗时非常久，调用次数非常多，且groovy在parseClass里头有加锁（所以并行无效果）。调用次数多，是因为生成class的个数，会剩以物理表的数量，比如配置里只有一个逻辑表+一个规则（不同表的规则也存在大量重复），分成1024张物理表，实际启动时会产生1024个规则类，存在大量的重复，不仅启动慢，还浪费了很多metaspace。
优化方案是新增一个全局的GuavaCache，将规则和生成的规则类实例存放进去，避免相同的规则去创建不同的类和实例。
