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

 幾個(gè)月前，我在《4個(gè)實(shí)驗(yàn)，徹底搞懂TCP連接的斷開》這篇文章中給自己挖了個(gè)坑：

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

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

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

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

總之一句話總結(jié)起來就是Provider節(jié)點(diǎn)沒有摘除流量前，就無法處理請(qǐng)求了?？梢苑譃槿悾?/p>

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

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

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

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

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

Consumer被動(dòng)探活

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

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

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

Consumer主動(dòng)探活

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

阿里的Tengine開源了一個(gè)nginx_upstream_check_module模塊來做主動(dòng)健康檢查。

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

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

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

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

Provider上報(bào)心跳

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

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

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

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

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

Provider與注冊(cè)中心會(huì)話保持

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

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

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

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

因?yàn)橹挥袛嚯姟嗑W(wǎng)或硬件故障才會(huì)導(dǎo)致無法感知連接的斷開，這個(gè)比例很小。

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

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

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

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

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

注冊(cè)中心主動(dòng)探測

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

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

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

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

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

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

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

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

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