微服務專題：服務註冊與發現之三Consul健康檢測

簡介

在微服務架構中，微服務會存在多個實例，部署在多臺主機中。由於網絡、主機狀態等諸多因素，單臺主機上的服務出現問題的概率大大增長。這就要求咱們可以監控每臺主機、每一個微服務實例的健康狀態。Consul做爲註冊中心，提供了強大、靈活的健康監測。

快速上手

定義check的位置爲/etc/consul.d/，格式跟定義服務同樣，也是JSON。
下邊咱們定義兩個check，分別爲pingBaidu.json和web.json。內容以下：

{
    "check": {
        "name": "pingBaidu",
        "script": "ping -c1 baidu.com >/dev/null",
        "interval": "30s"
    }
}

{
    "service": {
        "name": "web",
        "tags": [
            "springCloud"
        ],
        "port": 80,
        "check": {
            "script": "curl localhost >/dev/null 2>&1",
            "interval": "10s"
        }
    }
}

pingBaidu的健康檢查，每隔30秒檢查一次。
web的健康檢查，每隔10秒執行一次。

checks有做用域。與服務綁定的check爲應用級，不與服務綁定爲全局。能夠經過給check添加service-id來與服務進行綁定。

定義完成以後，啓動consul：

./consul agent -dev -client 0.0.0.0 -enable-script-checks -config-dir=/etc/consul.d >consul.log &

上圖中，pingBaidu執行成功，而web執行失敗，由於咱們並無這個應用。

詳細介紹

Consul支持五種健康檢測的方式，分別爲：Script+Interval、Http+Interval、TCP + Interval 、Time to Live (TTL)、Docker+ interval。接下來對每種方式進行詳細介紹。

Script+Interval

這種方式中，經過執行外部腳原本進行健康檢測。腳本按照指定時間來進行循環調用（好比30S調用一次）。腳本默認超時時間是30S，能夠經過timeout來指定。

{
  "check": {
    "id": "mem-util",
    "name": "Memory utilization",
    "args": ["/usr/local/bin/check_mem.py", "-limit", "256MB"],
    "interval": "10s",
    "timeout": "1s"
  }
}

Http+Interval

這種檢查將按照預設的時間間隔建立一個HTTP GET請求。HTTP響應代碼來標識服務所處狀態：任何2xx代碼視爲正常，429表示警告——有不少請求；其餘值表示失敗。Http默認的超時時間爲Interval中指定的時間，最大時間爲10秒。

{
  "check": {
    "id": "api",
    "name": "HTTP API on port 5000",
    "http": "https://localhost:5000/health",
    "tls_skip_verify": false,
    "method": "POST",
    "header": {"x-foo":["bar", "baz"]},
    "interval": "10s",
    "timeout": "1s"
  }
}

TCP + Interval

將按照預設的時間間隔與指定的IP/Hostname和端口建立一個TCP鏈接。服務的狀態依賴於TCP鏈接是否成功——若是鏈接成功，則狀態是「success」；不然狀態是「critical」。若是一個Hostname解析爲一個IPv4和一個IPv6，將嘗試鏈接這兩個地址，第一次鏈接成功則服務狀態是「success」。
若是但願經過這種方式利用外部腳本執行健康檢查，那麼腳本應該採用「netcat」或者簡單的socket操做。
默認狀況下，TCP checks中，請求超時時間等於調用請求的間隔時間，最大10秒。也是能夠自由配置的。

{
  "check": {
    "id": "ssh",
    "name": "SSH TCP on port 22",
    "tcp": "localhost:22",
    "interval": "10s",
    "timeout": "1s"
  }
}

Time to Live (TTL)

這種checks爲給定TTL保留了最後一種狀態，checks的狀態必須經過HTTP接口週期性更新，若是外部接口沒有更新狀態，那麼狀態就會被認定爲不正常。

這種機制，在概念上相似「死人開關」，須要服務週期性彙報健康狀態。好比，一個健康的APP能夠週期性的將狀態put到HTTP端；若是app出問題了，那麼TTL將過時，健康檢查將進入Critical狀態。用來爲給定check更新健康信息的endpoint都是pass endpoint和fail endpoint。（參見agent http endpoint）

TTL checks同時會將其最後已知狀態更新至磁盤，這容許Agent經過重啓後恢復到已知的狀態。經過TTL端上一次check來維持健康狀態的有效性。

{
  "check": {
    "id": "web-app",
    "name": "Web App Status",
    "notes": "Web app does a curl internally every 10 seconds",
    "ttl": "30s"
  }
}

Docker+ interval

這種檢查依賴於調用封裝在docker容器內的外部程序。運行的docker經過docker Exec API來觸發外部應用。

咱們指望，consul Agent用戶訪問Docker HTTP API或UNIX套接字。Consul使用$DOCKER_HOST來肯定Docker
API端點。應用程序將運行，並對在容器內運行的服務執行健康檢查，並返回適當的退出代碼。Check按照指定的時間間隔調用。

若是在同一個host主機上有多重shell，那麼一樣須要配置shell參數。
輸出限制在4K之內，輸出大於4K將截斷。

{
"check": {
    "id": "mem-util",
    "name": "Memory utilization",
    "docker_container_id": "f972c95ebf0e",
    "shell": "/bin/bash",
    "args": ["/usr/local/bin/check_mem.py"],
    "interval": "10s"
  }
}

總結

每種定義中，name是必填的，其餘事選填的，包括id。id在agent範圍內必須是惟一的，若是沒提供id，默認會用name做爲ID。