服務治理的一個重要任務是感知服務節點變更，完成服務自動注冊及異常節點的自動摘除。這就需要服務治理平臺能夠：及時、準確的感知service節點的健康狀況。
Nginx 提供了三種HTTP服務健康檢查方案供用戶選擇：
- TCP層默認檢查方案：定時與后端服務建立一條tcp連接，鏈接建立成功則認為服務節點是健康的。
- HTTP層默認檢查方案：TCP層檢查有一定的局限性：
- 很多HTTP服務是帶狀態的，端口處于listen狀態并不能代表服務已經完成預熱；
- 不能真實反映服務內部處理邏輯是否產生擁堵。
- 這時可以選擇http層健康檢查，會向服務發送一個http請求GET / HTTP/1.0rnrn，返回狀態是2xx或3xx時認為后端服務正常。
- 自定義方案：可根據下文描述自定義檢查方案。
配置參數詳解
一個常用的健康檢查配置如下：
check fall=3 interval=3000 rise=2 timeout=2000 type=http;
check_http_expect_alive http_2xx http_3xx ;check_http_send "GET /checkAlive HTTP/1.0rnrn" ;
下面針對每個配置參數，進行詳細介紹。
check：
check 字段參數如下：
Syntax: check interval=milliseconds [fall=count] [rise=count] [timeout=milliseconds] [default_down=true|false] [type=tcp|http|ssl_hello|MySQL|ajp] [port=check_port]
Default: 如果沒有配置參數，默認值是：interval=30000 fall=5 rise=2 timeout=1000 default_down=true type=tcp
check 字段各個參數含義如下：
- interval：向后端發送的健康檢查包的間隔。
- fall(fall_count): 如果連續失敗次數達到fall_count，服務器就被認為是down。
- rise(rise_count): 如果連續成功次數達到rise_count，服務器就被認為是up。
- timeout: 后端健康請求的超時時間。
- default_down: 設定初始時服務器的狀態，如果是true，就說明默認是down的，如果是false，就是up的。默認值是true，也就是一開始服務器認為是不可用，要等健康檢查包達到一定成功次數以后才會被認為是健康的。
- type：健康檢查包的類型，現在支持以下多種類型
- tcp：簡單的tcp連接，如果連接成功，就說明后端正常。
- ssl_hello：發送一個初始的SSL hello包并接受服務器的SSL hello包。
- http：發送HTTP請求，通過后端的回復包的狀態來判斷后端是否存活。
- mysql: 向mysql服務器連接，通過接收服務器的greeting包來判斷后端是否存活。
- ajp：向后端發送AJP協議的Cping包，通過接收Cpong包來判斷后端是否存活。
- port: 指定后端服務器的檢查端口?？梢灾付ú煌谡鎸嵎盏暮蠖朔掌鞯亩丝?，比如后端提供的是443端口的應用，你可以去檢查80端口的狀態來判斷后端健康狀況。默認是0，表示跟后端server提供真實服務的端口一樣。
check_http_expect_alive：
check_http_expect_alive 指定主動健康檢查時HTTP回復的成功狀態：
Syntax: check_http_expect_alive [ http_2xx | http_3xx | http_4xx | http_5xx ]
Default: http_2xx | http_3xx
check_http_send：
check_http_send 配置http健康檢查包發送的請求內容
為了減少傳輸數據量，推薦采用”HEAD”方法。當采用長連接進行健康檢查時，需在該指令中添加keep-alive請求頭，如：”HEAD / HTTP/1.1rnConnection: keep-alivernrn”。同時，在采用”GET”方法的情況下，請求uri的size不宜過大，確?？梢栽?個interval內傳輸完成，否則會被健康檢查模塊視為后端服務器或網絡異常。
Syntax: check_http_send http_packet
Default: "GET / HTTP/1.0rnrn"
