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

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

文章图片

然后阻塞数量很快就下去了，通过 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：