SOFABoot的Readiness健康检查机制是怎样的
今天就跟大家聊聊有关SOFABoot的Readiness健康检查机制是怎样的，可能很多人都不太了解，为了让大家更加了解，小编给大家总结了以下内容，希望大家根据这篇文章可以有所收获。
成都创新互联公司是一家专业的成都网站建设公司，我们专注网站建设、成都网站制作、网络营销、企业网站建设，卖链接，一元广告为企业客户提供一站式建站解决方案，能带给客户新的互联网理念。从网站结构的规划UI设计到用户体验提高，创新互联力求做到尽善尽美。
前言
SOFABoot是蚂蚁金服的开源框架，在原有Spring Boot的基础上增强了不少能力，例如Readiness Check，类隔离，日志空间隔离等能力。除此之外，SOFABoot还可以方便的整合SOFA技术栈所包含的各类中间件。如果想要对SOFABoot有体感，可以参考这里快速构建一个SOFABoot的应用。
本文来聊聊SOFABoot新增的Readiness健康检查机制。主要内容有以下几点：
liveness 和 readiness 的含义和区别
SOFABoot项目如何使用readiness的能力
SOFABoot是如何实现readiness的
一 Liveness 和Readiness
服务的健康检查，是微服务的基础能力，在微服务的运行时期定时地检查服务健康状态，为熔断降级等提供决策依据。那么说到健康检查，这里提出两个概念：liveness和readiness。这两个概念什么意思呢？有何区别呢？我们先看看在容器编排领域，k8s官网是在什么场景下提到这两个词的。
The kubelet uses liveness probes to know when to restart a Container. For example, liveness probes could catch a deadlock, where an application is running, but unable to make progress. Restarting a Container in such a state can help to make the application more available despite bugs.
The kubelet uses readiness probes to know when a Container is ready to start accepting traffic. A Pod is considered ready when all of its Containers are ready. One use of this signal is to control which Pods are used as backends for Services. When a Pod is not ready, it is removed from Service load balancers.
kubelet用liveness探针来检测应用在运行的过程中何时该重启一个容器。例如，liveness探针检测到一个应用在运行中陷入死锁状态，毫无进展，那么这个时候会重启容器暂时避免这种无解的运行状态，保持应用的正常运行。
kuelet用readiness探针来检测何时一个容器可以接受业务流量。当一个Pod中的所有容器都准备就绪了，这个Pod才被认为是准备就绪的，这个时候才会将容器放入到Service的负载均衡池中，对外提供服务。
所以，liveness的职责是在服务运行期，已经在跑业务时，定时检查服务是否正常；而readiness的职责则是在应用服务运行之前，判断该服务是否准备就绪，如果服务就绪了，负载均衡就可以将业务流量引入到该服务了。服务就绪往往有很多需要判断的，例如：各项配置是否加载完毕。如果这些提供服务前的准备工作未就绪，这个时候把流量放进来，就会有大量报错。
二 SOFABoot项目中使用Readiness Check
Readiness Check 在 SOFABoot中是个可选能力，通过starter的方式提供，如果需要使用，引入下方依赖即可：
com.alipay.sofa healthcheck-sofa-boot-starter
该starter包含了SpringBoot的健康检查spring-boot-starter-actuator。
在应用启动时，即可启动Readiness检查。
三 SOFABoot如何实现Readiness Check
我们到healthcheck-sofa-boot-starter对应的spring.factories文件看看有哪些自定义bean，其配置如下：
org.springframework.context.ApplicationContextInitializer=\ com.alipay.sofa.healthcheck.initializer.SofaBootHealthCheckInitializer org.springframework.boot.autoconfigure.EnableAutoConfiguration=\ com.alipay.sofa.healthcheck.configuration.SofaBootHealthCheckAutoConfiguration
配置了两个SOFABoot的实现类，一个是用应用初始化组件，一个是SOFABoot健康检查需要的配置类。
1 应用初始化
SofaBootHealthCheckInitializer
这个是SOFABoot对于ApplicationContextInitializer的实现，这个接口的主要职责是：在springcontext 刷新（refresh）之前，调用该接口的initialize做前置的初始化操作，我们看看SOFABoot初始化做了什么事情：
public class SofaBootHealthCheckInitializer implements ApplicationContextInitializer{ @Override public void initialize(ConfigurableApplicationContext applicationContext) { Environment environment = applicationContext.getEnvironment(); if (SOFABootEnvUtils.isSpringCloudBootstrapEnvironment(environment)) { return; } LOGGER.info("SOFABoot HealthCheck Starting!"); } }
初始化的时候，判断了当前是否为SpringCloud的引导上下文，如果是的话，则返回，不打印日志，如果不是的话，则打印日志。
这是什么逻辑？ 首先，初始化逻辑里只做了一件事情：打印日志，并且是在非SpringCloud环境下才打印日志？其实这是一个兼容逻辑。在SpringCloud环境下，自定义的initializer会被调用两次initialize方法（参考 # issue1151 & # issue 232），SpringCloud会加载一个引导上下文（bootstrap context）进来，我们自己的应用程序会加载应用上下文（application context）进来，这两个同时存在，intialzie会调用两次。
isSpringCloudBootstrapEnvironment方法就是为了区分是否为SpringCloud加载进来的引导上下文，从而屏蔽掉这次initialize执行，确保日志只会在应用上下文时输出，该方法主要是通过是否存在SpringCloud中的特定类来识别是否引入SpringCloud，这里就不赘述了，读者可自行查看。
2 SOFABoot实现Readiness的核心逻辑
2.1 核心Bean介绍
SofaBootHealthCheckAutoConfiguration
要搞清楚实现Readiness的核心实现，我们先看下SOFABoot到底装配了哪些bean，下面列了一些核心的bean。
@Configuration
public class SofaBootHealthCheckAutoConfiguration {
@Bean
public ReadinessCheckListener readinessCheckListener() {
return new ReadinessCheckListener();
}
@Bean
public HealthCheckerProcessor healthCheckerProcessor() {
return new HealthCheckerProcessor();
}
@Bean
public HealthIndicatorProcessor healthIndicatorProcessor() {
return new HealthIndicatorProcessor();
}
@Bean
public AfterReadinessCheckCallbackProcessor afterReadinessCheckCallbackProcessor() {
return new AfterReadinessCheckCallbackProcessor();
}
}上面一共罗列了4个bean，一个是应用监听器ReadinessCheckListener，这个是入口逻辑，下文核心逻辑讲解将从这个类开始。
一个是Readiness检查完毕的后置处理器AfterReadinessCheckCallbackProcessor，这个职责也比较容易理解，当Readiness完成之后，就会执行去处理逻辑。
另外两个处理器则是健康检查的处理器，HealthCheckerProcessor是针对SOFABoot提供的HealthChecker类型的bean进行处理，HealthIndicatorProcesso是针对SpringBoot提供的HealthIndicator类型的bean进行处理。
2.2 核心逻辑解析
ReadinessCheckListener
这个监听器实现了ApplicationListener，并监听ContextRefreshedEvent事件，当应用上下文刷新完成后，触发监听器收到该事件，执行下面的逻辑。
// ReadinessCheckListener 接收到刷新事件后的执行逻辑
public void onApplicationEvent(ContextRefreshedEvent event) {
if (applicationContext.equals(event.getApplicationContext())) {
healthCheckerProcessor.init();
healthIndicatorProcessor.init();
afterReadinessCheckCallbackProcessor.init();
readinessHealthCheck();
readinessCheckFinish = true;
}
}接收到上下文的刷新事件后，主要做了四件事情，前面三件是为最后一件事情做准备的：
健康检查处理器初始化，将上下文中所有HealthChecker类型的bean都放在map中，等待Readiness检查。
健康指标处理器初始化，将上下文中所有ReactiveHealthIndicator类型的bean都放在map中，等待Readiness检查。
Readiness检查后置处理器初始化，将上下文中所有的ReadinessCheckCallback类型的bean都放在map中，等待Readiness检查完毕后调用。
Readiness健康检查，前面三步已经准备好了HealthChecker、ReactiveHealthIndicator和ReadinessCheckCallback的所有bean，这一步是真正开始Readiness健康检查。Readiness检查核心逻辑如下：
public void readinessHealthCheck() {
if (skipAllCheck()) {
logger.warn("Skip all readiness health check.");
} else {
if (skipComponent()) {
logger.warn("Skip HealthChecker health check.");
} else {
healthCheckerStatus = healthCheckerProcessor
.readinessHealthCheck(healthCheckerDetails);
}
if (skipIndicator()) {
logger.warn("Skip HealthIndicator health check.");
} else {
healthIndicatorStatus = healthIndicatorProcessor
.readinessHealthCheck(healthIndicatorDetails);
}
}
healthCallbackStatus = afterReadinessCheckCallbackProcessor
.afterReadinessCheckCallback(healthCallbackDetails);
if (healthCheckerStatus && healthIndicatorStatus && healthCallbackStatus) {
logger.info("Readiness check result: success");
} else {
logger.error("Readiness check result: fail");
}
}从上面的逻辑，我们可以看到HealthChecker和HealthIndicator的处理都是可以基于配置跳过的，不是必须执行的。当HealthChecker、HealthIndicator、ReadinessCheckCallback对应的处理器都执行成功之后，打印相应的结果信息。
healthCheckerProcessor的readinessHealthCheck主要是去收集每一个HealthChecker的检查结果，当所有HealthChecker的检查结果都为true时，返回true。这个过程持续时间比较长，如果一个HealtchChecker返回的结果是false，processor会定时重试再去获取其结果，直到其返回true或者重试到最大次数。
healthIndicatorProcessor的readinessHealthCheck逻辑和healthCheckerProcessor的类似，去收集每一个HealthIndicator的指标的具体信息，但持续过程比较短，无需重试，执行完成则返回true。
afterReadinessCheckCallbackProcessor在Readiness检查完毕之后，逐一去调用所有ReadinessCheckCallback类型的bean，执行readiness的后置处理。
核心逻辑，其实就是三个不同类型Bean的处理器，去遍历执行各自的bean集合，收集执行结果。
HealthChecker类型：这个是SOFABoot提供的，其处理器是SOFABoot提供的，处理器去遍历执行时需要重试获取检查结果。
ReactiveHealthIndicator类型：这个是SpringBoot本身提供的，其处理器是SOFABoot提供的，用于处理SpringBoot本身的健康检查，处理器遍历执行时无需重试获取检查结果。
ReadinessCheckCallback类型：这个是SOFABoot提供的，其处理器是SOFABoot提供的，Readiness检查后的后置处理bean。
可以看出，SOFABoot提供的HealthChecker和SpringBoot提供的HealthIndicator职责有点类似，但是存在差异性，HealthChecker中是适合于Readiness的，其实现类指明重试次数retryCount和重试间隔retryTimeInterval，在应用刚启动时候，做Readiness检查不一定能一次性成功，那么就需要这种最大重试机制，所以HealthChecker的处理器在readinessHealthCheck过程中持续的时间会更长。
public interface HealthChecker {
// some method..
default int getRetryCount() {
return 0;
}
default long getRetryTimeInterval(){
return 0;
}
// some method..
}而SpringBoot本身提供的是Liveness机制，所以HealthIndicator在运行期间，本身就是一直定时去获取的，没有最大重试次数，只要一直在运行，就要定时去检查。
public interface HealthIndicator {
// Return an indication of health.
Health health();
}当然，SOFABoot在重试完成了HealthCheck的健康检查之后，再完成了一遍HealthIndicator的健康检查，且执行了一遍后置逻辑，都成功之后，检查结果才是健康的，才可以正式对外提供服务。
显然，要扩展自己的检查指标也是很容易的，如果是要Readiness Check的，则实现一个HealthCheck类，如果是需要Liveness Check的，则实现一个HealthIndicator即可。
四 结语
本文开篇介绍了SOFABoot和SpringBoot的关系，在SpringBoot的健康检查中，提供了Liveness Check能力，SOFABoot在此之上新增了Readiness Check能力。通过starter的配置一步一步找到其入口逻辑，并对应用监听器、HealthCheck、HealthIndicator和ReadinessCheckCallback对应的三个处理的逻辑进行了核心解读，并说明了HealthCheck和HealthIndicator的区别。
看完上述内容，你们对SOFABoot的Readiness健康检查机制是怎样的有进一步的了解吗？如果还想了解更多知识或者相关内容，请关注创新互联行业资讯频道，感谢大家的支持。
分享标题：SOFABoot的Readiness健康检查机制是怎样的
网页链接：http://myzitong.com/article/ijdhes.html