幾個月前，我在《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資料也在准備中，不想錯過可以點個關注。