Consul实践之Consul常见应用场景及方案梳理（FAQ），这篇文章用来回答一些在文章《Consul实践之相关计划与相关问题》中提到的一些问题。本方案整理参考依据于《使用Consul和Registrator实现Docker容器服务发现》英文原文《SERVICE DISCOVERY FOR DOCKER CONTAINERS USING CONSUL AND REGISTRATOR》，方案的实施依据可以根据原文进行。
-
手动新增的服务节点是否可以自动发现？
将consul以容器的方式部署到三个独立的主机上。Consul的DNS地址绑定到docker引擎的docker bridge地址，其他的地址如通告地址（the advertise address）、客户端访问地址等使用主机的私有地址（private address），每一个docker引擎上都部署一个registrator容器（其docker hub地址是https://hub.docker.com/r/gliderlabs/registrator/，有的资料上可能会用https://hub.docker.com/r/progrium/registrator/，两者是一样的），该容器内运行一个守护程序，该守护程序的功能是从docker socket监听docker事件，将凡是提供服务端口的docker容器都自动注册到consul中。这样一来就能解决手动新增服务节点被consul自动发现的问题。要想解决consul集群故障切换问题，首先要解决consul的集群地址问题，初步想法是将docker bridge地址设置成集群地址，因为每一个docker引擎必有一个docker bridge，将这几个docker bridge网卡的IP地址设置成一样的地址，如192.168.0.1，这样当三个节点中的任意一个consul服务节点挂掉后，另外两个consul服务节点会自动选举出一个可用的leader，由于集群地址是不变的，因此其他的Consul节点可以继续提供为registrator以及后续其他服务提供consul服务。 考虑到registrator可以不使用的consul集群地址，而使用每一个consul服务节点的私有地址，假设主机发生宕机，则运行有registrator的容器和其他提供服务的容器都会宕机，而其他两外两个节点上的容器可以照旧工作，因此集群地址对于registrator来说并不是必须的。
有一种情况应该考虑，假如负载由nginx分发，则如果采用consul-template根据consul集群中的服务信息变更，consul-template使用的consul地址必须是可用的。 -
当某一服务节点down掉后，是否可以自动去除？
凡是自动注册到consul中的任意服务节点down掉后，可以自动从consul中移除。
-
各个节点的运行情况监控，如果某个节点压力过大时是否运维人员如何得知？
consul自带持久化数据库以及健康监测机制，数据库中存储了每一个服务节点的状态信息（默认的状态信息是该容器端口是否可用（可正常连接））。这些状态信息都可以通过consul提供的UI（可以理解成一种http web服务）监测到。运维人员也可以通过将每一个容器安装consul agent的形式结合consul配置文件获取更多的状态信息，从consul提供的UI界面上查看。当然也可以借助其他监控方案获取容器内的服务状态信息，如借助zabbix或者针对docker的其他监控方案，因为consul提供的UI界面只能反映三种服务状态，通过、警告和严重级别，而且不能提供报警配置。
-
是否支持多个节点共享同一套配置？
consul存在的目的就是为了让多个节点共享一套配置，节点之间共享配置是通过consul提供的HTTP API 实现的，开发人员可以通过curl工具以及相关库根据consul提供的服务信息决定使用什么样的配置。如如果开发人员需要知道自己有什么数据库可以使用，则可以查询curl http://cluster.service.consul:8500/v1/catalog/services（cluster.service.consul域名是假设的consul集群地址对应的域名，初步的想法是将consul自身作为一种服务，通过DNS可以查询到）获得consul中注册过的数据库信息。
-
当节点压力过大时，是否可以自动的扩展节点？
根据目前已掌握的资料，暂时不支持此功能。
-
Consul本身集群，如某一Consul节点故障了，其它的Consul节点是否可以正常提供服务？
consul集群自身具备容错功能，当部署3个节点时，其容错是1，也就是允许1个consul节点宕机，具体的可以参见Consul实践之Consul结合nginx构建高可用可扩展的Web服务中列举的表格（即 Deployment Table），或者直接参考Consul官方推荐部署方式BOOTSTRAPPING A DATACENTER 以及 Deployment Table。
-
目前需要解决和评定的问题有：
-
集群地址的绑定问题，是否需要绑定集群地址以及如何确定集群地址？参考第1条中的“有一种情况应该考虑，假如负载由nginx分发，则如果采用consul-template根据consul集群中的服务信息变更，consul-template使用的consul地址必须是可用的。”
-
consul以及其他服务节点的监控问题，如何组合监控以及采用什么样的方案？
-
-
其他问题将继续补充。
-
以上方案整理参考依据于《使用Consul和Registrator实现Docker容器服务发现》英文原文《SERVICE DISCOVERY FOR DOCKER CONTAINERS USING CONSUL AND REGISTRATOR》
tag:Consul常见问题,Consul方案,Consul集群地址,Consul监控,Consul自动注册
--end--
本文出自 “通信，我的最爱” 博客，请务必保留此出处http://dgd2010.blog.51cto.com/1539422/1731788