服务发现:zookeeper vs consul vs etcd

　　为了能够定位服务，我们需要至少接下来的两个有用的步骤。

• 服务注册——该步骤存储的信息至少包括正在运行的服务的主机和端口信息
• 服务发现——该步骤允许其他用户可以发现在服务注册阶段存储的信息。

一、服务发现工具

　　服务发现工具的主要目标是用来服务查找和相互对话，为此该工具需要知道每个服务，这不是一个新概念，在Docker之前就已经存在很多类似的工具了，然而，容器带给了这些工具一个全新水平的需求。

　　服务发现背后的基本思想是对于服务的 每一个新实例（或应用程序），能够识别当前环境和存储相关信息。存储的注册表信息本事通常采用键值对的格式，由于服务发现经常用于分布式系统，所以要求这些信息可伸缩、支持容错和分布式集群中的所有节点。

　　这种存储的主要用途是给所有感兴趣的法方面提供最起码诸如服务器IP地址和端口，用途他们之间的互相通讯，这些数据还经常扩展到其他类型的信息服务服务发现工具倾向于提供某种形式的API，用于服务自身的注册以及服务信息的查找。

　　既然在多台服务器上构建一个分布式系统，那么该工具需要足够健壮，保证其中一个节点的宕机不会危及数据，同时，每个节点应该有完全相同的数据副本。我们希望能够以任何顺序启动服务、杀死服务或替换服务的新版本，我们还必须能够重新配置服务并且查看数据相应的变化。

二、zookeeper

　　1、zookeeper简述

　　​​Zookeeper​​是这种类型的项目中历史最悠久的之一，它起源于Hadoop，帮助在Hadoop集群中维护各种组件。它非常成熟、可靠，被许多大公司（YouTube、eBay、雅虎等）使用。

　　其数据存储的格式类似于文件系统，如果运行在一个服务器集群中，Zookeper将跨所有节点共享配置状态，每个集群选举一个领袖，客户端可以连接到任何一台服务器获取数据。

　　2、zookeeper优缺点

　　主要优势：其成熟、健壮以及丰富的特性。

　　缺点：其中采用Java开发以及复杂性是罪魁祸首。尽管Java在许多方面非常伟大，然后对于这种类型的工作还是太沉重了，Zookeeper使用Java以及相当数量的依赖使其对于资源竞争非常饥渴。

　　因为上述的这些问题，Zookeeper变得非常复杂，维护它需要比我们期望从这种类型的应用程序中获得的收益更多的知识。这部分地是由于丰富的特性反而将其从优势转变为累赘。应用程序的特性功能越多，就会有越大的可能性不需要这些特性，因此，我们最终将会为这些不需要的特性付出复杂度方面的代价。

　　zookeeper为其他Hadoop项目的改进铺平了道路，“大数据玩家”在说过它，因为没有更好的选择。现在已有更好的选择

三、etcd

　　​​etcd​​​是一个采用HTTP协议的健/值对存储系统，它是一个分布式和功能层次配置系统，可用于构建服务发现系统。其很容易部署、安装和使用，提供了可靠的数据持久化特性。它是安全的并且文档也十分齐全。

　　etcd比Zookeeper是比更好的选择，因为它很简单，然而，它需要搭配一些第三方工具才可以提供服务发现功能。　

　　理想情况下，这个工具应该监视所有节点上的Docker容器，并且每当有新容器运行或者现有的一个容器停止的时候更新etcd，其中的一个可以帮助我们达成目标的工具就是Registrator。

　　etcd、Registrator和Confd是一个非常简单但非常强大的组合，可以解决大部分问题，如果不是全部满足服务发现需要的话。它还展示了我们可以通过组合非常简单和特定的工具来获得强大的服务发现能力，它们中的每一个都执行一个非常具体的任务，通过精心设计的API进行通讯，具备相对自治工作的能力，从架构和功能途径方面都是微服务方式。

四、consul

　　consul集健康检查、Web界面和数据中心为一体。

　　Consul使用gossip来传播集群信息的方式，使其比etcd更易于搭建，特别是对于大的数据中心。将存储数据作为服务的能力使其比etcd仅仅只有健/值对存储的特性更加完整、更有用（即使Consul也有该选项）。

　　可以在etcd中通过插入多个键来达成相同的目标，Consul的服务实现了一个更紧凑的结果，通常只需要一次查询就可以获得与服务相关的所有数据。除此之外，Registrator很好地实现了Consul的两个协议，使其合二为一，特别是添加Consul-template到了拼图中。Consul的Web UI更是锦上添花般地提供了服务和健康检查的可视化途径。