螞蟻SOFA系列(2) - SOFABoot的Readiness健康檢查機制

404P發表於2019-09-09
作者:404,公眾號404P,轉載請註明出處。

前言

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的方式提供,如果需要使用,引入下方依賴即可:

<dependency>
  <groupId>com.alipay.sofa</groupId>
  <artifactId>healthcheck-sofa-boot-starter</artifactId>
</dependency>

該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<ConfigurableApplicationContext> {
    @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的區別。


file

近期文章:

螞蟻SOFA系列(1) - 聊聊SOFA的模組化

相關文章