Caddy 實戰（七）- 反向代理中的健康檢查

在上一篇文章中，我講解了反向代理中的負載均衡，一個上游主機要想被使用到的前提：就是該主機必須可用？那麼怎麼纔算可用呢？這涉及到 Caddy 的健康檢查，和 Nginx 的類似。

什麼是健康檢查

比如我們做體驗，其實就是對我們自己身體做一個健康檢查，判斷身體是否健康。那麼對於我們的上游主機服務，其實也一樣，只要做了健康檢查，才能知道這個上游是否健康，是否可用。

健康檢查根據方式不同，又分爲主動健康檢查和被動健康，同樣的 Caddy 也支持這兩種檢查方式，下面就先爲你介紹主動健康檢查。

主動健康檢查

主動，從字面上看，是主動發起的，所以主動健康檢查，也就是 Caddy 主動發起的對上游主機服務的健康檢查，它的 Caddyfile 配置格式如下所示：

reverse_proxy [<matcher>] [<upstreams...>] {
    # backends
    to <upstreams...>
    ...
    # active health checking
    health_uri      <uri>
    health_port     <port>
    health_interval <interval>
    health_timeout  <duration>
    health_status   <status>
    health_body     <regexp>
    health_headers {
        <field> [<values...>]
    }
}

  1. health_uri ：設置 Caddy 主動發起健康檢查的 URI，可以有 path 和 query 查詢參數

  2. health_port ：設置健康檢查 URL 的端口，如果和上游主機端口一樣，就不用單獨設置，一般不設置。

  3. health_interval ：主動健康檢查的週期，也就是多久發起一次主動健康檢查，默認是 30 秒。

  4. health_timeout ：檢查的超時時間，如果返回的響應超過這個值就認爲是不健康的，默認是 5 秒。

  5. health_status ：對於一個健康的上游服務，預期的狀態碼，可以是一個三位數的值，也可以使用 2xx 這種寫法，默認是 200 , 當然你寫成 2xx 也可以，這樣返回 204 也被認爲是健康的。

  6. health_body : 和 health_status 差不多，只不過它是返回的內容，如果匹配，則認爲是健康的，否則則認爲不健康。

  7. health_headers ：這個主要用於設置發起健康檢查請求頭的頭信息，比如需要鑑權的信息等。

下面通過一個例子，來看下主動健康檢查的使用：

reverse_proxy /api/* node1:80 node2:80 node3:80 {
    health_uri /health?ready=1
    health_status 2xx
    health_interval 20s
    health_timeout 3s
}

以上設置後，每隔 20s Caddy 就會向每個 upstream 的 /health?ready=1 發起一次健康檢查的請求，只要該 URI 返回的 HTTP Status Code 爲 2 開頭的，那麼就認爲是該 upstream 是健康的。

被動健康檢查

有主動就有被動，從上面的文章我們可以看到，主動檢查是 Caddy 定時主動發起的，不受其他因素限制，但是被動檢查就不一樣了，被動檢查只有在 Caddy 接收到用戶請求時，纔會對上游（後端）主機進行檢查探測，這就是 Caddy 的被動健康檢查。

和主動健康檢查一樣，Caddy 的被動檢查也有幾個設置：

reverse_proxy [<matcher>] [<upstreams...>] {
    # backends
    to <upstreams...>
    ...
    # passive health checking
    fail_duration     <duration>
    max_fails         <num>
    unhealthy_status  <status>
    unhealthy_latency <duration>
    unhealthy_request_count <num>
}

  1. fail_duration : 這是一個時間區間，它表示記錄一次失敗的請求多久，什麼意思呢？當一次失敗的請求後，caddy 會把失敗計數器 + 1，在過了fail_duration 時間後，會把失敗計數器 - 1，也就是恢復了。所以就是請求失敗了沒事，過了fail_duration 時間後，就認爲你這次失敗又恢復正常了。

  2. max_fails ：這個是允許最大失敗的次數，如果經常失敗，通過fail_duration 減的次數，趕不上失敗增加的次數，導致失敗次數達到了max_fails , 那麼 Caddy 就會認爲你的上游（後端）主機不可用。

  3. unhealthy_status ：設置一個狀態碼, 比如 404 或者 5xx 都行，如果上游返回的狀態是unhealthy_status , 那麼 Caddy 就認爲這次訪問失敗，失敗計數器會 + 1（fail_duration 時間後會 - 1），一直到max_fails 會認爲該上游主機不可用。

  4. unhealthy_latency : 這也是一個時間，它表示上游主機的相應時間如果超過unhealthy_latency 這個值，失敗計數器也會 + 1，一直到max_fails 會認爲該上游主機不可用。

  5. unhealthy_request_count : 這個其實用來設置上游主機允許的最大請求數，如果請求數超過這個值，那麼 Caddy 就會認爲該上游主機不可用。

    從以上每個配置的解釋說明，相信你已經瞭解了 Caddy 的被動檢查，它其實非常簡單，就這麼幾個配置，並且是根據接收到的請求觸發的（非 Caddy 自己主動），所以叫做被動檢查。

這裏需要注意的是，只有當fail_duration 的值大於 0，Caddy 才啓動被動檢查。

小結

這篇主要介紹 Caddy 的健康檢查，從機制上了解它的運作，這對於我們更好的配置 Caddy 可以提供很大的幫助。

其實 Caddy 的思路不止可以用於 Caddy，也可以用於你自己的代碼開發中，比如你調用其他的微服務，也可以採用這裏面的思路，做更好的優化，讓你的程序更健壯。

本文爲原創文章，轉載註明出處, 歡迎掃碼關注公衆號flysnow_org或者網站 https://www.flysnow.org/ ，第一時間看後續精彩文章。覺得好的話，請猛擊文章右下角「在看」，感謝支持。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/1yDIu5dRYa1EBBwhGDI-PQ

猜你喜歡