尽管Consul解决的问题很多，但是每个独立功能都有了其他成熟的解决方案。
Consul vs. ZooKeeper, doozerd, etcd
ZooKeeper, doozerd, etcd三者在架构上很相似，集群中的服务节点需要保持能够进行仲裁的数目（通常是过半）。他们有很强的一致性，通过在应用中引入对应的客户端来构建复杂的分布式系统。
所有的系统在k/v存储上提供大致的语义：强一致性的读和牺牲一些一致性，尽可能的保证可用性在遇到网络隔离的情况下。
Zookeeper等只提供原始的k/v存储。相比之下，Consul为服务发现提供一种独特的框架，client只需简单注册服务，然后使用DNS或是HTTP接口执行发现。
一个引人注目的服务发现框架必须提供健康检查和故障检测的能力。
Zookeeper提供临时节点存储k/v，当client掉线后会被删除，比起心跳机制会更加复杂。并且client必须维护与ZooKeeper Servers的连接。以至于这些client的实现会非常困难。
Consul提供一种非常特殊的心跳机制。Consul集群中除了运行Server节点外，Consul Clients在集群的每个节点上运行。这些client是gossip pool的一部分。Consul Client可以检查web服务是否200，内存利用率，磁盘空间等。
Consul vs. Serf
Serf是一个服务发现和编排工具，是迄今为止讨论的唯一个基于最终一致性的gossip模型与去中心化的实现。提供诸如：组员身份、故障检测、事件广播、查询机制。但是Serf不提供任何高阶的功能，例如：服务发现、健康检查、k/v存储。
Consul内部的gossip实现实际上依赖了Serf库。Consul在组员身份和故障检测基础上添加服务发现。
Serf提供的健康检查十分底层只能识别agent是否存活。Consul进行扩展，提供了丰富的健康检查系统，除了host和服务级别的检查，健康检查被集成到中央类目，可以获取集群内部的信息。
Serf的组员身份（节点状态检查？）只能到node级别，然后Consul聚焦到服务级别的抽象，映射多个服务到单个节点。
为了服务级的抽象与健康检查的提高，Consul支持多数据中心的k/v存储。提供数据中心的同步。
Consul是一种CP系统，Serf则是AP系统，即Serf是个去中心化系统。
Consul vs. Eureka
Eureka是个服务发现的工具。架构是原始的c/s（c/s架构如果理解？），每个数据中心有一组Eureka服务。通常，Eureka的Client会用一个内嵌的SDK去完成注册和发现服务。对于非天然集成的Client，使用Sidecar模式例如Ribbon透传发现服务到Eureka。
Eureka提供一种弱一致性的服务视图。当一个Client向服务器注册时，该服务器将尽力去尝试向其他服务器进行服务，但不保证复制成功。服务注册有一个短暂的时间TTL，对服务器建立心跳。不健康的服务或是节点会被停止心跳检测，导致他们超时并被删除。
Consul提供一系列超级功能，包括：丰富的健康检查、k/v存储、多数据中心的感知。Consul同样使用Sidecar的模式。Consul agent容许大多数的应用对其无感知，通过配置文件执行服务注册，并通过DNS或负载均衡进行服务注册。
Consul使用Raft协议提供强一致性的保证。
Consul vs. Istio
Istio是一种先进的微服务开发平台。
Consul vs. Envoy and Other Proxies
"摩登"的服务代理，为微服务更加云环境提供高阶的服务路由、鉴权、telemetry、等。
a primary challenge of proxies is the configuration sprawl and orchestration.
Proxies形成所谓的"data plane"：数据传输的途径。在此之上的是"control plane"：为数据面板提供规则和配置。Envoy集成了Consul为动态填充服务的后端地址。
Consul是一种控制面板的解决方案，集成了包括Envoy、HAProxy、Nginx其他的数据面板。
