Consul教程
Consul是微服务架构中，解决服务发现、配置中心的分布式中间件。
特性
-
服务发现： 解决在分布式环境中，如何找到可用的服务地址的问题，支持通过DNS和HTTP查询服务地址。
-
健康检查： 定时监控服务是否正常，对于异常的服务会主动下线。
-
键值存储： 配置中心解决方案，是一种key/value存储结构，区别就是key是以目录树结构形式组织的，可以用来存储系统配置信息。
-
多数据中心： 支持多数据中心部署。
架构
consul是分布式、高可用的系统，下图是单数据中心的部署架构。
说明：
consul主要有server和client两种组件组成。
server负责核心数据的存储和处理请求，server可以部署多个实例（通常推荐3-5个），server只有一个实例是leader实例，就是主节点，主节点是自动选举产生的，主节点负责处理数据的写入处理，同时将数据同步至其他server节点。
client负责跟server通信，处理转发服务注册、服务发现请求到server节点，client还负责服务的健康检查，client节点也可以部署多个实例，甚至每个微服务节点都部署一个client实例。
多数据中心架构看下面官网给出的截图：
Consul安装与部署
Consul安装比较友好，安装包解压缩后只有一个执行程序consul。
下载安装包
官网安装包下载地址：
https://www.consul.io/downloads.html
根据自己的操作系统类型，选择对应的安装包下载即可。
教程以linux为例。
将下载的安装包，解压缩到自己喜欢的目录，例如：
# 创建consul安装目录
mkdir -p ~/local/consul
# 例如，我们下载的压缩包是 consul_xxx_linux_amd64.zip
# 将压缩包内容，解压缩到~/local/consul目录
unzip -o -d ~/local/consul consul_xxx_linux_amd64.zip
为了方便搜索到命令，将~/local/consul添加到PATH环境变量中。
提示：windows系统的安装类似，下载windows版本的安装包，解压缩就得到consul程序了，同样为方便命令行工具可以找到consul命令，把你的consul安装目录，添加到windows的PATH环境变量中。
打开终端输入下面命令，如果没有提示找不到命令，就说明安装成功了。
consul
输出类似内容：
usage: consul [--version] [--help] <command> [<args>]
Available commands are:
agent Runs a Consul agent
event Fire a new event
...
consul命令介绍
通过前面，consul架构章节说明，我们知道consul主要分server和client两个组件，server负责核心数据的存储和处理数据的读写，通过client可以操作server提供的接口。
consul将server和client两个组件的实现都融合在一个叫consul的命令程序中，所以我们安装consul后，只有一个consul命令。
在consul中，无论server还是client都叫做agent，通过命令参数区分，我们运行的是server还是client。
提示：默认情况下运行的是client，下面章节会介绍如何启动server和client。
Consul默认地址
Consul部署好以后，默认对外提供接口的地址是：127.0.0.1:8500 或者 consul agent ip地址 + 8500端口号。
单机部署开发模式
作为本地开发环境，我们没有必要配置consul集群，只要一条命令就可以，以开发模式启动consul服务。
例如：
consul agent -dev
-dev参数的意思，就是以开发模式启动consul，同时具备server和client的功能，不需要单独部署server和client。
启动后得到类似的输出：
==> Starting Consul agent...
Version: 'v1.6.1'
Node ID: '9a8474ac-fd30-36d4-bb6f-e1a4960ab3d3'
Node name: 'tizidembp'
Datacenter: 'dc1' (Segment: '<all>')
Server: true (Bootstrap: false)
Client Addr: [127.0.0.1] (HTTP: 8500, HTTPS: -1, gRPC: 8502, DNS: 8600)
Cluster Addr: 127.0.0.1 (LAN: 8301, WAN: 8302)
Encrypt: Gossip: false, TLS-Outgoing: false, TLS-Incoming: false, Auto-Encrypt-TLS: false
.....
提示：如果本地开发，只要启动开发模式即可，当然不能关闭命令窗口，否则就退出了，你可以使用consul agent -dev & 命令，在后台启动consul。
基本命令
查询集群节点
consul members
打印出集群中所有的节点信息，可以通过Status状态查看节点是否正常运行。
输出：
Node Address Status Type Build Protocol DC Segment
tizidembp 127.0.0.1:8301 alive server 1.6.1 2 dc1 <all>
我们只是启动开发模式，只有一个节点。
重新加载配置文件
consul reload
如果我们修改了配置文件，可以使用这个命令，前面单机模式，我们什么配置文件也不需要，以默认参数启动了。
优雅关闭节点
consul leave
优雅的关闭当前机器上的节点，如果你有多个节点，需要每个节点都要执行关闭命令，否则只是关闭机器中的一个节点。
查询所有注册的服务
consul catalog services
生产环境部署
生产环境节点配置，主要分server节点和client节点，至少部署一个server节点，为了高可用，通常建议部署3-5个server节点，client节点任意，client节点数量可以跟我们服务的节点数量一致，每台服务的节点部署一个client。
下图是单数据中心的部署架构:
部署server节点
通过配置文件配置启动server节点。
mkdir /etc/consul.d
# 给目录授权
chown -R consul:consul /etc/consul.d
# 创建server配置文件
touch /etc/consul.d/server.hcl
# 给文件授权
chmod 640 /etc/consul.d/server.hcl
配置文件内容：/etc/consul.d/server.hcl
datacenter = "dc1"
data_dir = "/opt/consul"
encrypt = "Luj2FZWwlt8475wD1WtwUQ=="
server = true
bootstrap_expect = 3
retry_join = ["172.16.0.11"]
参数说明：
-
datacenter - 数据中心名字，唯一
-
data_dir - 数据目录，有权限读写即可
-
encrypt - consul节点之间通信的密钥
-
server - 代表当前agent以服务端模式启动
-
bootstrap_expect - 代表需要部署3个server节点。
-
retry_join - 其他server节点地址(支持ip地址、域名)，填一个即可，会自动加入集群。
提示：启动第一个server节点的时候，不需要配置retry_join参数，因为自己是目前唯一的server节点，没有其他server节点。
启动server命令：
~/local/consul/consul agent -config-dir=/etc/consul.d/
参数说明:
-
-config-dir - 指定配置文件所在目录
注意你安装consul的目录，可能跟这里不一样，输入正确的安装路径。
提示：为了方便开机自动启动consul，你可以根据不同版本的linux系统配置开机启动，例如:centos，配置systemd。
部署client节点
client节点的配置，跟server节点类似，就是少了一些参数。
例子:
mkdir /etc/consul.d
# 给目录授权
chown -R consul:consul /etc/consul.d
# 创建client配置文件
touch /etc/consul.d/client.hcl
# 给文件授权
chmod 640 /etc/consul.d/client.hcl
配置文件内容：/etc/consul.d/client.hcl
datacenter = "dc1"
data_dir = "/opt/consul"
encrypt = "Luj2FZWwlt8475wD1WtwUQ=="
retry_join = ["172.16.0.11"]
参数说明：
-
datacenter - 数据中心名字，唯一
-
data_dir - 数据目录，有权限读写即可
-
encrypt - consul节点之间通信的密钥
-
retry_join - 其他server节点地址，填一个即可，会自动加入集群。
跟server的参数对比，主要就是少了server和bootstrap_expect参数。
启动client的命令跟server一模一样。
~/local/consul/consul agent -config-dir=/etc/consul.d/
Consul服务注册
consul支持两种方式注册服务信息，使用配置文件或者http接口注册服务。
使用配置文件注册服务
基于配置文件的服务注册方式，是consul官方推荐的方式，因为这种方式对我们微服务应用无侵入，就是不需要写代码调consul的接口注册服务信息。
1.定义一个服务
首先定义一个存放consul配置文件的目录，例如：/etc/consul.d
# 首先创建一个配置文件目录, 确保consul命令有权限访问这个目录即可
mkdir /etc/consul.d
为方便管理，我们通常一个微服务定义一个配置文件，服务定义配置文件是json格式。
例如：定义一个名字叫web的服务。
文件：/etc/consul.d/web.json
{
"service": {
"name": "web",
"tags": ["rails"],
"port": 80
}
}
服务配置文件名，可以随便取，通常以服务名命名。
配置文件参数说明：
-
name - 服务名
-
tags - 可以为服务打上标签，是个字符串数组，查询服务的时候可以用来过滤
-
port - 服务的端口
-
address - 服务的ip地址，可选，一般不用填写，注册的时候agent会加上。
2.注册服务
本地开发模式，启动consul的时候，通过config-dir参数指定配置文件目录，就会自动注册配置文件目录下的所有服务。
# 以开发模式启动consul
consul agent -dev -config-dir=/etc/consul.d/
如果你的consul agent已经启动，并且启动的时候已经通过参数config-dir指定了同样的配置目录，只要执行下面命令，重新加载配置文件即可注册服务。
# 重新加载配置
consul reload
提示： 生产环境部署的时候，我通常一台机器就部署一个微服务实例，只要在这台机器上部署一个consul的client，机器启动的时候，自动启动consul client根据配置文件自动注册一个服务
3.查询注册的服务
通过下面命令查询，当前注册的所有服务，会发现web服务已经注册成功。
consul catalog services
输出：
consul
web
其他的服务发现功能，下个章节会详细讲解。
4.反注册
就是删除注册的服务，输入下面命令，会删除注册的服务信息，同时删掉本地的服务的配置文件。
consul services deregister -id=web
参数说明：
-
id - 服务名
使用接口注册服务
通过http接口注册服务，一般不推荐，毕竟还需要在写代码实现服务注册的逻辑，还不如配置文件方便，如果你想通过api注册，可以参考官方服务注册api接口文档：https://www.consul.io/api/catalog.html
提示：目前版本Http接口默认端口是8500, 例如注册服务的地址：http://localhost:8500/v1/catalog/register
Consul 服务查询
Consul支持两种接口查询我们注册的服务信息，http api或者DNS查询。
通过http接口查询
1.查询指定的服务
api格式:
http://localhost:8500/v1/catalog/service/服务名
例子:
查询web服务的所有地址信息
curl http://localhost:8500/v1/catalog/service/web
返回:
[
{
"ID": "f9f81742-421d-a102-93ea-fb9c04d2f66d",
"Node": "jogindembp", // 节点机器名字
"Address": "127.0.0.1", // 服务地址
"Datacenter": "dc1", // 数据中心名字
....忽略...
"ServiceKind": "",
"ServiceID": "web",
"ServiceName": "web", // 服务名
"ServiceTags": [
"rails"
],
...忽略...
"ServicePort": 80, // 服务端口
}
]
上面例子返回的结果是没有健康检查的结果，不知道服务地址是否可用。
2.仅查询可用的服务地址
下面查询服务信息，仅返回可用的服务信息，这个需要配合健康检查功能使用，后续有专门的章节介绍健康检查。
api格式：
http://localhost:8500/v1/health/service/服务名?passing
在Url后面增加一个passing参数代表，查询可用的服务地址。
例子：
查询web服务，可用的服务信息。
curl 'http://localhost:8500/v1/health/service/web?passing'
返回结果：
[
{
"Node": {
"Address": "127.0.0.1", // 节点地址
"Datacenter": "dc1",
..忽略...
},
"Service": { // 服务信息
"ID": "web",
"Service": "web",
"Tags": [
"rails"
],
"Address": "", // 服务地址，没有配置，取上面的节点地址
"Port": 80, // 服务端口号
...忽略...
},
"Checks": [ // 健康检查结果，可以配置多种健康检查，所以可能会存在多个结果
{
"CheckID": "api", // 定义的检查id
"Status": "passing", //passing代表可用, warning 代表警告, critical 代表不可用.
..忽略....
}
]
}
]
3.查询注册中心的服务目录
通过这个接口，我们可以查询consul目前注册了那些服务。
api格式：
http://localhost:8500/v1/catalog/services
例子:
请求api后，返回当前注册中心，注册的所有服务清单。
{
"consul": [],
"web": [
"rails"
]
}
目前注册中心，只有两个服务web和consul
通过DNS查询
consul支持通过dns查询服务信息，dns只能返回可用的服务地址。
下面我们通过dig命令，执行dns查询请求。
提示：macos系统默认自带了dig命令，其他系统可以网上找一下安装dig命令。
例子：
查询web服务的地址。
dig @127.0.0.1 -p 8600 web.service.consul
参数说明:
-
@127.0.0.1 - 指定dns服务器地址，就是我们consul的agent地址，本地安装了agent使用127.0.0.1即可
-
p - 指定dns服务的端口，consul默认使用的是8600
web.service.consul是需要查询的域名。
consul服务的域名规则：
服务名.service.consul
也就是，consul默认会为服务配置本地域名。
下面是执行dig命令后输出的结果：
; <<>> DiG 9.10.6 <<>> @127.0.0.1 -p 8600 web.service.consul
...忽略....
// QUESTION SECTION代表我们的查询请求
// 这里代表查询web.service.consul.这个域名的A记录信息。
;; QUESTION SECTION:
;web.service.consul. IN A
// ANSWER SECTION 代表查询结果，查询不到就是空的
;; ANSWER SECTION:
// 这里查询到一条A记录，ip地址是127.0.0.1
web.service.consul. 0 IN A 127.0.0.1
...忽略...
上面dig命令，默认查询的是DNS的A记录，只能查询到Ip地址，查询不到端口号，我们可以通过查询DNS的SRV记录，获取完整的服务地址（ip和端口号）
例子:
dig @127.0.0.1 -p 8600 web.service.consul SRV
命令，最后面多了一个SRV，代表查询DNS的SRV记录
输出:
查询结果跟之前的命令差不多，下面仅显示关键信息。
...忽略...
;; ANSWER SECTION:
// 80 代表端口号
web.service.consul. 0 IN SRV 1 1 80 jogindembp.node.dc1.consul.
;; ADDITIONAL SECTION:
// 下面是服务的ip地址
jogindembp.node.dc1.consul. 0 IN A 127.0.0.1
jogindembp.node.dc1.consul. 0 IN TXT "consul-network-segment="
...忽略...
提示：我们这里只是通过dig命令演示dns请求，项目中，不会使用dig命令发送dns请求，然后解析dig返回的结果，项目中可以使用dns客户端库，设置下dns服务的地址和端口，直接查询服务的域名即可；如果你的服务是web服务，甚至可以配置本地dns服务器，自动解析consul定义的服务域名。
Consul 服务健康检查
分布式环境下，微服务实例的重启、微服务异常等等，都会导致服务不可用，例如：我们向consul注册了一个web服务，web服务启动了10个实例，现在有3个实例不可用，consul怎么知道那些服务实例不可用？
consul健康检查机制，就是解决上述问题的解决方案，健康检查机制运行在consul client中，会定期的根据服务的健康检查配置，去检测服务是否正常，如果服务异常，就将服务的实例标记为不用，如果恢复了，就标记为可用。
健康检查基本配置格式，是在服务定义配置中，增加checks字段，配置健康检查。
{
"service": {
"name": "web",
"tags": ["rails"],
"port": 80,
"checks" : [
{
...具体的健康检查配置...
}
]
}
}
consul健康检查有多种方式，具体的配置，参考下面。
提示：下面的例子，以一个web服务的配置为例子，介绍健康检查的配置，web服务端口号为80。
1.基于HTTP请求
定时以GET请求方式，请求指定url，http请求返回状态码200表示正常，其他状态代表异常。
例子:
{
"service": {
"name": "web",
"tags": ["rails"],
"port": 80,
"checks": [{
"id": "api", // 健康检查项的id，唯一
"name": "HTTP API on port 5000", // 检查项的名字
"http": "https://localhost:5000/health", // 定期访问的Url,通过这个url请求结果确定服务是否正常
"tls_skip_verify": false, // 关闭tls验证
"method": "POST", // 设置http请求方式，默认是GET
"header": { // 可以自定义请求头，可以不配置
"x-foo": ["bar", "baz"]
},
"interval": "10s", // 定期检查的时间间隔，这里是10秒
"timeout": "1s" // 请求超时时间，1秒
}]
}
}
2.基于tcp请求
基于tcp请求方式，就是定时，向指定的地址，建立tcp连接，连接成功就代表服务正常，否则代表异常。
例子：
{
"service": {
"name": "web",
"tags": ["rails"],
"port": 80,
"checks": [{
"id": "ssh", // 检查项目id
"name": "SSH TCP on port 22", // 检查项名字
"tcp": "localhost:22", // tcp连接地址，ip+port
"interval": "10s", // 定义建立连接的时间间隔是10秒
"timeout": "1s" // 超时时间是1秒
}]
}
}
3.基于grpc请求
如果微服务是基于grpc协议，可以使用grpc协议检测服务是否正常。
例子：
{
"service": {
"name": "web",
"tags": ["rails"],
"port": 80,
"checks": [{
"id": "mem-util", // 检查项目id
"name": "Service health status", // 检查项名字
"grpc": "127.0.0.1:12345", // grpc地址，ip+port
"grpc_use_tls": true,
"interval": "10s" // 10秒检测一次
}]
}
}
4.基于命令
consul支持定期执行一个命令或者脚本，来检测服务是否正常；Consul通过检测命令退出状态判断服务是否正常，命令退出状态0代表正常，其他代表异常。
例如：
通过shell脚本检测服务.
#!/bin/bash
# 执行检测任务
# ...忽略...
# 通过exit命令退出脚本，并返回一个整数值，0代表正常
exit 0
提示：通常linux命令，都遵循这个规则，命令正常执行，程序退出状态都是0，报错的话就是大于0的状态。
例子1：
{
"service": {
"name": "web",
"tags": ["rails"],
"port": 80,
"checks": [{
"id": "mem-util", // 检查项id
"name": "Memory utilization", // 检查项名字
"args": ["/usr/local/bin/check_mem.py", "-limit", "256MB"], // 这里是我们要执行的命令，第一个参数是命令或者脚本名，后面跟着任意个参数
"interval": "10s", // 每10秒执行一次命令
"timeout": "1s" // 命令执行超时时间
}]
}
}
例子2：
{
"service": {
"name": "web",
"tags": ["rails"],
"port": 80,
"checks": [{
"args": ["curl", "localhost"], // 执行curl命令，数组第2到第N个元素，代表命令参数
"interval": "10s" // 每10秒执行一次命令
}]
}
}
为了安全考虑，如果健康检查使用执行命令方式，在启动consul的时候支持下面两种参数：
-
-enable-script-checks 允许通过配置文件和http api注册的服务，执行命令检查健康状态
-
-enable-local-script-checks 禁止通过http api注册的服务，执行命令检查健康状态，只允许通过配置文件注册的服务，执行命令。
建议生产环境使用-enable-local-script-checks参数启动consul agent。
例子：
consul agent -dev -enable-local-script-checks -config-dir=/etc/consul.d
本地测试，增加-dev参数，代表开发模式，生产环境，去掉-dev参数。
因为只有consul的client才会执行健康检查任务，可以在client设置这个参数就可以。
Consul键值存储
consul提供一个键值存储（k/v）数据库，我们使用这个特性，存储我们的应用配置、应用元数据和实现分布式锁。
consul支持命令方式和http api两种方式读写键值数据。
提示：存储的数据key/value都不限制类型，但是不能大于512k。
consul的键（key）是以目录树的形式组织，例如：
/tizi/consul/users
/tizi/consul/conns
/tizi/maxusers
key以这种目录树结构组织，方便我们实现前缀搜索，例如，查询/tizi 为前缀的键值数据。
命令方式
主要通过consul kv的子命令读写数据。
下面介绍通过命令方式读写键值数据
# 更新或者创建键值数据
# key = redis/config/connections
# value = 5
consul kv put redis/config/connections 5
# 读取数据
# key = redis/config/connections
consul kv get redis/config/connections
输出：5
# 查询key的详细信息
# key = redis/config/connections
consul kv get -detailed redis/config/connections
输出：
CreateIndex 802 // 创建数据的版本号
Flags 0
Key redis/config/connections
LockIndex 0 // 用于锁处理的版本号
ModifyIndex 802 // 修改数据的版本号
Session -
Value 5 // key对应的值
# 删除指定Key的数据
# key = redis/config/connections
consul kv delete redis/config/connections
api方式
1.更新/创建
如果Key不存在则创建一个新的，存在则更新数据。
api语法：
http://127.0.0.1:8500/v1/kv/my-key
my-key就是我们的key，更新Key的值需要发送PUT请求。
例子：
curl \
--request PUT \
--data "tizi365.com"\
http://127.0.0.1:8500/v1/kv/tizi365/domain
key = tizi365/domain，value = tizi365.com
2.读取
api语法：
http://127.0.0.1:8500/v1/kv/my-key
查询指定Key的值，发送get请求即可。
例子:
curl "http://127.0.0.1:8500/v1/kv/tizi365/domain"
输出:
[
{
"LockIndex": 0,
"Key": "tizi365/domain",
"Flags": 0,
"Value": "dGl6aTM2NS5jb20=",
"CreateIndex": 842,
"ModifyIndex": 842
}
]
value值是base64编码的，读取的时候需要解码处理。
3.删除
api语法：
http://127.0.0.1:8500/v1/kv/my-key
删除指定的Key, 需要发送DELETE请求。
例子：
curl \
--request DELETE \
http://127.0.0.1:8500/v1/kv/tizi365/domain
4.查询前缀相同的Key有哪些
例子:
查询key前缀为/web/的所有Key, 不返回值。
http://127.0.0.1:8500/v1/kv/web?keys
返回：
[
"/web/bar",
"/web/foo",
"/web/subdir/"
]
5.批量查询前缀相同的key的值
例子：
一次返回，key前缀等于tizi365的所有键值。
curl "http://127.0.0.1:8500/v1/kv/tizi365?recurse=true"
返回：
[
{
"LockIndex": 0,
"Key": "tizi365/domain",
"Flags": 0,
"Value": "dGl6aTM2NS5jb20=",
"CreateIndex": 842,
"ModifyIndex": 842
},
{
"LockIndex": 0,
"Key": "tizi365/title",
"Flags": 0,
"Value": null,
"CreateIndex": 934,
"ModifyIndex": 934
}
]
Consul UI Web后台
Consul自带了一个可视化的后台，我们可以在后台查看注册服务、修改一些配置等等。
1.启动Consul UI
启动UI很简单，只要在启动consul agent的时候加上一个参数即可，但是不需要每个Consul agent节点都需要启动UI，只要一个Consul agent启动UI即可。
consul agent启动ui后，默认地址是：http://localhost:8500/ui/
1.1. 通过命令行参数启动
只要在启动Consul agent的时候, 加上-ui参数即可。
例如：
启动开发模式的agent
consul agent -dev -ui
1.2. 通过配置文件启动
只要在consul的配置文件中添加 ui=true 配置，重启consul agent即可。
如何通过配置文件启动consul agent请参考前面的安装部署章节。
2.查询服务
可以查看当前注册了什么服务、服务的健康状态等等。
3.查询节点
查看consul机器节点的情况
4.管理键值存储
支持查看、创建、编辑键值数据
Consul Watches监控服务变化
当Consul中注册的服务信息发生变化的时候，我们除了定时通过接口去查询最新的服务信息之外，consul还提供了watch机制，通过监控consul数据的变化，主动通知。
目前conusl watch支持两种通知方式：可执行程序和Http接口。
consul watch支持监控的数据类型：
-
services
-
service
-
nodes
-
key
-
keyprefix
也就是说，consul支持监控服务、键值数据、节点信息，只要发生变化，就通知我们。
1.基本用法
我们以监控键值数据的变化为例子，介绍watch机制的用法。
watch监控的配置信息是跟consul的配置文件放在一起的，通过配置文件中的watches字段，设置监控信息。
说明：watches的配置，大致用法就是通过type，配置监控数据的类型，然后根据不同数据类型配置不同的参数，最后选择一种通知方式进行配置。
1.1. 通过可执行程序通知
当我们监控的数据发生变化，consul agent会调用我们配置的可执行程序（命令、脚本等等），并且通过标准输入，以Json格式传入通知的参数， 我们只要在程序中根据参数处理业务即可。
例子：
下面是我们consul agent的配置，文件保存在/etc/consul.d/server.json
提示：我们前面安装部署章节，部署consul集群的时候，consul的配置文件，使用的不是Json格式，实际上consul的配置文件是支持json格式的，字段的含义是一样的，区别就是数据格式换了下。
{
"datacenter": "dc1",
"data_dir": "/Users/jogin/Documents/work/local/consul/data",
"ui": true,
"watches": [{
"type": "key",
"key": "foo/bar/baz",
"handler_type": "script",
"args": ["/usr/bin/my-service-handler.sh", "-redis"]
}]
}
参数说明：
-
datacenter - 数据中心的名字
-
data_dir - consul数据存放目录
-
ui - 开启consul ui
-
watches - 配置监控信息，如果监控的数据发生变化，则根据配置执行通知。
上面这些都是consul的基本配置，具体可以参考安装与部署章节，里面生产环境部署。
watches参数说明：
-
type - 监控的数据类型
-
key - 监控的键值数据的Key
-
handler_type - 通知类型，支持script和http
-
args - 配置通知类型为script的，执行命令，是一个数组，第一个元素是命令，后面第2个到第N个元素是命令的参数。
例子的watches配置的意思就是：
监控key=foo/bar/baz的键值数据，如果数据发生变化，就调用/usr/bin/my-service-handler.sh -redis 命令， 这个命令可以通过标准输入，接收变化的数据。
启动consul，就会加载watches配置。
例如：以开发模式启动
consul agent -config-dir=/etc/consul.d/ -dev
1.2. 通过http接口通知
通过http接口通知数据变化，大体上配置跟上面一样，区别是多了一些http接口的配置参数。
例子：
{
"datacenter": "dc1",
"data_dir": "/Users/jogin/Documents/work/local/consul/data",
"ui": true,
"watches": [{
"type": "key",
"key": "foo/bar/baz",
"handler_type": "http",
"http_handler_config": {
"path": "https://localhost:8000/watch",
"method": "POST",
"header": {
"x-foo": ["bar", "baz"]
},
"timeout": "10s",
"tls_skip_verify": false
}
}]
}
我们关注watches字段的配置信息，下面是参数说明：
-
type - watch监控类型是key
-
key - 监控foo/bar/baz这个key
-
handler_type - 通知类型, http
-
http_handler_config - 配置http通知信息。
http_handler_config参数说明：
-
path - 通知Url
-
method - http请求方法
-
header - 自定义Http请求头，没有可以忽略
-
timeout - 超时时间，10秒
-
tls_skip_verify - 是否跳过tls验证
这个例子的意思，就是当key=foo/bar/baz的键值数据发生变化，就通过https://localhost:8000/watch通知我们。
2.监控服务
上面介绍了watch的基本用法，我们也可以监控服务信息的变化，例如当有人注册新的服务或者服务不可用的时候，通知我们。
我们忽略掉，consul agent的配置，单独看watches的配置。
监控所有的服务的配置
{
"watches": [{
"type": "services",
"handler_type": "http",
"http_handler_config": {
...忽略...
}
}]
}
监控单个服务的配置
{
"watches": [{
"type": "service",
"service": "要监控的服务名",
"handler_type": "http",
"http_handler_config": {
...忽略...
}
}]
}
3.监控键值数据
前面介绍过基本Key的监控，其实我们还可以通过key的前缀，批量监控一批key，只要key的前缀相同，这些Key下面的数据发生变化，都会发送通知。
{
"watches": [{
"type": "keyprefix",
"prefix": "foo/",
"args": ["/usr/bin/my-service-handler.sh", "-redis"]
}]
}
监控类型为：keyprefix
通过prefix字段，配置key的前缀。
这个配置的意思就是：以foo/开头的Key, 数据发生变化，都会执行args参数，配置的命令。
4.监控节点变化
我们也可以监控consul集群节点的变化信息。
{
"watches": [{
"type": "nodes",
"handler_type": "http",
"http_handler_config": {
...忽略...
}
}]
}
