服务发现：Zookeeper vs etcd vs Consul

本文对比了Zookeeper、etcd和Consul三种服务发现工具，探讨了最佳的服务发现解决方案，仅供参考。

若是使用预约义的端口，服务越多，发生冲突的可能性越大，毕竟，不可能有两个服务监听同一个端口。管理一个拥挤的比方说被几百个服务所使用的全部端口的列表，自己就是一个挑战，添加到该列表后，这些服务须要的数据库和数量会日益增多。所以咱们应该部署无需指定端口的服务，而且让Docker为咱们分配一个随机的端口。惟一的问题是咱们须要发现端口号，而且让别人知道。

当咱们开始在一个分布式系统上部署服务到其中一台服务器上时，事情会变得更加复杂，咱们能够选择预先定义哪台服务器运行哪一个服务的方式，但这会致使不少问题。咱们应该尽咱们所能尽可能利用服务器资源，可是若是预先定义每一个服务的部署位置，那么要实现尽可能利用服务器资源是几乎不可能的。另外一个问题是服务的自动伸缩将会很是困难，更不用说自动恢复了，比方说服务器故障。另外一方面，若是咱们将服务部署到某台只有最少数量的容器在运行的服务器上，咱们须要添加IP地址到数据列表中，这些数据须要能够被发现并存储在某处。

当咱们须要存储和发现一些与正在工做的服务相关的信息时，还有不少其余的例子。

为了可以定位服务，咱们须要至少接下来的两个有用的步骤。
服务注册——该步骤存储的信息至少包括正在运行的服务的主机和端口信息
服务发现——该步骤容许其余用户能够发如今服务注册阶段存储的信息。

除了上述的步骤，咱们还须要考虑其余方面。若是一个服务中止工做并部署/注册了一个新的服务实例，那么该服务是否应该注销呢？当有相同服务的多个副本时咋办？咱们该如何作负载均衡呢？若是一个服务器宕机了咋办？全部这些问题都与注册和发现阶段紧密关联。如今，咱们限定只在服务发现的范围里（常见的名字，围绕上述步骤）以及用于服务发现任务的工具，它们中的大多数采用了高可用的分布式键/值存储。
服务发现工具

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

服务发现背后的基本思想是对于服务的每个新实例（或应用程序），可以识别当前环境和存储相关信息。存储的注册表信息自己一般采用键/值对的格式，因为服务发现常常用于分布式系统，因此要求这些信息可伸缩、支持容错和分布式集群中的全部节点。这种存储的主要用途是给全部感兴趣的各方提供最起码诸如服务IP地址和端口这样的信息，用于它们之间的相互通信，这些数据还常常扩展到其它类型的信息服务发现工具倾向于提供某种形式的API，用于服务自身的注册以及服务信息的查找。

比方说咱们有两个服务，一个是提供方，另外一个是第一个服务的消费者，一旦部署了服务提供方，就须要在服务发现注册表中存储其信息。接着，当消费者试图访问服务提供者时，它首先查询服务注册表，使用获取到的IP地址和端口来调用服务提供者。为了与注册表中的服务提供方的具体实现解耦，咱们经常采用某种代理服务。这样消费者老是向固定IP地址的代理请求信息，代理再依次使用服务发现来查×××提供方信息并重定向请求，在本文中咱们稍后经过反向代理来实现。如今重要的是要理解基于三种角色（服务消费者、提供者和代理）的服务发现流程。

服务发现工具要查找的是数据，至少咱们应该可以找出服务在哪里？服务是否健康和可用？配置是什么样的？既然咱们正在多台服务器上构建一个分布式系统，那么该工具须要足够健壮，保证其中一个节点的宕机不会危及数据，同时，每一个节点应该有彻底相同的数据副本，进一步地，咱们但愿可以以任何顺序启动服务、杀死服务或者替换服务的新版本，咱们还应该可以从新配置服务而且查看到数据相应的变化。

让咱们看一下一些经常使用的选项来完成咱们上面设定的目标。
手动配置

大多数服务仍然是须要手动管理的，咱们预先决定在何处部署服务、如何配置和但愿无论什么缘由，服务都将继续正常工做，直到天荒地老。这样的目标不是能够轻易达到的。部署第二个服务实例意味着咱们须要启动全程的手动处理，咱们须要引入一台新的服务器，或者找出哪一台服务器资源利用率较低，而后建立一个新的配置集并启动服务。状况或许会变得愈来愈复杂，比方说，硬件故障致使的手动管理下的反应时间变得很慢。可见性是另一个痛点，咱们知道什么是静态配置，毕竟是咱们预先准备好的，然而，大多数的服务有不少动态生成的信息，这些信息不是轻易可见的，也没有一个单独的地方供咱们在须要时参考这些数据。

反应时间会不可避免的变慢，鉴于存在许多须要手动处理的移动组件，故障恢复和监控也会变得很是难以管理。

尽管在过去或者当服务/服务器数量不多的时候有借口不作这项工做，随着服务发现工具的出现，这个借口已经不存在了。
Zookeeper

Zookeeper是这种类型的项目中历史最悠久的之一，它起源于Hadoop，帮助在Hadoop集群中维护各类组件。它很是成熟、可靠，被许多大公司（YouTube、eBay、雅虎等）使用。其数据存储的格式相似于文件系统，若是运行在一个服务器集群中，Zookeper将跨全部节点共享配置状态，每一个集群选举一个领袖，客户端能够链接到任何一台服务器获取数据。

Zookeeper的主要优点是其成熟、健壮以及丰富的特性，然而，它也有本身的缺点，其中采用Java开发以及复杂性是罪魁祸首。尽管Java在许多方面很是伟大，而后对于这种类型的工做仍是太沉重了，Zookeeper使用Java以及至关数量的依赖使其对于资源竞争很是饥渴。由于上述的这些问题，Zookeeper变得很是复杂，维护它须要比咱们指望从这种类型的应用程序中得到的收益更多的知识。这部分地是因为丰富的特性反而将其从优点转变为累赘。应用程序的特×××越多，就会有越大的可能性不须要这些特性，所以，咱们最终将会为这些不须要的特性付出复杂度方面的代价。

Zookeeper为其余项目至关大的改进铺平了道路，“大数据玩家“在使用它，由于没有更好的选择。今天，Zookeeper已经老态龙钟了，咱们有了更好的选择。
etcd

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

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

如今，咱们有一个地方来存储服务相关信息，咱们还须要一个工具能够自动发送信息给etcd。但在这以后，为何咱们还须要手动把数据发送给etcd呢？即便咱们但愿手动将信息发送给etcd，咱们一般状况下也不会知道是什么信息。记住这一点，服务可能会被部署到一台运行最少数量容器的服务器上，而且随机分配一个端口。理想状况下，这个工具应该监视全部节点上的Docker容器，而且每当有新容器运行或者现有的一个容器中止的时候更新etcd，其中的一个能够帮助咱们达成目标的工具就是Registrator。
Registrator

Registrator经过检查容器在线或者中止运行状态自动注册和去注册服务，它目前支持etcd、Consul和SkyDNS 2。

Registrator与etcd是一个简单可是功能强大的组合，能够运行不少先进的技术。每当咱们打开一个容器，全部数据将被存储在etcd并传播到集群中的全部节点。咱们将决定什么信息是咱们的。

上述的拼图游戏还缺乏一块，咱们须要一种方法来建立配置文件，与数据都存储在etcd，经过运行一些命令来建立这些配置文件。
Confd

Confd是一个轻量级的配置管理工具，常见的用法是经过使用存储在etcd、consul和其余一些数据登记处的数据保持配置文件的最新状态，它也能够用来在配置文件改变时从新加载应用程序。换句话说，咱们能够用存储在etcd（或者其余注册中心）的信息来从新配置全部服务。

对于etcd、Registrator和Confd组合的最后的思考

当etcd、Registrator和Confd结合时，能够得到一个简单而强大的方法来自动化操做咱们全部的服务发现和须要的配置。这个组合还展现了“小”工具正确组合的有效性，这三个小东西能够如咱们所愿正好完成咱们须要达到的目标，若范围稍微小一些，咱们将没法完成咱们面前的目标，而另外一方面若是他们设计时考虑到更大的范围，咱们将引入没必要要的复杂性和服务器资源开销。

在咱们作出最后的判决以前，让咱们看看另外一个有相同目标的工具组合，毕竟，咱们不该该知足于一些没有可替代方案的选择。
Consul

Consul是强一致性的数据存储，使用gossip造成动态集群。它提供分级键/值存储方式，不只能够存储数据，并且能够用于注册器件事各类任务，从发送数据改变通知到运行健康检查和自定义命令，具体如何取决于它们的输出。

与Zookeeper和etcd不同，Consul内嵌实现了服务发现系统，因此这样就不须要构建本身的系统或使用第三方系统。这一发现系统除了上述提到的特性以外，还包括节点健康检查和运行在其上的服务。

Zookeeper和etcd只提供原始的键/值队存储，要求应用程序开发人员构建他们本身的系统提供服务发现功能。而Consul提供了一个内置的服务发现的框架。客户只须要注册服务并经过DNS或HTTP接口执行服务发现。其余两个工具须要一个亲手制做的解决方案或借助于第三方工具。

Consul为多种数据中心提供了开箱即用的原生支持，其中的gossip系统不只能够工做在同一集群内部的各个节点，并且还能够跨数据中心工做。

Consul还有另外一个不错的区别于其余工具的功能，它不只能够用来发现已部署的服务以及其驻留的节点信息，还经过HTTP请求、TTLs（time-to-live）和自定义命令提供了易于扩展的健康检查特性。
Registrator

Registrator有两个Consul协议，其中consulkv协议产生相似于etcd协议的结果。

除了一般的IP和端口存储在etcd或consulkv协议中以外，Registrator consul协议存储了更多的信息，咱们能够获得服务运行节点的信息，以及服务ID和名称。咱们也能够借助于一些额外的环境变量按照必定的标记存储额外的信息。

Consul-template

confd能够像和etce搭配同样用于Consul，不过Consul有本身的模板服务，其更适配Consul。

经过从Consul得到的信息，Consul-template是一个很是方便的建立文件的途径，还有一个额外的好处就是在文件更新后能够运行任意命令，正如confd，Consul-template也可使用Go模板格式。

Consul健康检查、Web界面和数据中心

监控集群节点和服务的健康状态与测试和部署它们同样的重要。虽然咱们应该向着拥有历来没有故障的稳定的环境努力，但咱们也应该认可，随时会有意想不到的故障发生，时刻准备着采起相应的措施。例如咱们能够监控内存使用状况，若是达到必定的阈值，那么迁移一些服务到集群中的另一个节点，这将是在发生“灾难”前执行的一个预防措施。另外一方面，并非全部潜在的故障均可以被及时检测到并采起措施。单个服务可能会齿白，一个完整的节点也可能因为硬件故障而中止工做。在这种状况下咱们应该准备尽快行动，例如一个节点替换为一个新的并迁移失败的服务。Consul有一个简单的、优雅的但功能强大的方式进行健康检查，当健康阀值达到必定数目时，帮助用户定义应该执行的操做。

若是用户Google搜索“etcd ui”或者“etec dashboard”时，用户可能看到只有几个可用的解决方案，可能会问为何咱们尚未介绍给用户，这个缘由很简单，etcd只是键/值对存储，仅此而已。经过一个UI呈现数据没有太多的用处，由于咱们能够很容易地经过etcdctl得到这些数据。这并不意味着etcd UI是无用的，但鉴于其有限的使用范围，它不会产生多大影响。

Consu不只仅是一个简单的键/值对存储，正如咱们已经看到的，除了存储简单的键/值对，它还有一个服务的概念以及所属的数据。它还能够执行健康检查，所以成为一个好的候选dashboard，在上面能够看到咱们的节点的状态和运行的服务。最后，它支持了多数据中心的概念。全部这些特性的结合让咱们从不一样的角度看到引入dashboard的必要性。

经过Consul Web界面，用户能够查看全部的服务和节点、监控健康检查状态以及经过切换数据中心读取设置键/值对数据。

对于Consul、Registrator、Template、健康检查和Web UI的最终思考

Consul以及上述咱们一块儿探讨的工具在不少状况下提供了比etcd更好的解决方案。这是从心里深处为了服务架构和发现而设计的方案，简单而强大。它提供了一个完整的同时不失简洁的解决方案，在许多状况下，这是最佳的服务发现以及知足健康检查需求的工具。
结论

全部这些工具都是基于类似的原则和架构，它们在节点上运行，须要仲裁来运行，而且都是强一致性的，都提供某种形式的键/值对存储。

Zookeeper是其中最老态龙钟的一个，使用年限显示出了其复杂性、资源利用和尽力达成的目标，它是为了与咱们评估的其余工具所处的不一样时代而设计的（即便它不是老得太多）。

etcd、Registrator和Confd是一个很是简单但很是强大的组合，能够解决大部分问题，若是不是所有知足服务发现须要的话。它还展现了咱们能够经过组合很是简单和特定的工具来得到强大的服务发现能力，它们中的每个都执行一个很是具体的任务，经过精心设计的API进行通信，具有相对自治工做的能力，从架构和功能途径方面都是微服务方式。

Consul的不一样之处在于无需第三方工具就能够原生支持多数据中心和健康检查，这并不意味着使用第三方工具很差。实际上，在这篇博客里咱们经过选择那些表现更佳同时不会引入没必要要的功能的的工具，尽力组合不一样的工具。使用正确的工具能够得到最好的结果。若是工具引入了工做不须要的特性，那么工做效率反而会降低，另外一方面，若是工具没有提供工做所须要的特性也是没有用的。Consul很好地权衡了权重，用尽可能少的东西很好的达成了目标。

Consul使用gossip来传播集群信息的方式，使其比etcd更易于搭建，特别是对于大的数据中心。将存储数据做为服务的能力使其比etcd仅仅只有健/值对存储的特性更加完整、更有用（即便Consul也有该选项）。虽然咱们能够在etcd中经过插入多个键来达成相同的目标，Consul的服务实现了一个更紧凑的结果，一般只须要一次查询就能够得到与服务相关的全部数据。除此以外，Registrator很好地实现了Consul的两个协议，使其合二为一，特别是添加Consul-template到了拼图中。Consul的Web UI更是锦上添花般地提供了服务和健康检查的可视化途径。

我不能说Consul是一个明确的赢家，而是与etcd相比其有一个轻微的优点。服务发现做为一个概念，以及做为工具都很新，咱们能够期待在这一领域会有许多的变化。秉承开放的心态，你们能够对本文的建议持保留态度，尝试不一样的工具而后作出本身的结论。本文出自http://dockone.io/article/667