关于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：

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

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

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