Shulou(Shulou.com)06/02 Report--

Today, I would like to talk to you about the Readiness health examination mechanism of SOFABoot, which may not be well understood by many people. in order to make you understand better, the editor has summarized the following contents for you. I hope you can get something from this article.

Preface

SOFABoot is Ant Financial Services Group's open source framework, which enhances a lot of capabilities on the basis of the original Spring Boot, such as Readiness Check, class isolation, log space isolation and so on. In addition, SOFABoot can also easily integrate all kinds of middleware contained in the SOFA technology stack. If you want to have a sense of SOFABoot, you can refer to here to quickly build a SOFABoot application.

This article will talk about the new Readiness health check mechanism added by SOFABoot. The main contents are as follows:

The meaning and difference between liveness and readiness

How SOFABoot projects use the capabilities of readiness

How does SOFABoot implement readiness?

One Liveness and Readiness

The health check of the service is the basic capability of the micro-service, which regularly checks the health status of the service during the operation of the micro-service, so as to provide a decision-making basis for fuse degradation and so on. So when it comes to health check-ups, here are two concepts: liveness and readiness. What do these two concepts mean? What's the difference? Let's first take a look at the context in which the K8s official website mentions these two words in the field of container orchestration.

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 uses liveness probes to detect when an application should restart a container while it is running. For example, if the liveness probe detects that an application is stuck in a deadlock state and makes no progress, then the container will be restarted to temporarily avoid this unsolved running state and keep the application running normally.

Kuelet uses readiness probes to detect when a container can accept business traffic. When all the containers in a Pod are ready, the Pod is considered to be ready. Only then will the container be put into the load balancer pool of the Service to provide services.

Therefore, the responsibility of liveness is to check whether the service is normal regularly when the service is running, while readiness is responsible for judging whether the service is ready before the application service is running. If the service is ready, the load balancer can introduce business traffic into the service. Service readiness often requires a lot of judgment, such as whether the configurations are loaded or not. If these pre-service preparations are not ready, if the traffic is put in at this time, there will be a large number of errors.

Using Readiness Check in SOFABoot projects

Readiness Check is an optional capability in SOFABoot, which is provided through starter. If you need to use it, you can introduce the following dependency:

Com.alipay.sofa healthcheck-sofa-boot-starter

The starter contains the health check spring-boot-starter-actuator for SpringBoot.

When the application starts, you can start the Readiness check.

How to realize Readiness Check with three SOFABoot

Let's go to the spring.factories file corresponding to healthcheck-sofa-boot-starter to see what custom bean is available. The configuration is as follows:

Org.springframework.context.ApplicationContextInitializer=\ com.alipay.sofa.healthcheck.initializer.SofaBootHealthCheckInitializerorg.springframework.boot.autoconfigure.EnableAutoConfiguration=\ com.alipay.sofa.healthcheck.configuration.SofaBootHealthCheckAutoConfiguration

Two SOFABoot implementation classes are configured, one is to initialize the component with the application, and the other is the configuration class required for SOFABoot health check.

1 Application initialization

SofaBootHealthCheckInitializer

This is SOFABoot's implementation of ApplicationContextInitializer. The main responsibility of this API is: before springcontext refresh (refresh), call the initialize of this API to do the pre-initialization operation. Let's see what SOFABoot initialization does:

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!");}}

During initialization, it is determined whether it is currently the boot context of SpringCloud, if so, it is returned, the log is not printed, if not, the log is printed.

What kind of logic is that? First of all, only one thing is done in the initialization logic: print the log, and print the log in a non-SpringCloud environment? In fact, this is a compatible logic. In the SpringCloud environment, the custom initializer will be called the initialize method twice (see # issue1151 & # issue 232), the SpringCloud will load a boot context (bootstrap context), and our own application will load the application context (application context), both of which exist at the same time, and the intialzie will be called twice.

The purpose of the isSpringCloudBootstrapEnvironment method is to distinguish whether it is the boot context loaded by SpringCloud, so as to block the initialize execution and ensure that the log will only be output in the application context. This method mainly identifies whether SpringCloud is introduced by whether there are specific classes in SpringCloud. Readers can check it for themselves.

Introduction to core logic 2.1Core Bean of implementing Readiness with 2 SOFABoot

SofaBootHealthCheckAutoConfiguration

To figure out the core implementation of Readiness, let's first take a look at which bean is assembled by SOFABoot. Here are some core bean.

@ Configurationpublic 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 ();}}

A total of four bean are listed above, one is the application listener ReadinessCheckListener, and this is the entry logic. The following core logic explanation will start with this class.

One is the post-processor AfterReadinessCheckCallbackProcessor, which is checked by the Readiness, which is also relatively easy to understand, and when the Readiness is complete, the de-processing logic is executed.

The other two processors are health check processors, HealthCheckerProcessor is for bean of type HealthChecker provided by SOFABoot, and HealthIndicatorProcesso is for bean of type HealthIndicator provided by SpringBoot.

2.2 Core logic analysis

ReadinessCheckListener

The listener implements the ApplicationListener and listens for the ContextRefreshedEvent event. When the application context refreshes, the trigger listener receives the event and executes the following logic.

/ / the execution logic public void onApplicationEvent (ContextRefreshedEvent event) {if (applicationContext.equals (event.getApplicationContext () {healthCheckerProcessor.init (); healthIndicatorProcessor.init (); afterReadinessCheckCallbackProcessor.init (); readinessHealthCheck (); readinessCheckFinish = true;}} after ReadinessCheckListener receives the refresh event

After receiving the context refresh event, four main things are done, and the first three are in preparation for the last thing:

The health check processor initializes, putting all the bean of type HealthChecker in the context into the map, waiting for the Readiness check.

The health indicator processor initializes, placing all bean of type ReactiveHealthIndicator in the context in the map, waiting for the Readiness to check.

Readiness checks the post-processor initialization, puts all the ReadinessCheckCallback type bean in the context in the map, and waits for the Readiness check to be called.

Readiness health check, the first three steps have prepared all the bean for HealthChecker, ReactiveHealthIndicator, and ReadinessCheckCallback, this step is to really start the Readiness health check. The core logic of Readiness inspection is as follows:

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 .ReadinessCheckCallback (healthCallbackDetails); if (healthCheckerStatus & & healthIndicatorStatus & & healthCallbackStatus) {logger.info ("Readiness check result: success") } else {logger.error ("Readiness check result: fail");}}

From the above logic, we can see that the processing of HealthChecker and HealthIndicator can be skipped based on configuration and is not required. When the corresponding processors of HealthChecker, HealthIndicator and ReadinessCheckCallback are executed successfully, the corresponding result information is printed.

The readinessHealthCheck of healthCheckerProcessor is mainly to collect the check results of each HealthChecker. When the check result of all HealthChecker is true, true is returned. This process takes a long time, and if the result returned by a HealtchChecker is false,processor, it will periodically retry and get its result until it returns true or retries the maximum number of times.

The readinessHealthCheck logic of healthIndicatorProcessor is similar to that of healthCheckerProcessor, which collects specific information about the metrics of each HealthIndicator, but the duration is relatively short and there is no need to retry. If the execution is completed, true is returned.

After the Readiness check, afterReadinessCheckCallbackProcessor invokes bean of all ReadinessCheckCallback types one by one to perform the post-processing of readiness.

The core logic is actually three different types of Bean processors to traverse the respective bean collections and collect the execution results.

HealthChecker type: this is provided by SOFABoot and its processor is provided by SOFABoot. The processor needs to retry to get the check results when it traverses the execution.

ReactiveHealthIndicator type: this is provided by SpringBoot itself, and its processor is provided by SOFABoot to handle the health check of SpringBoot itself, and the processor traverses the execution without having to retry to get the check results.

ReadinessCheckCallback type: this is provided by SOFABoot, its processor is provided by SOFABoot, and the post-processing bean after Readiness check.

As you can see, the HealthIndicator responsibilities provided by HealthChecker provided by SOFABoot are similar to those provided by SpringBoot, but there are differences. HealthChecker is suitable for Readiness. Its implementation class specifies the number of retries (retryCount) and the interval between retries (retryTimeInterval). When the application is launched, the Readiness check may not be successful at one time, so this maximum retry mechanism is needed, so the processor of HealthChecker lasts longer in the readinessHealthCheck process.

Public interface HealthChecker {/ / some method.. Default int getRetryCount () {return 0;} default long getRetryTimeInterval () {return 0;} / / some method..}

SpringBoot itself provides Liveness mechanism, so HealthIndicator itself is always regularly obtained during operation, and there is no maximum number of retries. As long as it is running all the time, it is necessary to check it regularly.

Public interface HealthIndicator {/ / Return an indication of health. Health health ();}

Of course, after retrying to complete the health check of HealthCheck, SOFABoot has completed the health check of HealthIndicator again, and the post-set logic has been executed successfully, only after the test result is healthy can the service be officially provided to the public.

Obviously, it's easy to expand your own check metrics, and if you want to Readiness Check, implement a HealthCheck class, and if you need Liveness Check, you can implement a HealthIndicator.

Four concluding remarks

This article begins with an introduction to the relationship between SOFABoot and SpringBoot. Liveness Check capability is provided in the health examination of SpringBoot, and SOFABoot adds Readiness Check capability on top of it. Through the configuration of starter, the entry logic is found step by step, and the core interpretation of the three processing logic corresponding to application listener, HealthCheck, HealthIndicator and ReadinessCheckCallback is carried out, and the difference between HealthCheck and HealthIndicator is explained.

After reading the above, do you have any further understanding of SOFABoot's Readiness health examination mechanism? If you want to know more knowledge or related content, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.