服務注冊 - 服務進程在注冊中心注冊自己的位置。它通常注冊自己的主機和端口號，有時還有身份驗證信息，協議，版本號，以及運行環境的詳細資料。
服務發現 - 客戶端應用進程向注冊中心發起查詢，來獲取服務的位置。服務發現的一個重要作用就是提供一個可用的服務列表。
服務定義的格式類似如下：
{
"service":{
"id": "jetty",
"name": "jetty",
"address": "192.168.1.200",
"port": 8080,
"tags": ["dev"],
"checks": [
{
"http": "http://192.168.1.200:8080/health",
"interval": "5s"
}
]
}
}
其中，check是用來做服務的健康檢查的，可以有多個，也可以沒有，支持多種方式的檢查。check定義在配置文件中，或運行時通過HTTP接口添加。Check是通過HTTP與節點保持一致。
有五種check方法：
check必須是script或者TTL類型的，如果是script類型，則script和interval變量必須被提供，如果是TTL類型，則ttl變量必須被提供
script是consul主動去檢查服務的健康狀況，ttl是服務主動向consul報告自己的健康狀況。
以下是幾種配置方式
Check必須是Script、HTTP、TCP、TTL四種類型中的一種。Script類型需要提供Script腳本和interval變量。HTTP類型必須提供http和Interval字段。TCP類型需要提供tcp和Interval字段，TTL類型秩序提供ttl。Check的name字段是自動通過service:<service-id>生成，如果有多個service，則由service:<service-id>:<num>生成。
Script check（Script+ Interval）
通過執行外部應用進行健康檢查：這種外部程序具有退出代碼，並可能產生一些輸出；腳本按照指預置時間間隔來調用（比如，每30秒調用一次），類似於Nagios插件系統，腳本輸出限制在4K以內，輸出大於4K將截斷。默認情況下，腳本超時時間為30秒——可通過timeout來配置。
{
"check": {
"id": "mem-util",
"name": "Memory utilization",
"script": "/usr/local/bin/check_mem.py",
"interval": "10s",
"timeout": "1s"
}
}
HTTP check（HTTP+ Interval）
這種檢查將按照預設的時間間隔創建一個HTTP “get”請求。HTTP響應代碼來標示服務所處狀態：任何2xx代碼視為正常，429表示警告——有很多請求；其他值表示失敗。
這種類型的檢查應使用curl或外部程序來處理HTTP操作。默認情況下，HTTP Checks中，請求超時時間等於調用請求的間隔時間，最大10秒。有可能使用客制的HTTP check，可以自由配置timeout時間，輸出限制在4K以內，輸出大於4K將截斷。
{
"check": {
"id": "api",
"name": "HTTP API on port 5000",
"http": "http://localhost:5000/health",
"interval": "10s",
"timeout": "1s"
}
}
TCP check(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"
}
}
TTL check:（Timeto Live生存時間）
這種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": "Memoryutilization",
"docker_container_id": "f972c95ebf0e",
"shell": "/bin/bash",
"script": "/usr/local/bin/check_mem.py",
"interval": "10s"
}
}
小結
每一種check都必須包含name，id和notes兩個是可選的。如果沒有提供id，那么id會被設置為name。在一個節點中，check的ID都必須是唯一的。如果名字是沖突的，那么ID就應該設置。
字段Notes主要是增強checks的可讀性。Script check中，notes字段可以由腳本生成。同樣，適用HTTP接口更新TTL check的外部程序一樣可以設置notes字段。
Check腳本
Check腳本可以自由地做任何事情確定check的狀態。唯一的限制是：退出代碼必須遵循下面的約定：
- 退出代碼0 – 正常
- 退出代碼1 – 告警
- 其他值 - 失敗。
Consul依賴此約定。腳本其他的輸出都保存在notes字段中，可以供人查看。
健康狀態初始化
默認情況下，當checks注冊到Consul agent時，健康狀態立即被設置為“Critical”。可以防止服務直接被注冊為通過（“passing”）狀態，在進入service pool前認為是健康狀態。在某些情況下，checks可能需要指定健康檢查的初始狀態，可以通過設置“status”字段來實現。
如下：
{
"check": {
"id": "mem",
"script": "/bin/check_mem",
"interval": "10s",
"status": "passing"
}
}
初始狀態設置為passing。
Service-boundchecks
健康檢查（Health checks）或者有可能綁定到指定的服務。這將確保健康檢查的狀態只會影響給定的服務而不是整個節點。服務綁定健康檢查需要提供一個service_id字段。
{
"check": {
"id": "web-app",
"name": "WebApp Status",
"service_id": "web-app",
"ttl": "30s"
}
}
在上述示例中，web-app健康檢查如果失敗了，只會影響web-app服務的有效性，本節點的其他服務是不受影響的。
MultipleCheck Definitions
多個check定義，可以使用字段“checks”，示例：
{
"checks": [
{
"id": "chk1",
"name": "mem",
"script": "/bin/check_mem",
"interval": "5s"
},
{
"id": "chk2",
"name": "/health",
"http": "http://localhost:5000/health",
"interval": "15s"
},
{
"id": "chk3",
"name": "cpu",
"script": "/bin/check_cpu",
"interval": "10s"
},
...
]
}
注，實踐過程中發現，腳本並不支持python，必須為shell腳本