kl个人博客 首页>>Spring>>spring boot应用优化,6s内启动,内存减半

spring boot应用优化,6s内启动,内存减半

spring boot应用优化,6s内启动,内存减半

前言

taptap-developer是一个spring boot框架驱动的纯Grpc服务,所以,只用了四步,移除了web和spring cloud相关的模块后,启动速度就稳稳的保持在了6s内。除了启动速度提升外,在服务待机状态下,内存锐减了50%左右,从500M左右的内存占用,缩减到了250M不到。

分析日志


日志是一个应用的门面,在未深入了解一个应用的架构前,通过启动的日志输出基本可以分析出这个应用的大概的技术构成。在分析日志之前,在强调一点,这个应用是一个纯Grpc的服务。如上图贴出的日志,是未优化前的系统日志输出,从上到下有四个红色箭头指向,是本次日志分析的关键信息,下面就这四个关键信息,分别分析下。然后总结出常见的优化方法

优化点一:关于Spring Data repository scanning

Spring Data repository是一个高度抽象的数据访问层接口,常见的实现有redis、jdbc、jpa、MongoDB、elasticsearch等等。实现一个Spring-data-xxx包,需要实现org.springframework.data.repository.core.support.RepositoryFactorySupport抽象类,然后在!/META-INF/spring.factories文件中定义好实现类。spring容器启动时,会扫描加载factories的信息。如果一个项目里有被扫描到有多个spring-data-xxx的实现,启动时日志就会打印Multiple Spring Data modules found, entering strict repository configuration mode!

优化:看到这个日志,我们就需要检查下项目中是否用到了这些功能,比如引入了spring-data-redis,其实只用到了其携带的jedis,而且jedis实例可能还是自己实例化的,这个时候就可以禁用repository的功能。参考配置如下:spring.data.redis.repositories.enabled=false

Spring Data repository有三种内置的初始化模式,分别对应如下:

  • DEFAULT:和Spring其他Bean一样,在容器上下文加载时就初始化
  • DEFERRED:惰性加载,容器上下文启动完成后开始初始化
  • LAZY:惰性加载,并且延迟注入,容器上下文启动完成接收第一个请求时开始初始化
    如日志输出:Bootstrapping Spring Data repositories in DEFAULT mode,默认是随容器启动就开始初始化的,

优化:这里可以根据业务特点,选择延迟加载,参考配置spring.data.jpa.repositories.bootstrap-mode=lazy

Spring Data repository会扫描项目中的实现了repository接口的类,默认情况下会盲扫所有的jar包,日志输出:Finished Spring Data repository scanning in 148ms. Found 0 repository interfaces.打印出了扫描repository接口的耗时情况。

优化:这里可以通过@EnableRedisRepositories(basePackages = "com.taptap")指定扫描的路径,可以显著提升扫描加载的速度

优化点二:关于WebApplicationContext

在spring中,WebApplicationContext是ApplicationContext的增强,由spring-web-mvc实现,增加了servlet、session等web相关的内容。从日志Initializing Spring embedded WebApplicationContext可以看出,我们初始化了一个web容器,而纯Grpc服务用不到Web的容器上下文,所以移除如下依赖即可

优化:移除implementation('org.springframework.boot:spring-boot-starter-web')

优化点三:关于servlet容器

spring-web-mvc是基于java web标准servlet设计架构的。而servlet是由servlet容器来驱动的,常见的servlet有tocmat、jetty、undertow等。从日志中可看出,我们启动了一个8081的servlet容器。这个不应该出现在纯Grpc的服务中,所以,直接移除即可。

优化:移除implementation 'org.springframework.boot:spring-boot-starter-undertow'

优化点四:关于archaius配置组件

从最后一个箭头指向的日志信息可以分析出,项目引入了archaius配置加载组件,所以项目在启动时,archaius会尝试去加载默认策略的配置源。而我们整体的技术栈,配置中心统一采用了apollo,所以可以直接移除,最后通过分析定位,archaius不是单独引入的,是随着spring-cloud-starter-netflix-hystrix一同引入,这个组件是spring-cloud-netflix微服务框架最常用的,但是在这边,目前所有的微服务都是直接注册到k8s容器的,所有服务的熔断、限流、负载均衡都下沉到了容器基数设施平台,所以应用层面虽然引入了这个包,其实没有实际作用,所以最后移除spring cloud相关组件

优化:移除implementation 'org.springframework.cloud:spring-cloud-starter-openfeign'和 implementation 'org.springframework.cloud:spring-cloud-starter-netflix-hystrix'组件、

附优化后的日志输出:

系统资源的变化

优化前的

优化后的

最后,基于资源监控图,从三个维度总结下,优化后的资源占用情况:

资源名称 优化前 优化后
内存 500M左右 250M左右
总线程数 107 78
装载类 12922 10041
kl个人博客