背景

  • 无论在测试中还是在线上,我们都会发现在java服务刚开始启动之后,第一个请求会比正常的请求响应时间慢很多,一般会到达几百ms乃至1秒。
  • 在微服务架构中,实例与实例之间存在依赖关系,当A实例依赖B实例,两个实例同时启动时,A实例必需要等B实例就绪并可用后,才可对外提供服务。
  • 如果我们的调用方服务设置了超时时间,那么在被调用方服务刚启动时,会有极大概率达到超时时间限制,从而发生超时异常。
  • 极端情况:当流量非常大的时候,可能会发现,服务一启动,因为响应时间较慢,立刻被高流量打死,而且永远也启动不起来,甚至会造成整个系统的雪崩。
    本文针对这种情况,阐述了原理,并调研了目前业界的预热方案。

预热方案

预热方案有目前以下手段:

  1. 通过流量控制来进行预热:
    1.1. 利用网关的流量控制功能,按照新服务上线时间,给与不同的访问权重,使得服务能够逐渐达到正常访问的热度。
    1.2. 使用sentinel等组件进行warmup限流,在服务上线的时候,将过高的流量直接拦截掉。
    1.3. spring的ribbon组件策略改造,与网关流量控制策略相同。
  2. 在服务启动后,可以正常访问前,让服务自己预热
    2.1. 服务开发者进行编码,启动后,初始化模块自己遍历一遍重要的访问接口
    2.2. 利用测试工具组件(Java Microbenchmark Harness(JMH)),启动后遍历访问接口
    2.3. 使用阿里的开源项目龙井,替换jdk,在服务启动时自动加载该加载的类。阿里龙井使用手册
  3. 发布系统中进行配置访问url列表,由发布系统预热
    每个服务的开发者自己进行评估,列出需要预热的url,将这个url列表存入发布系统,由发布系统调用health之前,由curl调用一遍。

当前使用方案

方案一在流量过高的时候本身就是必须存在的,但是目前我们的sentinel还在建设中
方案二和方案三需要微服务实例能够感知到服务是否已启动完成,如果感知不到,预热就无法进行了

为什么选择actuator而不是自定义endpoint?

  • 采用Starter POM简化Maven的配置
  • 大量采用约定简化Spring的配置
  • 内嵌Tomcat、Jetty或Undertow
  • 提供产品级的运行监控Actuator功能

什么是springboot actuator?
由此可见,actuator是springboot设计的精髓之一,而springboot或者jvm预热属于应用个性化功能,actuator目前的版本包括3.0的版本都没有照顾到。
另外,说到预热少不了就绪探针和存活探针:

就绪探针和存活探针

k8s

  • 当使用 Kubernetes 作为我们编排平台时,每个节点中的 kubelet 负责保持该节点中的 pod 健康。
    例如,有时应用程序可能需要一点时间才能接受请求。 kubelet 可以确保应用程序仅在准备就绪时接收请求。 此外,如果 Pod 的主进程因任何原因崩溃,kubelet 将重新启动容器。
    为了履行这些职责,Kubernetes 有两个探针:活性探针和就绪探针。
  • kubelet 将使用就绪探针来确定应用程序何时准备好接受请求。 更具体地说,当 pod 的所有容器都准备就绪时,它就准备好了。
  • 类似地,kubelet 可以通过活性探针检查 pod 是否还活着。 基本上,活性探针可以帮助 kubelet 知道何时应该重新启动容器。

熟悉了这些概念,看看 Spring Boot 集成是如何工作的。

springboot

从 Spring Boot 2.3 开始,LivenessStateHealthIndicator 和 ReadinessStateHealthIndicator 类将公开应用程序的活跃度和就绪状态。 当将应用程序部署到 Kubernetes 时,Spring Boot 会自动注册这些健康指标。

因此,可以分别使用 /actuator/health/liveness 和 /actuator/health/readiness 端点作为liveness 和 readiness 探针。

例如,以将这些添加到 pod 定义中,以将活性探针配置为 HTTP GET 请求:

livenessProbe:
  httpGet:
    path: /actuator/health/liveness
    port: 8080
    initialDelaySeconds: 3
    periodSeconds: 3

如果使用 Spring Boot 2.3.2 +,可以使用以下属性来启用 liveness 和 readiness 探针:

management:
  endpoint:
    health:
      probes:
        enabled: true
  health:
    livenessstate:
      enabled: true
    readinessstate:
      enabled: true

原理

Spring Boot 使用两个枚举来封装不同的就绪和活跃状态。 对于就绪状态,有一个名为 ReadinessState 的枚举,具有以下值:

  • ACCEPTING_TRAFFIC 状态表示应用程序已准备好接受流量
  • REFUSING_TRAFFIC 状态意味着应用程序还不愿意接受任何请求

同样,LivenessState 枚举使用两个值表示应用程序的活跃状态:

  • CORRECT 值表示应用程序正在运行并且其内部状态是正确的
  • 另一方面,BROKEN 值意味着应用程序运行时出现了一些致命故障

以下是 Spring 中应用程序生命周期事件方面的就绪和活跃状态如何变化:

  1. 注册监听器和初始化器
  2. 准备环境
  3. 准备应用程序上下文
  4. 加载 bean 定义
  5. 将活动状态更改为 CORRECT
  6. 调用应用程序和命令行运行程序
  7. 将就绪状态更改为 ACCEPTING_TRAFFIC
  8. 一旦应用程序启动并运行,(和 Spring 本身)就可以通过发布适当的 AvailabilityChangeEvents 来更改这些状态。

我们的方案

其实有了readiness就绪探针,我们就可以完成我们的预热工作,而Liveness存活探针用于k8s检测实例是否存活,这里有一个坑点:
不能使用/actuator/health来做存活探针!
因为/health进行严格检查springboot各项组件服务,比如邮件服务、数据库服务、mq服务等,当发现有一个组件处于非正常状态,其返回的内容会由{"status": "up"}变为{"status": "down"},从而导致Liveness探针失效,而有些情况下,还抛出异常,在特定情况下某些服务不正常属于正常现象,例如:邮件服务。

ps: 我们在一次邮件服务迁移的过程中,使用Liveness探针频繁访问/health,触发了springboot连续抛出堆栈信息导致服务直接宕机,非常恐怖,如果没有做到宕机快照,会导致查问题无从下手

在actuator/health中自定义健康探针

由于预热可以看做实例能否正常提供服务的健康指标,所以我采用了rediness探针,实例代码如下:

public class SeaReadinessHealthIndicator extends AvailabilityStateHealthIndicator {
    private Integer isChecking = 0;
	private StringBuffer notCompleteExecuteClassBuffer = new StringBuffer();
	
	@Override
	protected void doHealthCheck(Health.Builder builder) {
		switch (isChecking.get()) {
			case 1:
				builder.down().withDetail("message", "instance is starting.").build();
				return;
			case 2:
				builder.outOfService().withDetail("message", String.format("some service start error. they are: %s", notCompleteExecuteClassBuffer.toString())).build();
				return;
			case 200:
				builder.up().build();
				return;
		}
	}
	@Override
	protected AvailabilityState getState(ApplicationAvailability applicationAvailability) {
		return applicationAvailability.getReadinessState();
	}
}

这么设置后,访问/actuator/health/seaReadiness,发现无法访问,再检查/actuator/health目录,发现有一个"cn.xxx.seaReadiness"的状态是{"status":"UP"},原来actuator health的规则是SeaReadinessHealthIndicator,HealthIndicator之前的默认为名称。如果是加入扫描的方式就是这样的,但我现在是用starter的方式进行发布的。
如果我要实现/actuator/health/seaReadiness访问怎么做呢?
在starter扫描的类名中,加上以下别名即可:

@Component("seaReadiness")
public class SeaReadinessHealthIndicator extends AvailabilityStateHealthIndicator

安全考量

早期我们项目在几次生产过程中,为了安全,已将acuator目录做了禁止访问处理,只允许在k8s内部才能进行访问,所以可以考虑不用上spring security来对acuator目录进行保护。

参考资料:
https://blog.csdn.net/qq_39149842/article/details/118995017
https://mobilabsolutions.com/2020/04/a-proper-kubernetes-readiness-probe-with-spring-boot-actuator/
https://www.jdon.com/57471
https://mobilabsolutions.com/2020/04/a-proper-kubernetes-readiness-probe-with-spring-boot-actuator/
https://blog.51cto.com/u_11418075/4870067
https://kubesphere.io/zh/blogs/kubesphere-devops-java-microservice/
https://www.kancloud.cn/java-jdxia/java/1388077#health_73
https://blog.csdn.net/weixin_45503796/article/details/119246564
https://www.jianshu.com/p/ac0566c28562
https://spring.io/blog/2020/03/25/liveness-and-readiness-probes-with-spring-boot
https://blog.csdn.net/JHIII/article/details/126601858
https://blog.csdn.net/jiang18238032891/article/details/109745682
https://blog.csdn.net/weixin_43790623/article/details/104287216
https://blog.csdn.net/weixin_51291483/article/details/126596612

Logo

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐