实现微服务预热调用之后再开始服务(上)
Posted 干货满满张哈希
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了实现微服务预热调用之后再开始服务(上)相关的知识,希望对你有一定的参考价值。
最近线上发现一个现象,应用实例刚刚启动的时候,开始接收请求之后发生了一小段时间的请求阻塞,从 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
: 连接池最大连接数量,默认是 8spring.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:
以上是关于实现微服务预热调用之后再开始服务(上)的主要内容,如果未能解决你的问题,请参考以下文章
微服务框架 SpringCloud微服务架构 多级缓存 48 多级缓存 48.7 Redis 缓存预热
.Net Core with 微服务 - Consul 注册中心
Spring Cloud下使用Feign Form实现微服务之间的文件上传