目录
Consul是HashiCorp公司推出的开源工具，用于实现分布式系统的服务发现与配置
与Docker等轻量级容器可无缝配合
Consul是HashiCorp公司推出的开源工具，consul包含很多组件，但总体来说，consul是用于实现分布
consul可以作为注册中心和配置中心，同时consul与其他注册中心一样，提供了一定的存储能力（存放注册者的信息），同时consul可以对集群中的节点进行监控检查实现故障排除。
1、服务发现：consul提供了通过DNS或者http接口的方式来注册服务和发现服务。一些外部的服务通过consul很容易的找到它所依赖的服务。
2、健康检查：consul的client提供健康检查机制，可以用来避免流量被转发到有故障的节点上。
3、KV存储：应用程序可以根据自己的需要使用consul提供key/value存储。consul提供了简单易用的http接口，结合其他工具可以实现动态配置、功能标记、leader选举等。
4、多数据中心：consul提供了多数据中心机制。这样就可以不用再创建多用的虚拟层来应用多个分区。
5、安全服务通信：consul可以为服务生成和分发TLS证书已建立相互TLS连接。Intentions可以用于定义允许通信的服务。可以通过实时更改的instentions来管理服务隔离，而不需复杂的网络拓扑和静态防火墙策略。
6、提供web的UI界面。
总结：consul是分布式的、高可用的一个服务管理工具，使用go语言编写，所以可移植性高，使用raft保证数分布式数据一致性及服务的高可用。consul内置了服务注和发现、分布一致性协议实现（采用raft算法）、健康检查、KV存储、多数据中心方案以及服务之间的安全通信。每个consul服务提供节点，都运行一个consul agent（代理），consul agent并不意味着必须发现其它的服务，或者进行相应的数据操作，代理只需要对健康检查负责。代理连接一个或者多个consul服务端，consul服务端存储，复制数据，选取leader。虽然consul服务端可以单例运行，但是通过建议部署3到5个实例集群运行，以防止数据丢失，同时保证server-leader的选择能够正确的进行。
Raft算法属于Multi-Paxos算法，它是在Multi-Paxos思想的基础上，做了一些简化和限制，比如增加了日志必须是连续的，只支持领导者、跟随者和候选人三种状态，在理解和算法实现上都相对容易许多。从本质上说，Raft算法是通过一切以领导者为准的方式，实现一系列值的共识和各节点日志的一致。
现在比较流行的也就是Consul和Nacos，这两个注册中心我做的项目当中都涉及到了，Zookeeper没有管理界面，一般不建议使用，而Eureka已经处于停更，并且本身就存在很多bug，一般不建议使用！
应用程序可以轻松找到它们所依赖的服务。服务发现组件也可以使用此信息将通信流量路由到远离不健康主机的地方，支持多种方式,HTTP, TCP、 Docker, Shell脚本定制化监控。动态配置、特性标记、协调、leader选举等等。简单的HTTP API使其易于使用。可以使用意图来定义允许哪些服务进行通信。可以很容易地管理服务细分，目的可以实时更改，而不是使用复杂的网络拓扑和静态防火墙规则。Consul的应用场景包括服务发现、服务隔离、服务配置：
① 服务发现场景中consul作为注册中心，服务地址被注册到consul中以后，可以使用consul提供的dns、http接口查询，consul支持health check。
② 服务隔离场景中consul支持以服务为单位设置访问策略，能同时支持经典的平台和新兴的平台，支持tls证书分发，service-to-service加密。
③ 服务配置场景中consul提供key-value数据存储功能，并且能将变动迅速地通知出去，借助Consul可以实现配置共享，需要读取配置的服务可以从Consul中读取到准确的配置信息。
④ Consul可以帮助系统管理者更清晰的了解复杂系统内部的系统架构，运维人员可以将Consul看成一种监控软件，也可以看成一种资产（资源）管理系统。
Consul Cluster（集群）有Server 和Client两种角色。不管是Server还是Client,统称为Agent（代理）。
Consul Client 是相对无状态的，只负责转发RPC到Server资源开销很少。Server是一个有一组扩展功能的代理，这些功能包括参与Raft选举、维护集群状态、响应RPC查询、与其他数据中心交互WAN Gossip和转发查询给leader或者远程数据中心。每个数据中心，Client和Server是混合的。一股建议有3~5台Server，这是基于有故障情况下的可用性和性能之间的权衡结果，因为越多的机器加入达成共识越慢（server越多追求一致性的时候 必定会消耗一定的时间来进行同步数据，同步数据的过程就会导致服务短时间内不能访问），Server之间会选举出一个Leader，然而并不限制Client的数量，一般建议一个服务对应一个Client，它们可以很容易的扩展到数千或者数万台。在开发时我们绑定一组服务注册中心中的客户端即可。
为什么集群要搭建奇数？
zookeeper的集群同样会面临这个问题，集群一般都是只要坏掉一半服务整个集群就不可用，3和4都是坏掉两台就不可用 所以一般会选三台。
建立Consul服务
每个提供服务的节点上都要部署和运行Consul的agent
Consul agent有两种运行模式
Server
Client
Server和Client只是Consul集群层面的区分，与搭建在Cluster之上的应用服务无关
mkdir /mnt/consul #创建目录
cd /mnt/consul
consul_0.9.2_linux_amd64.zip #上传安装包
unzip consul_0.9.2_linux_amd64.zip #解压
mv consul /usr/bin #将解压的文件移动到环境变量consul agent \ #初始化
-server \
-bootstrap \
-ui \ #ui界面
-data-dir=/var/lib/consul-data \ #数据存储位置
-bind=192.168.187.108 \ #绑定地址
-client=0.0.0.0 \ #监听所有地址
-node=consul-server01 &> /var/log/consul.log & #后台运行
consul members #插入集群成员
consul info | grep leader #查看leader信息
| 查看集群server成员 | curl 127.0.0.1:8500/v1/status/peers |
| 集群Raf leader | curl 127.0.0.1:8500/v1/status/leader |
| 注册的所有服务 | curl 127.0.0.1:8500/v1/catalog/services |
| 查看nginx服务信息 | curl 127.0.0.1:8500/v1/catalog/nginx |
| 集群节点详细信息 | curl 127.0.0.1:8500/v1/catalog/nodes |
#容器服务自动加入nginx集群
1、安装Gliderlabs/Registrator Gliderlabs/Registrator
可检查容器运行状态自动注册，还可注销docker容器的服务 到服务配置中心
目前支持Consul、Etcd和SkyDNS2
#在192.168.187.108节点上，执行以下操作
docker run -d \
--name=registrator \
--net=host \
-v /var/run/docker.sock:/tmp/docker.sock \
--restart=always \
gliderlabs/registrator:latest \
-ip=192.168.187.118 \
consul://192.168.187.108:8500
systemctl restart docker
docker run -itd -p:81:80 --name test-01 -h test01 nginx
docker run -itd -p:82:80 --name test-02 -h test02 nginx
docker run -itd -p:83:80 --name test-03 -h test03 httpd
docker run -itd -p:84:80 --name test-04 -h test04 httpd
本机访问http://192.168.187.108:8500
此时应该可以发现5个服务
Consul-Template是一个守护进程，用于实时查询Consul集群信息，并更新文件系统上任意数量的指定模板，生成配置文件，更新完成以后，可以查询Consul中的服务目录，Key、Key-values等。
##在consul上操作
vim /mnt/consul/nginx.ctmpl
upstream http_backend {
{{range service "nginx"}}
server {{.Address}}:{{.Port}}; #此处引用的变量会指向后端的地址和端口（动态变化）
{{end}}
}
server {
listen 100; #监听端口
server_name localhost 192.168.187.108; #反向代理的IP地址(前端展示的NG服务的IP)
access_log /var/log/nginx/gg.com-access.log;
index index.html index.php;
location / {
proxy_set_header HOST $host;
proxy_set_header X-Real-IP $remote_addr; #后端真实IP
proxy_set_header Client-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; #转发地址
proxy_pass http://http_backend; #反向代理调用
}
}
由于之前安装好nginx服务，所以不需要再次安装
yum install gcc pcre-devel zlib-devel -y
tar zxvf nginx-1.22.0.tar.gz -C /opt
./configure --prefix=/usr/local/nginx
make && make install
ln -s /usr/local/nginx/sbin/nginx /usr/local/sbin
配置nginx服务的文件
vim /usr/local/nginx/conf/nginx.conf
在http模块下插入include vhost/*.conf; #添加虚拟主机目录（consul动态生成的配置文件就会放在这里）
##创建虚拟主机目录
mkdir /usr/local/nginx/conf/vhost
##创建日志文件目录
mkdir /var/log/nginx
##启动nginx
usr/local/nginx/sbin/nginx 或者 systemctl restart nginx.service
cd /mnt/consul
上传 consul-template_0.19.3_linux_amd64.zip
unzip consul-template_0.19.3_linux_amd64.zip #解压
mv consul-template /usr/bin/
##关联nginx 虚拟目录中的子配置文件操作 #启动日志监控
consul-template -consul-addr 192.168.187.108:8500 \
-template "/mnt/consul/nginx.ctmpl:/usr/local/nginx/conf/vhost/gg.conf:/usr/local/nginx/sbin/nginx -s reload" \
--log-level=info
再打开另一个终端
cat /usr/local/nginx/conf/vhost/gg.conf
增加一个 nginx 容器节点，测试服务发现及配置更新功能
//在registrator服务端注册
docker run -itd -p 85:80 --name test-05 -h test05 nginx
浏览器访问查看新添加的内容
是否可以完成代理访问轮询
浏览器访问192.168.187.108:100 多次刷新产生日志
在client端查看日志信息
docker logs -f test-01
docker logs -f test-02
docker logs -f test-05
#注意需要启动日志监控
consul-template -consul-addr 192.168.187.108:8500 \
-template "/mnt/consul/nginx.ctmpl:/usr/local/nginx/conf/vhost/gg.conf:/usr/local/nginx/sbin/nginx -s reload" \
--log-level=info
