Consul实践之Consul常见应用场景及方案梳理(FAQ)

原创作品,允许转载,转载时请务必以超链接形式标明文章 原始出处 、作者信息和本声明。否则将追究法律责任。http://dgd2010.blog.51cto.com/1539422/1731788

Consul实践之Consul常见应用场景及方案梳理(FAQ),这篇文章用来回答一些在文章《Consul实践之相关计划与相关问题》中提到的一些问题。本方案整理参考依据于《使用Consul和Registrator实现Docker容器服务发现》英文原文《SERVICE DISCOVERY FOR DOCKER CONTAINERS USING CONSUL AND REGISTRATOR》,方案的实施依据可以根据原文进行。


  1. 手动新增的服务节点是否可以自动发现?

    将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地址必须是可用的。


  2. 当某一服务节点down掉后,是否可以自动去除?

    凡是自动注册到consul中的任意服务节点down掉后,可以自动从consul中移除。


  3. 各个节点的运行情况监控,如果某个节点压力过大时是否运维人员如何得知?

    consul自带持久化数据库以及健康监测机制,数据库中存储了每一个服务节点的状态信息(默认的状态信息是该容器端口是否可用(可正常连接))。这些状态信息都可以通过consul提供的UI(可以理解成一种http web服务)监测到。运维人员也可以通过将每一个容器安装consul agent的形式结合consul配置文件获取更多的状态信息,从consul提供的UI界面上查看。当然也可以借助其他监控方案获取容器内的服务状态信息,如借助zabbix或者针对docker的其他监控方案,因为consul提供的UI界面只能反映三种服务状态,通过、警告和严重级别,而且不能提供报警配置。


  4. 是否支持多个节点共享同一套配置?

    consul存在的目的就是为了让多个节点共享一套配置,节点之间共享配置是通过consul提供的HTTP API 实现的,开发人员可以通过curl工具以及相关库根据consul提供的服务信息决定使用什么样的配置。如如果开发人员需要知道自己有什么数据库可以使用,则可以查询curl http://cluster.service.consul:8500/v1/catalog/services(cluster.service.consul域名是假设的consul集群地址对应的域名,初步的想法是将consul自身作为一种服务,通过DNS可以查询到)获得consul中注册过的数据库信息。


  5. 当节点压力过大时,是否可以自动的扩展节点?

    根据目前已掌握的资料,暂时不支持此功能。


  6. Consul本身集群,如某一Consul节点故障了,其它的Consul节点是否可以正常提供服务?

    consul集群自身具备容错功能,当部署3个节点时,其容错是1,也就是允许1个consul节点宕机,具体的可以参见Consul实践之Consul结合nginx构建高可用可扩展的Web服务中列举的表格(即 Deployment Table),或者直接参考Consul官方推荐部署方式BOOTSTRAPPING A DATACENTER 以及 Deployment Table

  7. 目前需要解决和评定的问题有:

    1. 集群地址的绑定问题,是否需要绑定集群地址以及如何确定集群地址?参考第1条中的“有一种情况应该考虑,假如负载由nginx分发,则如果采用consul-template根据consul集群中的服务信息变更,consul-template使用的consul地址必须是可用的。”

    2. consul以及其他服务节点的监控问题,如何组合监控以及采用什么样的方案?

  8. 其他问题将继续补充。

  9. 以上方案整理参考依据于《使用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

上一篇:WordCount 案例 Mapper| 学习笔记


下一篇:多 Job 串联案例第一个 Job |学习笔记