背景

• 无论在测试中还是在线上，我们都会发现在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

最后

以上就是内向小兔子为你收集整理的SpringBoot使用自定义actuator健康检查完成服务预热、微服务依赖检查背景预热方案当前使用方案为什么选择actuator而不是自定义endpoint?就绪探针和存活探针我们的方案安全考量的全部内容，希望文章能够帮你解决SpringBoot使用自定义actuator健康检查完成服务预热、微服务依赖检查背景预热方案当前使用方案为什么选择actuator而不是自定义endpoint?就绪探针和存活探针我们的方案安全考量所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。