今天就跟大家聊聊有關(guān)SOFABoot的Readiness健康檢查機(jī)制是怎樣的，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結(jié)了以下內(nèi)容，希望大家根據(jù)這篇文章可以有所收獲。
成都創(chuàng)新互聯(lián)公司是一家專業(yè)的成都網(wǎng)站建設(shè)公司，我們專注網(wǎng)站建設(shè)、成都網(wǎng)站制作、網(wǎng)絡(luò)營(yíng)銷、企業(yè)網(wǎng)站建設(shè)，賣鏈接，一元廣告為企業(yè)客戶提供一站式建站解決方案，能帶給客戶新的互聯(lián)網(wǎng)理念。從網(wǎng)站結(jié)構(gòu)的規(guī)劃UI設(shè)計(jì)到用戶體驗(yàn)提高，創(chuàng)新互聯(lián)力求做到盡善盡美。
SOFABoot是螞蟻金服的開(kāi)源框架，在原有Spring Boot的基礎(chǔ)上增強(qiáng)了不少能力，例如Readiness Check，類隔離，日志空間隔離等能力。除此之外，SOFABoot還可以方便的整合SOFA技術(shù)棧所包含的各類中間件。如果想要對(duì)SOFABoot有體感，可以參考這里快速構(gòu)建一個(gè)SOFABoot的應(yīng)用。
本文來(lái)聊聊SOFABoot新增的Readiness健康檢查機(jī)制。主要內(nèi)容有以下幾點(diǎn)：
liveness 和 readiness 的含義和區(qū)別
SOFABoot項(xiàng)目如何使用readiness的能力
SOFABoot是如何實(shí)現(xiàn)readiness的
服務(wù)的健康檢查，是微服務(wù)的基礎(chǔ)能力，在微服務(wù)的運(yùn)行時(shí)期定時(shí)地檢查服務(wù)健康狀態(tài)，為熔斷降級(jí)等提供決策依據(jù)。那么說(shuō)到健康檢查，這里提出兩個(gè)概念：liveness和readiness。這兩個(gè)概念什么意思呢？有何區(qū)別呢？我們先看看在容器編排領(lǐng)域，k8s官網(wǎng)是在什么場(chǎng)景下提到這兩個(gè)詞的。
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探針來(lái)檢測(cè)應(yīng)用在運(yùn)行的過(guò)程中何時(shí)該重啟一個(gè)容器。例如，liveness探針檢測(cè)到一個(gè)應(yīng)用在運(yùn)行中陷入死鎖狀態(tài)，毫無(wú)進(jìn)展，那么這個(gè)時(shí)候會(huì)重啟容器暫時(shí)避免這種無(wú)解的運(yùn)行狀態(tài)，保持應(yīng)用的正常運(yùn)行。
kuelet用readiness探針來(lái)檢測(cè)何時(shí)一個(gè)容器可以接受業(yè)務(wù)流量。當(dāng)一個(gè)Pod中的所有容器都準(zhǔn)備就緒了，這個(gè)Pod才被認(rèn)為是準(zhǔn)備就緒的，這個(gè)時(shí)候才會(huì)將容器放入到Service的負(fù)載均衡池中，對(duì)外提供服務(wù)。
所以，liveness的職責(zé)是在服務(wù)運(yùn)行期，已經(jīng)在跑業(yè)務(wù)時(shí)，定時(shí)檢查服務(wù)是否正常；而readiness的職責(zé)則是在應(yīng)用服務(wù)運(yùn)行之前，判斷該服務(wù)是否準(zhǔn)備就緒，如果服務(wù)就緒了，負(fù)載均衡就可以將業(yè)務(wù)流量引入到該服務(wù)了。服務(wù)就緒往往有很多需要判斷的，例如：各項(xiàng)配置是否加載完畢。如果這些提供服務(wù)前的準(zhǔn)備工作未就緒，這個(gè)時(shí)候把流量放進(jìn)來(lái)，就會(huì)有大量報(bào)錯(cuò)。
Readiness Check 在 SOFABoot中是個(gè)可選能力，通過(guò)starter的方式提供，如果需要使用，引入下方依賴即可：
com.alipay.sofa healthcheck-sofa-boot-starter
該starter包含了SpringBoot的健康檢查spring-boot-starter-actuator。
在應(yīng)用啟動(dòng)時(shí)，即可啟動(dòng)Readiness檢查。
我們到healthcheck-sofa-boot-starter對(duì)應(yīng)的spring.factories文件看看有哪些自定義bean，其配置如下：
org.springframework.context.ApplicationContextInitializer=\ com.alipay.sofa.healthcheck.initializer.SofaBootHealthCheckInitializer org.springframework.boot.autoconfigure.EnableAutoConfiguration=\ com.alipay.sofa.healthcheck.configuration.SofaBootHealthCheckAutoConfiguration
配置了兩個(gè)SOFABoot的實(shí)現(xiàn)類，一個(gè)是用應(yīng)用初始化組件，一個(gè)是SOFABoot健康檢查需要的配置類。
SofaBootHealthCheckInitializer
這個(gè)是SOFABoot對(duì)于ApplicationContextInitializer的實(shí)現(xiàn)，這個(gè)接口的主要職責(zé)是：在springcontext 刷新（refresh）之前，調(diào)用該接口的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!"); } }
初始化的時(shí)候，判斷了當(dāng)前是否為SpringCloud的引導(dǎo)上下文，如果是的話，則返回，不打印日志，如果不是的話，則打印日志。
這是什么邏輯？ 首先，初始化邏輯里只做了一件事情：打印日志，并且是在非SpringCloud環(huán)境下才打印日志？其實(shí)這是一個(gè)兼容邏輯。在SpringCloud環(huán)境下，自定義的initializer會(huì)被調(diào)用兩次initialize方法（參考 # issue1151 & # issue 232），SpringCloud會(huì)加載一個(gè)引導(dǎo)上下文（bootstrap context）進(jìn)來(lái)，我們自己的應(yīng)用程序會(huì)加載應(yīng)用上下文（application context）進(jìn)來(lái)，這兩個(gè)同時(shí)存在，intialzie會(huì)調(diào)用兩次。
isSpringCloudBootstrapEnvironment方法就是為了區(qū)分是否為SpringCloud加載進(jìn)來(lái)的引導(dǎo)上下文，從而屏蔽掉這次initialize執(zhí)行，確保日志只會(huì)在應(yīng)用上下文時(shí)輸出，該方法主要是通過(guò)是否存在SpringCloud中的特定類來(lái)識(shí)別是否引入SpringCloud，這里就不贅述了，讀者可自行查看。
SofaBootHealthCheckAutoConfiguration
要搞清楚實(shí)現(xiàn)Readiness的核心實(shí)現(xiàn)，我們先看下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個(gè)bean，一個(gè)是應(yīng)用監(jiān)聽(tīng)器ReadinessCheckListener，這個(gè)是入口邏輯，下文核心邏輯講解將從這個(gè)類開(kāi)始。
一個(gè)是Readiness檢查完畢的后置處理器AfterReadinessCheckCallbackProcessor，這個(gè)職責(zé)也比較容易理解，當(dāng)Readiness完成之后，就會(huì)執(zhí)行去處理邏輯。
另外兩個(gè)處理器則是健康檢查的處理器，HealthCheckerProcessor是針對(duì)SOFABoot提供的HealthChecker類型的bean進(jìn)行處理，HealthIndicatorProcesso是針對(duì)SpringBoot提供的HealthIndicator類型的bean進(jìn)行處理。
ReadinessCheckListener
這個(gè)監(jiān)聽(tīng)器實(shí)現(xiàn)了ApplicationListener，并監(jiān)聽(tīng)ContextRefreshedEvent事件，當(dāng)應(yīng)用上下文刷新完成后，觸發(fā)監(jiān)聽(tīng)器收到該事件，執(zhí)行下面的邏輯。
// ReadinessCheckListener 接收到刷新事件后的執(zhí)行邏輯
public void onApplicationEvent(ContextRefreshedEvent event) {
if (applicationContext.equals(event.getApplicationContext())) {
healthCheckerProcessor.init();
healthIndicatorProcessor.init();
afterReadinessCheckCallbackProcessor.init();
readinessHealthCheck();
readinessCheckFinish = true;
}
}接收到上下文的刷新事件后，主要做了四件事情，前面三件是為最后一件事情做準(zhǔn)備的：
健康檢查處理器初始化，將上下文中所有HealthChecker類型的bean都放在map中，等待Readiness檢查。
健康指標(biāo)處理器初始化，將上下文中所有ReactiveHealthIndicator類型的bean都放在map中，等待Readiness檢查。
Readiness檢查后置處理器初始化，將上下文中所有的ReadinessCheckCallback類型的bean都放在map中，等待Readiness檢查完畢后調(diào)用。
Readiness健康檢查，前面三步已經(jīng)準(zhǔn)備好了HealthChecker、ReactiveHealthIndicator和ReadinessCheckCallback的所有bean，這一步是真正開(kāi)始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的處理都是可以基于配置跳過(guò)的，不是必須執(zhí)行的。當(dāng)HealthChecker、HealthIndicator、ReadinessCheckCallback對(duì)應(yīng)的處理器都執(zhí)行成功之后，打印相應(yīng)的結(jié)果信息。
healthCheckerProcessor的readinessHealthCheck主要是去收集每一個(gè)HealthChecker的檢查結(jié)果，當(dāng)所有HealthChecker的檢查結(jié)果都為true時(shí)，返回true。這個(gè)過(guò)程持續(xù)時(shí)間比較長(zhǎng)，如果一個(gè)HealtchChecker返回的結(jié)果是false，processor會(huì)定時(shí)重試再去獲取其結(jié)果，直到其返回true或者重試到最大次數(shù)。
healthIndicatorProcessor的readinessHealthCheck邏輯和healthCheckerProcessor的類似，去收集每一個(gè)HealthIndicator的指標(biāo)的具體信息，但持續(xù)過(guò)程比較短，無(wú)需重試，執(zhí)行完成則返回true。
afterReadinessCheckCallbackProcessor在Readiness檢查完畢之后，逐一去調(diào)用所有ReadinessCheckCallback類型的bean，執(zhí)行readiness的后置處理。
核心邏輯，其實(shí)就是三個(gè)不同類型Bean的處理器，去遍歷執(zhí)行各自的bean集合，收集執(zhí)行結(jié)果。
HealthChecker類型：這個(gè)是SOFABoot提供的，其處理器是SOFABoot提供的，處理器去遍歷執(zhí)行時(shí)需要重試獲取檢查結(jié)果。
ReactiveHealthIndicator類型：這個(gè)是SpringBoot本身提供的，其處理器是SOFABoot提供的，用于處理SpringBoot本身的健康檢查，處理器遍歷執(zhí)行時(shí)無(wú)需重試獲取檢查結(jié)果。
ReadinessCheckCallback類型：這個(gè)是SOFABoot提供的，其處理器是SOFABoot提供的，Readiness檢查后的后置處理bean。
可以看出，SOFABoot提供的HealthChecker和SpringBoot提供的HealthIndicator職責(zé)有點(diǎn)類似，但是存在差異性，HealthChecker中是適合于Readiness的，其實(shí)現(xiàn)類指明重試次數(shù)retryCount和重試間隔retryTimeInterval，在應(yīng)用剛啟動(dòng)時(shí)候，做Readiness檢查不一定能一次性成功，那么就需要這種最大重試機(jī)制，所以HealthChecker的處理器在readinessHealthCheck過(guò)程中持續(xù)的時(shí)間會(huì)更長(zhǎng)。
public interface HealthChecker {
// some method..
default int getRetryCount() {
return 0;
}
default long getRetryTimeInterval(){
return 0;
}
// some method..
}而SpringBoot本身提供的是Liveness機(jī)制，所以HealthIndicator在運(yùn)行期間，本身就是一直定時(shí)去獲取的，沒(méi)有最大重試次數(shù)，只要一直在運(yùn)行，就要定時(shí)去檢查。
public interface HealthIndicator {
// Return an indication of health.
Health health();
}當(dāng)然，SOFABoot在重試完成了HealthCheck的健康檢查之后，再完成了一遍HealthIndicator的健康檢查，且執(zhí)行了一遍后置邏輯，都成功之后，檢查結(jié)果才是健康的，才可以正式對(duì)外提供服務(wù)。
顯然，要擴(kuò)展自己的檢查指標(biāo)也是很容易的，如果是要Readiness Check的，則實(shí)現(xiàn)一個(gè)HealthCheck類，如果是需要Liveness Check的，則實(shí)現(xiàn)一個(gè)HealthIndicator即可。
本文開(kāi)篇介紹了SOFABoot和SpringBoot的關(guān)系，在SpringBoot的健康檢查中，提供了Liveness Check能力，SOFABoot在此之上新增了Readiness Check能力。通過(guò)starter的配置一步一步找到其入口邏輯，并對(duì)應(yīng)用監(jiān)聽(tīng)器、HealthCheck、HealthIndicator和ReadinessCheckCallback對(duì)應(yīng)的三個(gè)處理的邏輯進(jìn)行了核心解讀，并說(shuō)明了HealthCheck和HealthIndicator的區(qū)別。
看完上述內(nèi)容，你們對(duì)SOFABoot的Readiness健康檢查機(jī)制是怎樣的有進(jìn)一步的了解嗎？如果還想了解更多知識(shí)或者相關(guān)內(nèi)容，請(qǐng)關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝大家的支持。
