幾個月前，我在《4個實驗，徹底搞懂TCP連線的斷開》這篇文章中給自己挖了個坑：
文中提到的實際問題就是服務探活，今天來填上這個坑。
在微服務架構下，服務提供方（Provider）的節點一般不止一個，消費方（Consumer）根據負載均衡演算法挑選一個健康的節點進行呼叫。識別Provider節點是否健康，這便是服務探活 要討論的內容。
健康的節點可定義為能正常響應Consumer請求的節點，不健康自然是不能正常響應Consumer請求的節點
不健康的原因可能是物理上的斷電、斷網、硬體故障，也可能是網路延遲、程式異常退出或程式無法處理請求。
總之一句話總結起來就是Provider節點沒有摘除流量前，就無法處理請求了。可以分為三類：
- 系統異常：如斷電、斷網、其他硬體故障、或作業系統異常退出
- 程式異常退出：程式異常退出，埠掛掉，如有登出機制但沒來得及登出，如執行了kill -9
- 程式無法處理請求：埠還在，但服務無法正常響應，如Full GC期間
一個Provider節點的狀態只有健康和不健康，由健康到不健康稱之為探死，由不健康到健康稱之為探活，一般我們不分這麼細，統一叫探活。
至於是誰來探，可能是Consumer，也可能是註冊中心，甚至是某個單獨的探活元件。我們就從探活的發起者來列舉目前主流的探活方式。
Consumer被動探活
最簡單的是在Consumer側進行探活，如果Consumer呼叫Provider報錯，則Consumer將該Provider剔掉，為了防止偶發的網路抖動或其他干擾，可設定一個時間視窗，視窗內失敗達N 次則剔除，當過了這段時間，再把這個Provider重置為正常。
這種方式的典型代表是Nginx，Nginx可配置多長時間內，失敗多少次則認為該Provider不可用，其失敗可以是連線失敗、也可以是某些http狀態碼（如4xx，5xx）
這種方案的缺點很明顯，需要真實流量去檢測，如果配置了失敗繼續轉發給下一個Provider，則時間視窗的開始的一段時間內耗時上升，未配置則直接報錯，所以無論怎麼配置，對服務都是有影響的。
Consumer主動探活
Consumer被動健康檢查的主要問題在於使用了真實流量檢測，其實只要稍微改一改，使用旁路的方式去檢測即可避免。
阿里的Tengine開源了一個nginx_upstream_check_module模組來做主動健康檢查。
這個旁路可以一直去探測Provider，當檢測到異常時，將其標記為不可用狀態，請求不再發往該Provider，若檢測到Provider 健康時，再將其標記為健康。
Consumer側的探活在RPC框架實現的比較少，不知道是基於怎樣的一種考慮，其實有些企業內會在Consumer側已經加入了探活機制，比如愛奇藝在Dubbo的Consumer側增加了探活機制，其實我所在的公司內部RPC框架也是有Consumer側的服務探活。
參考《愛奇藝在 Dubbo 生態下的微服務架構實踐》https://developer.aliyun.com/article/771495
但Dubbo官方沒有整合，至於為什麼，我也去github上問過，不過沒人回覆~
Provider上報心跳
當有一個註冊中心時，探活這項任務就可以交給註冊中心了。
最簡單的，我們想到了心跳保持這個策略，Provider註冊成功後，一直向註冊中心傳送心跳包，註冊中心定時檢查Provider，如果長時間未傳送心跳包，就將其置為不可用，並告知Consumer，如果心跳恢復，則將其恢復並通知。
某些元件也支援這種續約的特性，如etcd、redis等都可以構建類似的系統。
這種方式的代表是Nacos 1.x 版本中的臨時例項。
慢慢你會發現這種方式摘除故障節點的時效性和資源的使用成正相關，如果你想要更好的時效性，就必須縮短心跳間隔，從而會增加心跳請求量，每次心跳得更新每個節點的上次心跳時間，佔用了大量資源。
Provider與註冊中心會話保持
為了解決心跳請求佔用大量資源的問題，我們想到了TCP 連線不是一個天然的健康檢查機制嗎？如果僅僅依靠TCP連線可以嗎？
這就是之前文章埋下的坑，再次總結一下這篇文章《4個實驗，徹底搞懂TCP連線的斷開》中關於TCP連線斷開的場景：
- 如果是程式終止、無論是正常或者是異常，只要作業系統還在，TCP連線就會正確斷開
- 如果是斷電、斷網或其他因素導致作業系統掛掉，則網路不一定能正確斷開，還得分情況
- 如果此時註冊中心有往Provider傳送資料，那麼是能及時感知到Provider的異常，並斷開連線的
- 如果註冊中心沒有往Provider傳送資料，是不能及時感知連線的斷開，即使配置了TCP的KeepAlive，也需要大概2小時才能感知到
2小時肯定不能接受，為了防止這種情況，光靠TCP是不夠的，還得在應用層實現一個心跳檢測，為了節省資源，可以將心跳包設計的很小，傳送頻率不需要那麼高，通常1分鐘內能感知即可。
因為只有斷電、斷網或硬體故障才會導致無法感知連線的斷開，這個比例很小。
可以參考下圖，雖然圖中的資料是我杜撰的，但八九不離十吧，可以看到系統異常只佔1%，這1%中未發資料可能更少，所以可以認為這個概率很小。
這種方式比較常見，像Dubbo使用的Zookeeper，Nacos 2.x版本（gRPC）的臨時例項，SOFARegistry等等都用了這這種方式。
其中SOFARegistry比較有意思，它提出了一種連線敏感的長連線，乍一看以為用了什麼黑科技，後來看了程式碼發現就是TCP連線加應用層的心跳檢測，這些被他們封裝在SOFABolt通訊框架中。
參考《海量資料下的註冊中心 - SOFARegistry 架構介紹》https://mp.weixin.qq.com/s/mZo7Dg6gfNqXoetaqgwMww
但這個方式也有一個明顯的缺點，如果網路狀況不好的情況下，TCP連線比較容易斷開，會導致節點頻繁上下線。
註冊中心主動探測
除了上述的方式，還有一種註冊中心（甚至是一個單獨的元件）主動探測Provider的方式，與Consumer主動探測類似，只不過把探測任務移交給了註冊中心或一個單獨的元件。
主動探測有個最大的優勢是可以擴充套件非常豐富的探測方式，比如最常見的探測埠是否存活，又或者探測Provider的一個http介面返回是否符合預期，甚至可以擴充套件為MySQL、Redis等等協議的探測。
這也是種能解決服務假死的探活方式，Nacos中的永久例項探活就是採用的這種方式。
但這種方式在實際使用的時候要考慮主動探測元件的高可用，高可用就得存在副本，可採取主備方式。
如果單機存在效能瓶頸，還得分散式探活，主備可能就不適合，得有一個分散式協調者，這要說又得長篇大論。但這裡你知道有這麼個事兒就可以了。
考量探活的指標有三個：
- 能不能探出來？——功能性
- 什麼時候探出來？——時效性
- 會不會探錯了？——穩定性
功能上最強的是帶語義的主動探測，時效性最強的要屬長連線會話保持。
穩定性不好說誰強誰弱，但一般會給一個叢集設定一個探活摘除的比例，比如最多摘除50%機器，防止探活錯誤導致節點全部下線，這也算是一種兜底策略吧。
搜尋關注微信公眾號"捉蟲大師"，回覆關鍵字「Nacos」送你一本《Nacos架構與原理》電子書，Dubbo資料也在準備中，不想錯過可以點個關注。