Consul解决的问题有多个，但是每一个单个的问题都已经被许多不同的系统解决。虽然没有一个单个的系统提供Consul的所有功能，但是有其它选择来解决其中的部分问题。

这一节我们将比较Consul和其它选择。在大多数情况下，Consul和其它系统并不是互斥的。

使用左边的导航了解Consul和其它指定系统的比较。

CONSUL VS. ZOOKEEPER, DOOZERD, ETCD

ZooKeeper、doozerd和etcd有着相似的架构，这三个都有Server节点，并且需要一个法定的多数（通常是简单多数）节点才能进行运转。他们是强一致性的，并且开放多种基本操作，使用这些操作编写成Client库，集成到应用中来构建复杂的分布式系统。

Consul也需要Server节点。在每个数据中心，Consul都需要一个法定的数目的Server节点来控制和提供强一致性。然而，Consul原生支持多数据中心，并且有一个用于连接Server和Client节点的功能丰富的流言系统。

这些系统在提供键值存储方面都有大致相同的语义：读是强一致的，并且在面对网络分区时可用性要为保证一致性做出牺牲。然而当这些系统被应用于一些高级场景时，其和Consul的差异将变的更为明显。

这些系统提供的语义对于服务发现是很有吸引力的，但是很重要的需要强调的是这些功能必须自己构建。ZooKeeper以及其它的软件仅仅提供了一个原始的键值存储功能，需要应用开发者构建他们自己的系统来提供服务发现。和它们比起来，Consul专门提供了一个框架用于服务发现，消除了空头支票和开发计划。Client简单地注册服务，然后使用DNS或者HTTP接口进行服务发现。其它的系统则需要一个自己定制的解决方案。

一个值得信赖的服务发现框架必须包含健康检查，以及可能的故障检测。对于节点A上的Foo Service，如果节点已经挂了或者服务已经崩溃了，那么知道这个服务的存在没有什么用处。朴素的（简单的）系统一般可以使用心跳、周期性的更新和TTLs等方案来实现此功能。这些方案需要工作在线性增长的节点，并要求一组固定数量的Server。另外，故障检测窗口至少要像TTL一样长。

ZooKeeper的临时节点，作为键值条目存在，当客户端连接断开时条目被删除。这比一个心跳系统更为精密，但是也会带来扩展性问题，并增加客户端的复杂性。所有的客户端必须保持到ZooKeeper Server的活动连接，并进行keep-alives。另外，这将导致“胖客户端”，程序难以编写并经常导致调试风险。

Consul使用一个非常不同的架构来进行健康检查。除了Server节点，Consul Client运行在集群的每一个节点。这些Client是流言池的一部分，流言池提供一些功能，包括分布式的健康检查。流言协议实现了一个高效的故障检测，可以扩展到一个任意数量的集群，而不集中工作在一个选定的Server组。Client也可以在本地运行一套丰富的的健康检查，反之ZooKeeper临时节点是一个非常原始的活跃度检查。使用Consul，Client可以检查一个Web服务是否返回200状态码，内存使用是否危急，是否有足够的磁盘空间，等等。Consul客户端开放一个简单的HTTP接口，并且避免像ZooKeeper一样将系统的复杂性暴露给客户端。

Consul提供了优秀的服务发现、健康检查、键值存储和多数据中心支持。其它系统为了提供比简单的键值存储更多的功能，需要在其上增加另外的工具或库。在Client节点，Consul仅需要一个瘦客户端提供一个简单的API。此外，通过配置文件和DNS接口可以实现一个完整的服务发现方案，可以完全避免使用API，从而不用进行任何开发工作。

CONSUL VS. CHEF, PUPPET, ETC.

很多人在使用Chef、Puppet，以及其它配置管理工具构建服务发现机制，这种机制通常在一个周期性收敛运行的过程中通过全局状态查询在每个节点上生成配置文件。

不幸的是，这个方式（途径）有一些陷阱。配置信息是静态的，并且不能比收敛运行更频繁的进行更新，一般更新会间隔许多分钟或小时。此外，没有机制让系统的状态包含在配置中：不健康的节点接收访问可能使问题更加恶化。使用此方式还会带来支持多数据中心的挑战：一组中央服务器必须管理所有的数据中心（译者注：Chef、Puppet通过Server管理所有Client）。

Consul被明确地设计为一个服务发现工具。因此，它对于集群的状态提供更多的动态性和便捷性。节点可以注册和注销它们提供的服务，可以依赖应用和服务快速地发现其它所有提供者。通过集成的健康检查，Consul可以使路由访问远离不健康的节点，从而允许系统和服务优雅的恢复。原来由配置管理工具提供的静态配置可以转移到动态的键值存储。这允许应用配置可以不用再通过一个缓慢的收敛运行进行更新。最后，由于每一个数据中心独立运行，支持多数据中心不再比单个数据中心更加困难。

不过，Consul不是用来代替配置管理工具的。这些工具对于安装应用还是很重要的，包括Consul自己。静态配置最好通过现有的管理工具，动态状态和发现通过Consul进行管理更好。分离配置管理和集群管理也会带来一些有利的副作用：没有全局状态，Chef recipes和Puppet manifests变的更简单；周期性的运行不再需要关心服务和配置变更；因为配置管理运行不需要全局状态，则基础设施无需改变（译者注：不需要维护全局状态，则不需要改变配置管理工具）。

CONSUL VS. NAGIOS, SENSU

Nagios和Sensu都被构建为监控工具，用于当问题发生时快速的通知运维人员。

Nagios使用一组被配置为在远程主机执行检查任务的中央服务器。这个设计使它难以扩展，因为大型集群会迅速达到垂直尺度的限制，而Nagios自身也不能容易的进行水平扩展。众所周知，Nagios很难与现代的DevOps和配置管理工具配合使用，因为当远程服务器添加或移除时，主机上的配置必须被更新（不能自动发现）。

Sensu有更多的现代设计，它依赖本地Agent运行检查，然后将结果推送到一个AMQP Broker。若干服务器从Broker接收并处理健康检查的结果。这个模型比Nagios具有更多的可伸缩性，因为它允许更多的水平伸缩，并且Agent和Server之间是弱耦合的。然而，中心Broker有伸缩的限制，并且是系统中的单一故障点。

Consul提供了像Nagios和Sensu一样的健康检查能力，并且对现代的DevOps友好，避免了其它系统固有的伸缩性问题。Consul在本地运行所有的检查，就像Sensu一样，避免把负载全放到中央服务器（译者注：避免把鸡蛋放到一个篮子里

）。Consul Server维护检查的状态，它具有一定的故障容忍度，并且没有单点故障。最后，Consul可以扩大到更多的检查数量，因为它依靠边界触发更新。这意味着，仅当一个检查状态从“passing”转换为“faling”或者反过来的时候，才会触发更新。

在一个大型集群，大多数的检查都是passing状态，也可能存在少量的检查一直是failing状态。通过仅捕获状态改变，Consul减少了大量的网络通信，以及健康检查的计算资源，允许系统提供更多的可伸缩性。

敏锐的读者可能注意到，如果一个Consul Agent挂了，将不会有边界触发更新的事发生。从其它节点看，所有的健康检查将呈现为一个不变的稳定的状态。然而，Consul守护进程也会处理这个问题。Client和Server使用的流言协议集成了一个分布式的故障检测器。这意味着如果一个Consul Agent挂了，故障将被检测到，于是这个节点上运行的所有健康检查将被认为失败。同时故障检测器在整个集群分发这个工作，更重要的是，使边界触发架构运作起来。

CONSUL VS. SKYDNS

SkyDNS是一个提供服务发现的工具。它使用多个具有强一致性和故障容错的中心服务器。节点使用HTTP API进行服务注册，通过HTTP或DNS查询进行服务发现。

Consul非常相似，但提供了这些功能的一个超集。Consul也依赖于多个中央服务器提供强一致性和故障容错。节点可以使用HTTP API或使用Agent进行服务注册，通过HTTP或DNS进行查询。

然而，它们在许多方面有所不同。Consul提供了更为丰富的健康检查框架，支持任意检查和高伸缩性的故障检测。SkyDNS依赖普通的心跳和TTL，这个方法存在出了名的伸缩性问题。此外，相对Consul执行的丰富的健康检查，SkyDNS的心跳只提供一个有限的存活度检查。

SkyDNS通过使用“regions”来支持多数据中心。然而，数据只能被一个集群管理和查询。如果服务器分隔在不同的数据中心，复制协议将要容忍非常长的提交时间。如果所有的SkyDns服务器都在一个中央数据中心，连通性问题将导致整个数据中心失去可用性。此外，即时不存在连通性问题，因为请求必须在远程数据中心执行，查询性能也是个问题。

Consul非常好的支持多数据中心，它专门将管理的数据控制在每个数据中心的范围。这意味着每个数据中心运行一个独立的Server集群。如果需要的话，请求直接指向远程数据中心；一个数据中内的服务请求绝不会通过WAN，并且不同数据中心间的连接性问题也不会影响同一个数据中心内的可用性。此外，一个数据中心内的不可用也不会影响其他数据中心服务的服务发现功能。

CONSUL VS. SMARTSTACK

SmartStack是一个处理服务发现问题的工具。它有一个相当独特的架构，有4个主要的组件：ZooKeeper, HAProxy, Synapse, and Nerve。ZooKeeper负责存储集群状态，以一致性的和故障容错的方式。Nerve和Synapse运行在SmartStack集群中的每个节点。Nerve负责对服务进行健康检查，并注册到ZooKeeper服务器（译者注：创建ZooKeeper临时节点）。Synapse为服务提供者查询ZooKeeper，动态的配置HAProxy。最后，客户端与HAProxy通信，HAProxy进行健康检查，并处理服务多份部署之间的负载均衡。

Consul是一个非常简单但功能丰富的系统，并且它不依赖于任何其它组件。Consul集成流言协议来跟踪所有的节点，并进行服务器发现。这意味着服务器地址不需要硬编码，并且变化时不需要更新整个集群，这和SmartStack是不同的。

Consul和Nerves都可以通过配置文件进行服务注册，但是Consul也支持通过API动态的改变正在使用的服务和检查。

对于服务发现，SmartStack客户端必须使用HAProxy，需要Synapse预先配置所有需要的节点。Consul客户端使用DNS或HTTP API，而不用任何预先配置。Consul还提供一个Tag概念，允许服务提供元数据如版本、主/副名称，或者其它指定的符号，用于过滤服务。客户端可以仅请求匹配指定Tag的服务。

在管理健康检查方面SmartStack和Consul也是不同的。Nerve和Consul Agent以类似的方式执行本地健康检查。然而，Consul维护隔离的目录和健康系统。这个区分允许运维人员可以看到每个服务池中有哪些节点，以及哪些节点是检查失败的。Nerve当检查失败时只是简单的注销节点，提供有限的运维洞察力。Synapse还通过配置HAProxy进行另外的健康检查。这导致所有潜在的服务客户端都会进行活跃度检查。在一个大的集群中，这种N-to-N风格的健康检查可能代价过高。

总的来说Consul提供了一个非常丰富的健康检查系统。Consul支持Nagios风格式的插件，支持巨大的检查目录。Consul允许服务和主机级别的检查。Consul甚至提供一个“死人键”检查，以允许应用可以容易的整合自定义健康检查。最终，所有这些整合到一个健康和目录系统，运维人员通过API可以洞察更广泛的系统。

除了服务发现和健康检查，Consul还为配置管理提供一个键值存储，并支持多数据中心。如果配置SmartStack支持多数据中心，中央ZooKeeper集群对于故障容错部署可能是一个严重的妨碍。