实现微服务预热调用之后再开始服务(上)

最近线上发现一个现象,应用实例刚刚启动的时候,开始接收请求之后发生了一小段时间的请求阻塞,从 HTTP Servlet 请求队列监控上可以看出(基于 spring-web 的普通阻塞的 HTTP 服务器是有 HTTP 线程池的,当线程是满了之后,请求在阻塞队列中等待处理。基于 spring-webflux 的没有这个现象,但是考虑的背压问题其实和这个场景类似):
image

然后阻塞数量很快就下去了,通过 JFR 发现和 Spring 各种懒加载的 Bean,各种资源或者连接池初始化等有关。这些资源可以理解为是懒加载的,是在请求真正用到的时候才会初始化。这些资源初始化之前,微服务就已经注册到注册中心并开始接受请求了。这样在平常业务低峰发布的时候,是没有问题的,因为这些资源的初始化耗时也就在几十到几百毫秒之间。但是在业务高峰需要动态扩容的时候,就会受一些影响,因为请求压力会立刻大量打到这些新启动的实例上,这种情况下,初始化耗时的影响就比较大了

所以,我们希望在微服务开始真正提供服务之前,将这些比较耗时的需要初始化的资源提前初始化完成之后,再告诉注册中心我们可以开始接受处理请求了。

Spring Boot 中的 MVC Servlet 与 Web Service Servlet 的提前初始化

在微服务实例启动后,我们发送第一个请求的时候,会看到类似于下面的日志:

INFO: Initializing Servlet 'dispatcherServlet'
INFO: Initializing Spring DispatcherServlet 'dispatcherServlet'

这是在初始化 Servlet。

MVC Servlet 指的就是 Spring-MVC 的 Servlet,其实就是提供 HTTP 服务的一些核心 Servlet,例如最核心的 org.springframework.web.servlet.DispatcherServlet。这些默认是懒加载的,需要通过下面的配置打开:

spring.mvc.servlet.load-on-startup: 1

除了 MVC Servlet,另一些 Servlet 可能是提供除了 HTTP 以外的其他应用协议的 Servlet,这些 Servlet 默认也是懒加载的,需要通过下面的配置打开:

spring.webservices.servlet.load-on-startup: 1

例如 WebSocket 的 org.springframework.ws.transport.http.MessageDispatcherServlet 就是通过这个配置进行初始化的。

spring-data-redis 连接池的初始化

我们项目中使用的是 spring-data-redis + lettuce。如果没有使用 Pipeline 等需要独占连接的 redis 操作,其实不用使用连接池。但是我们在使用中为了效率,尽量都是用 Pipeline,所以我们都启用了连接池配置。其连接池实现基于 common-pools2 库。相关配置如下所示:

  • spring.redis.lettuce.pool.enabled: 是否启用连接池,如果依赖中有 common-pools2 依赖自动会启用。一般这个配置是用来关闭连接池的。
  • spring.redis.lettuce.pool.max-active: 连接池最大连接数量,默认是 8
  • spring.redis.lettuce.pool.max-idle:连接池中最多保留的空闲连接数量,默认是 8,这个配置需要和 spring.redis.lettuce.pool.time-between-eviction-runs 一起配置才可以生效。
  • spring.redis.lettuce.pool.max-wait:从连接池获取连接最大的等待时间(毫秒),超过这个等待时间则会抛出异常,默认是 -1,即不超时
  • spring.redis.lettuce.pool.min-idle:连接池中最小的空闲连接数量,默认是 0,这个配置需要和 spring.redis.lettuce.pool.time-between-eviction-runs 一起配置才可以生效。
  • spring.redis.lettuce.pool.time-between-eviction-runs:common-pools 中 Evictor 初始执行延迟以及执行间隔。不配置的话,就没有启用 Evictor 任务。

这个配置经常有人会误用,只配置了 spring.redis.lettuce.pool.min-idle 但是没有配置 spring.redis.lettuce.pool.time-between-eviction-runs,导致 Evictor 任务没有启动,导致并没有初始化最小连接数量的连接。

Evictor 任务包括将池中空闲的超过 spring.redis.lettuce.pool.max-idle 配置数量的对象,进行过期,以及空闲对象不足 spring.redis.lettuce.pool.min-idle 时,创建对象补足:

 public void run() {
    final ClassLoader savedClassLoader =
            Thread.currentThread().getContextClassLoader();
    try {
        if (factoryClassLoader != null) {
            // Set the class loader for the factory
            final ClassLoader cl = factoryClassLoader.get();
            if (cl == null) {
                // The pool has been dereferenced and the class loader
                // GC'd. Cancel this timer so the pool can be GC'd as
                // well.
                cancel();
                return;
            }
            Thread.currentThread().setContextClassLoader(cl);
        }

        // Evict from the pool
        try {
            evict();
        } catch(final Exception e) {
            swallowException(e);
        } catch(final OutOfMemoryError oome) {
            // Log problem but give evictor thread a chance to continue
            // in case error is recoverable
            oome.printStackTrace(System.err);
        }
        // Re-create idle instances.
        try {
            ensureMinIdle();
        } catch (final Exception e) {
            swallowException(e);
        }
    } finally {
        // Restore the previous CCL
        Thread.currentThread().setContextClassLoader(savedClassLoader);
    }
}

对于这种连接池,最好初始化足够的连接数量,即配置 spring.redis.lettuce.pool.min-idle 以及 spring.redis.lettuce.pool.time-between-eviction-runs。由于我们的项目中大量使用了 Pipeline,线程会独占一个连接进行操作。所以初始化的连接数量最好等于线程池的数量,在我们项目中即 Http Servlet 线程池的数量。

数据库连接池的初始化

这里以 druid 连接池为例子,druid 连接池底层其实也是类似于 common-pools 的实现,但是配置设计的更全面复杂一些。可以直接配置 initialSize:

DruidDataSource dataSource = new DruidDataSource();
dataSource.setInitialSize(50);
dataSource.setMaxActive(50);

我们设置初始连接池大小就是最大连接数

微信搜索“我的编程喵”关注公众号,每日一刷,轻松提升技术,斩获各种offer

posted @ 2022-01-01 08:36  干货满满张哈希  阅读(107)  评论(0编辑  收藏  举报