服务发现是分布式应用程序之间管理相互关系的一种机制。允许某个应用程序组件与其他组件交互时，自动找到对方。
Consul是分布式的、高可用的、 可横向扩展的用于实现分布式系统的服务发现与配置。
Consul具有哪些特点?
服务发现（Service Discovery）：Consul提供了通过DNS或者HTTP接口的方式来注册服务和发现服务。一些外部的服务通过Consul很容易的找到它所依赖的服务。
健康检查（Health Checking）：Consul的Client可以提供任意数量的健康检查，既可以与给定的服务相关联(“webserver是否返回200 OK”)，也可以与本地节点相关联(“内存利用率是否低于90%”)。操作员可以使用这些信息来监视集群的健康状况，服务发现组件可以使用这些信息将流量从不健康的主机路由出去。
Key/Value存储：应用程序可以根据自己的需要使用Consul提供的Key/Value存储。 Consul提供了简单易用的HTTP接口，结合其他工具可以实现动态配置、功能标记、领袖选举等等功能。
安全服务通信：Consul可以为服务生成和分发TLS证书，以建立相互的TLS连接。意图可用于定义允许哪些服务通信。服务分割可以很容易地进行管理，其目的是可以实时更改的，而不是使用复杂的网络拓扑和静态防火墙规则。
多数据中心：Consul支持开箱即用的多数据中心. 这意味着用户不需要担心需要建立额外的抽象层让业务扩展到多个区域。
首先，我们可以看到有两个数据中心，分别标记为“1”和“2”。Consul拥有对多个数据中心的一流支持，这是比较常见的情况。
在每个数据中心中，我们都有客户机和服务器。预计将有三到五台服务器。这在故障情况下的可用性和性能之间取得了平衡，因为随着添加更多的机器，一致性会逐渐变慢。但是，客户端的数量没有限制，可以很容易地扩展到数千或数万。
Consul 实现多个数据中心都依赖于gossip protocol协议。这样做有几个目的:首先，不需要使用服务器的地址来配置客户端;服务发现是自动完成的。其次，健康检查故障的工作不是放在服务器上，而是分布式的。这使得故障检测比单纯的心跳模式更具可伸缩性。为节点提供故障检测;如果无法访问代理，则节点可能经历了故障。
每个数据中心中的服务器都是一个筏对等集的一部分。这意味着它们一起工作来选举单个leader，一个被选中的服务器有额外的职责。领导负责处理所有的查询和事务。事务还必须作为协商一致协议的一部分复制到所有对等方。由于这个需求，当非leader服务器接收到RPC请求时，它会将其转发给集群leader。
本节任务：
1.创建Consul服务的Docker镜像
2.构建3台Docker宿主机，并在每一台运行一个Consul。这三台宿主机会提供一个分布式环境，来展现Consul如何处理弹性和失效工作的。
3.构建服务，并将其注册到Consul，然后从其他服务查询该数据。
2.1 构建Consul镜像
Dockerfile
FROMubuntu:18.04
LABELmaintainer="james@example.com"
ENVREFRESHED_AT 2014-08-01
RUNapt-get -qq update
RUNapt-get -qq install curl unzip
ADDhttps://releases.hashicorp.com/consul/0.3.1/consul_0.3.1_linux_amd64.zip /tmp/consul.zip
RUNcd /usr/sbin && unzip /tmp/consul.zip && chmod +x /usr/sbin/consul && rm /tmp/consul.zip
ADDconsul.json /config/
EXPOSE8300 8301 8301/udp 8302 8302/udp 8400 8500 53/udp
VOLUME["/data"]
ENTRYPOINT["/usr/sbin/consul","agent","-config-dir=/config"]
CMD[ ]
端口 用途
53/udp DNS服务器
8300 服务器RPC
8301+udp Serf的LAN端口
8302+udp Serf的WAN端口
8400 RPC接入点
8500 HTTP API
consul.json
{
"data_dir":"/data",
"ui_dir":"/webui",
"client_addr":"0.0.0.0",
"ports": {
"dns":53
},
"recursor":"8.8.8.8"
}
recursor来解析Consul无法解析DNS请求
构建Consul镜像
docker build -t jamtur01/consul .
2.2 在本地测试Consul容器
docker run -p 8500:8500 -p 53:53/udp \
-h node1 jamtur01/consul -server -boostrap
-h 指定节点主机名
-server 指定Consul代理以服务器模式运行
-bootstrap
访问8500端口，发现Consul启动了node1节点，并在本地叫你小领导者选举
2.3 使用docker运行Consul集群
---------------------------------------------------------------------------------------------------------------------
docker pull jamtur01/consul
每台主机 运行Consul镜像的容器
larry主机设置公共ip地址
PUBLIC_IP="$(ifconfig eth0 | awk -F ' *|:' '/inet addr/{print $4}')"
或者手动添加
ifconfig eth0
PUBLIC_IP="IP地址"
echo $PUBLIC_IP
larry 主机 172.18.1.38
moe 节点 172.26.252.89
curly 节点
指定larry为自启动主机，启动集群。
在moe 和curly 添加
JOIN_IP=172.18.1.38
修改每台宿主机Docker守护进程的网络配置，以便容易使用Consul
Docker守护进程DNS设置为：
~本地docker的 ip 地址，以便使用Consul解析DNS
~GOOGLE的DNS服务器，来解析其他请求
~为Consul查询指定搜索域
获取Docker0的ip地址
使用这个172.17.0.16地址，将/ect/default/docker文件中的Docker启动项默认改为新ip
原：
新：
DOCKER_OPTS='--dns 172.17.0.16 --dns 8.8.8.8 --dns-search service .consul'
moe与curl同理
在larry上重启Docker守护进程
service docker restart
2.4 启动具有自启功能的Consul节点
docker run -d -h $HOSTNAME \
--name larry_agent jamtur01/consul \
-p 8300:8300 -p 8301:8301 \
-p 8301:8301\udp -p 8302:8302 \
-p 8302:8302\udp -p 8400:8400 \
-p 8500:8500 -p 53:53\udp \
--server -advertise $PUBLIC_IP -bootstrap-expect 3
docker run -d -p 8300:8300 -p 8301:8301 -p 8301:8301/udp -p 8302:8302 -p 8302:8302/udp -p 8400:8400 -p 8500:8500 -p 54:53/udp --name larry_agent jamtur01/consul -server -advertise $PUBLIC_IP -bootstrap-expect 2
docker run -d -p 8300:8300 -p 8301:8301 -p 8301:8301/udp -p 8302:8302 -p 8302:8302/udp -p 8400:8400 -p 8500:8500 -p 54:53/udp --name curly_agent jamtur01/consul -server -advertise $PUBLIC_IP -join $JOIN_IP
{
"services":[
{
"id": "EDC_DNC_MSAD_CLIENT_SERVICE_01",
"name" : "CAS Client Service",
"tags": [
"urlprefix-/ClientService01"
],
"address": "192.168.80.71",
"port": 8810,
"checks": [
{
"name": "clientservice_check",
"http": "http://192.168.80.71:8810/api/health",
"interval": "10s",
"timeout": "5s"
}
]
},
{
"id": "EDC_DNC_MSAD_CLIENT_SERVICE_02",
"name" : "CAS Client Service",
"tags": [
"urlprefix-/ClientService02"
],
"address": "192.168.80.71",
"port": 8820,
"checks": [
{
"name": "clientservice_check",
"http": "http://192.168.80.71:8820/api/health",
"interval": "10s",
"timeout": "5s"
}
]
}
]
}
对于一个API请求，首先会经历一个Load Balancer才会到达API Gateway，这个Load Balancer可以是基于硬件的F5，也可以是基于软件的Nginx或LVS再搭配Keepalived，一般来说大部分团队都会选择Nginx。然后API Gateway通过部署多个，来解决单点问题，也达到负载均衡的效果。而对于API Gateway和Consul Client之间的连接，我们往往也会增加一个Load Balancer来实现服务发现的高可用，这个Load Balancer也一般会基于Nginx/LVS搭配Keepalived，API Gateway只需要访问一个Virtual IP即可。而在Consul Data Center中，Consul Server会选择3或5个，Consul Client也会部署多个，刚刚提到的Virtual IP则会指向多个Consul Client，从而防止了Consul Client的单点问题。
https://www.cnblogs.com/edisonchou/p/consul_cluster_based_on_docker_introduction.html
