consul介绍
在分布式架构中，服务治理是一个重要的问题。在没有服务治理的分布式集群中，各个服务之间通过手工或者配置的方式进行服务关系管理，遇到服务关系变化或者增加服务的时候，人肉配置极其麻烦且容易出错。之前在一个C/C++项目中，采用ZooKeeper进行服务治理，可以很好的维护服务之间的关系，但是使用起来较为麻烦。现在越来越多新的项目采用consul进行服务治理，各方面的评价都优于ZooKeeper。
consul PK zookeeper
-
开发语言方面，zookeeper采用java开发，安装的时候需要部署java环境；consul采用golang开发，所有依赖都编译到了可执行程序中，即插即用。
-
部署方面，zookeeper一般部署奇数个节点方便做简单多数的选举机制。consul部署的时候分server节点和client节点（通过不同的启动参数区分），server节点做leader选举和数据一致性维护，client节点部署在服务机器上，作为服务程序访问consul的接口。
-
一致性协议方面，zookeeper使用自定义的zab协议，consul的一致性协议采用更流行的Raft。
-
zookeeper不支持多数据中心，consul可以跨机房支持多数据中心部署，有效避免了单数据中心故障不能访问的情况。
-
链接方式上，zookeeper client
api和服务器保持长连接，需要服务程序自行管理和维护链接有效性，服务程序注册回调函数处理zookeeper事件，并自己维护在zookeeper上建立的目录结构有效性（如临时节点维护）；consul采用DNS或者http获取服务信息，没有主动通知，需要自己轮训获取。 -
工具方面，zookeeper自带一个cli_mt工具，可以通过命令行登录zookeeper服务器，手动管理目录结构。consul自带一个Web
UI管理系统， 可以通过参数启动并在浏览器中直接查看信息。
consul 与 eureka
- Eureka是一个服务发现工具。该体系结构主要是客户端/服务器，每个数据中心有一组Eureka服务器，通常每个可用区域一个。通常Eureka的客户使用嵌入式SDK来注册和发现服务。对于非本地集成的客户，使用功能区边框等透过Eureka透明地发现服务。
- Eureka提供了一个弱一致的服务视图，使用尽力而为复制。当客户端向服务器注册时，该服务器将尝试复制到其他服务器，但不提供保证。服务注册的生存时间（TTL）较短，要求客户端对服务器心存感激。不健康的服务或节点将停止心跳，导致它们超时并从注册表中删除。发现请求可以路由到任何服务，由于尽力而为的复制，这些服务可能会导致陈旧或丢失数据。这个简化的模型允许简单的群集管理和高可扩展性。
- Consul提供了一套超级功能，包括更丰富的健康检查，关键/价值存储以及多数据中心意识。Consul需要每个数据中心都有一套服务器，以及每个客户端的代理，类似于使用像Ribbon这样的边车。Consul代理允许大多数应用程序成为Consul不知情者，通过配置文件执行服务注册并通过DNS或负载平衡器sidecars发现。
- Consul提供强大的一致性保证，因为服务器使用Raft协议复制状态 。Consul支持丰富的健康检查，包括TCP，HTTP，Nagios/Sensu兼容脚本或基于Eureka的TTL。客户端节点参与基于八卦的健康检查，该检查分发健康检查工作，而不像集中式心跳检测那样成为可扩展性挑战。发现请求被路由到选举出来的领事领导，这使他们默认情况下强烈一致。允许陈旧读取的客户端使任何服务器都可以处理他们的请求，从而实现像Eureka这样的线性可伸缩性。
- Consul强烈的一致性意味着它可以作为领导选举和集群协调的锁定服务。Eureka不提供类似的保证，并且通常需要为需要执行协调或具有更强一致性需求的服务运行ZooKeeper。
- Consul提供了支持面向服务的体系结构所需的一系列功能。这包括服务发现，还包括丰富的运行状况检查，锁定，密钥/值，多数据中心联合，事件系统和ACL。Consul和consul-template和envconsul等工具生态系统都试图尽量减少集成所需的应用程序更改，以避免需要通过SDK进行本地集成。Eureka是一个更大的Netflix
OSS套件的一部分，该套件预计应用程序相对均匀且紧密集成。因此，Eureka只解决了一小部分问题，希望ZooKeeper等其他工具可以一起使用。 - 在CAP中，Consul使用CA体系结构，有利于实现可用性一致性; eureka使用AP弱一致性
如果我的文章对您有帮助，我恭喜你
如果对我的文章有任何的疑问或批评，我特别感谢你，即使不确定也请大胆的说出来一起讨论
生命不止，let’s go go go !