本文轉(zhuǎn)載自微信公眾號「捉蟲大師」，作者捉蟲大師 。轉(zhuǎn)載本文請聯(lián)系捉蟲大師公眾號。

 幾個月前，我在《4個實驗，徹底搞懂TCP連接的斷開》這篇文章中給自己挖了個坑：

文中提到的實際問題就是服務(wù)探活，今天來填上這個坑。

在微服務(wù)架構(gòu)下，服務(wù)提供方(Provider)的節(jié)點一般不止一個，消費方(Consumer)根據(jù)負(fù)載均衡算法挑選一個健康的節(jié)點進(jìn)行調(diào)用。識別Provider節(jié)點是否健康，這便是服務(wù)探活 要討論的內(nèi)容。

健康的節(jié)點可定義為能正常響應(yīng)Consumer請求的節(jié)點，不健康自然是不能正常響應(yīng)Consumer請求的節(jié)點

不健康的原因可能是物理上的斷電、斷網(wǎng)、硬件故障，也可能是網(wǎng)絡(luò)延遲、進(jìn)程異常退出或進(jìn)程無法處理請求。

總之一句話總結(jié)起來就是Provider節(jié)點沒有摘除流量前，就無法處理請求了。可以分為三類：

系統(tǒng)異常：如斷電、斷網(wǎng)、其他硬件故障、或操作系統(tǒng)異常退出

進(jìn)程異常退出：進(jìn)程異常退出，端口掛掉，如有注銷機(jī)制但沒來得及注銷，如執(zhí)行了kill -9

進(jìn)程無法處理請求：端口還在，但服務(wù)無法正常響應(yīng)，如Full GC期間

一個Provider節(jié)點的狀態(tài)只有健康和不健康，由健康到不健康稱之為探死，由不健康到健康稱之為探活，一般我們不分這么細(xì)，統(tǒng)一叫探活。

至于是誰來探，可能是Consumer，也可能是注冊中心，甚至是某個單獨的探活組件。我們就從探活的發(fā)起者來列舉目前主流的探活方式。

Consumer被動探活

最簡單的是在Consumer側(cè)進(jìn)行探活，如果Consumer調(diào)用Provider報錯，則Consumer將該Provider剔掉，為了防止偶發(fā)的網(wǎng)絡(luò)抖動或其他干擾，可設(shè)置一個時間窗口，窗口內(nèi)失敗達(dá)N 次則剔除，當(dāng)過了這段時間，再把這個Provider重置為正常。

這種方式的典型代表是Nginx，Nginx可配置多長時間內(nèi)，失敗多少次則認(rèn)為該Provider不可用，其失敗可以是連接失敗、也可以是某些http狀態(tài)碼(如4xx，5xx)

這種方案的缺點很明顯，需要真實流量去檢測，如果配置了失敗繼續(xù)轉(zhuǎn)發(fā)給下一個Provider，則時間窗口的開始的一段時間內(nèi)耗時上升，未配置則直接報錯，所以無論怎么配置，對服務(wù)都是有影響的。

Consumer主動探活

Consumer被動健康檢查的主要問題在于使用了真實流量檢測，其實只要稍微改一改，使用旁路的方式去檢測即可避免。

阿里的Tengine開源了一個nginx_upstream_check_module模塊來做主動健康檢查。

這個旁路可以一直去探測Provider，當(dāng)檢測到異常時，將其標(biāo)記為不可用狀態(tài)，請求不再發(fā)往該Provider，若檢測到Provider 健康時，再將其標(biāo)記為健康。

Consumer側(cè)的探活在RPC框架實現(xiàn)的比較少，不知道是基于怎樣的一種考慮，其實有些企業(yè)內(nèi)會在Consumer側(cè)已經(jīng)加入了探活機(jī)制，比如愛奇藝在Dubbo的Consumer側(cè)增加了探活機(jī)制，其實我所在的公司內(nèi)部RPC框架也是有Consumer側(cè)的服務(wù)探活。

參考《愛奇藝在 Dubbo 生態(tài)下的微服務(wù)架構(gòu)實踐》https://developer.aliyun.com/article/771495

但Dubbo官方?jīng)]有集成，至于為什么，我也去github上問過，不過沒人回復(fù)~

Provider上報心跳

當(dāng)有一個注冊中心時，探活這項任務(wù)就可以交給注冊中心了。

最簡單的，我們想到了心跳保持這個策略，Provider注冊成功后，一直向注冊中心發(fā)送心跳包，注冊中心定時檢查Provider，如果長時間未發(fā)送心跳包，就將其置為不可用，并告知Consumer，如果心跳恢復(fù)，則將其恢復(fù)并通知。

某些組件也支持這種續(xù)約的特性，如etcd、redis等都可以構(gòu)建類似的系統(tǒng)。

這種方式的代表是Nacos 1.x 版本中的臨時實例。

慢慢你會發(fā)現(xiàn)這種方式摘除故障節(jié)點的時效性和資源的使用成正相關(guān)，如果你想要更好的時效性，就必須縮短心跳間隔，從而會增加心跳請求量，每次心跳得更新每個節(jié)點的上次心跳時間，占用了大量資源。

Provider與注冊中心會話保持

為了解決心跳請求占用大量資源的問題，我們想到了TCP 連接不是一個天然的健康檢查機(jī)制嗎?如果僅僅依靠TCP連接可以嗎?

這就是之前文章埋下的坑，再次總結(jié)一下這篇文章《4個實驗，徹底搞懂TCP連接的斷開》中關(guān)于TCP連接斷開的場景：

• 如果是進(jìn)程終止、無論是正?；蛘呤钱惓＃灰僮飨到y(tǒng)還在，TCP連接就會正確斷開
• 如果是斷電、斷網(wǎng)或其他因素導(dǎo)致操作系統(tǒng)掛掉，則網(wǎng)絡(luò)不一定能正確斷開，還得分情況
  • 如果此時注冊中心有往Provider發(fā)送數(shù)據(jù)，那么是能及時感知到Provider的異常，并斷開連接的
  • 如果注冊中心沒有往Provider發(fā)送數(shù)據(jù)，是不能及時感知連接的斷開，即使配置了TCP的KeepAlive，也需要大概2小時才能感知到

2小時肯定不能接受，為了防止這種情況，光靠TCP是不夠的，還得在應(yīng)用層實現(xiàn)一個心跳檢測，為了節(jié)省資源，可以將心跳包設(shè)計的很小，發(fā)送頻率不需要那么高，通常1分鐘內(nèi)能感知即可。

因為只有斷電、斷網(wǎng)或硬件故障才會導(dǎo)致無法感知連接的斷開，這個比例很小。

可以參考下圖，雖然圖中的數(shù)據(jù)是我杜撰的，但八九不離十吧，可以看到系統(tǒng)異常只占1%，這1%中未發(fā)數(shù)據(jù)可能更少，所以可以認(rèn)為這個概率很小。

這種方式比較常見，像Dubbo使用的Zookeeper，Nacos 2.x版本(gRPC)的臨時實例，SOFARegistry等等都用了這這種方式。

其中SOFARegistry比較有意思，它提出了一種連接敏感的長連接，乍一看以為用了什么黑科技，后來看了代碼發(fā)現(xiàn)就是TCP連接加應(yīng)用層的心跳檢測，這些被他們封裝在SOFABolt通信框架中。

參考《海量數(shù)據(jù)下的注冊中心 - SOFARegistry 架構(gòu)介紹》https://mp.weixin.qq.com/s/mZo7Dg6gfNqXoetaqgwMww

但這個方式也有一個明顯的缺點，如果網(wǎng)絡(luò)狀況不好的情況下，TCP連接比較容易斷開，會導(dǎo)致節(jié)點頻繁上下線。

注冊中心主動探測

除了上述的方式，還有一種注冊中心(甚至是一個單獨的組件)主動探測Provider的方式，與Consumer主動探測類似，只不過把探測任務(wù)移交給了注冊中心或一個單獨的組件。

主動探測有個最大的優(yōu)勢是可以擴(kuò)展非常豐富的探測方式，比如最常見的探測端口是否存活，又或者探測Provider的一個http接口返回是否符合預(yù)期，甚至可以擴(kuò)展為MySQL、Redis等等協(xié)議的探測。

這也是種能解決服務(wù)假死的探活方式，Nacos中的永久實例探活就是采用的這種方式。

但這種方式在實際使用的時候要考慮主動探測組件的高可用，高可用就得存在副本，可采取主備方式。

如果單機(jī)存在性能瓶頸，還得分布式探活，主備可能就不適合，得有一個分布式協(xié)調(diào)者，這要說又得長篇大論。但這里你知道有這么個事兒就可以了。

考量探活的指標(biāo)有三個：

• 能不能探出來?——功能性
• 什么時候探出來?——時效性
• 會不會探錯了?——穩(wěn)定性

功能上最強(qiáng)的是帶語義的主動探測，時效性最強(qiáng)的要屬長連接會話保持。

穩(wěn)定性不好說誰強(qiáng)誰弱，但一般會給一個集群設(shè)置一個探活摘除的比例，比如最多摘除50%機(jī)器，防止探活錯誤導(dǎo)致節(jié)點全部下線，這也算是一種兜底策略吧。