consul VS zookeeper、etcd、doozerd

为什么80%的码农都做不了架构师？>>>   

        zookeeper、doozerd、etcd都有着相似的架构，这三者的服务节点都需要一个仲裁节点来操作，它们是强一致的，并提供各种操作原语。应用程序可以通过客户端lib库来构建分布式的系统。在一个单datacenter中，consul的server节点工作在一种简单的方式下，consul server需要一个仲裁操作，并提供强一致性。consul原生的支持多datacenter，就像多gossip系统链接sever节点和clients一样。

         如果任何这些系统都用于K/V值存储，它们都提供了相同的语义，读取是强一致性的，在面对网络分区的时候，牺牲一致性确保可用性，然而，当系统使用高级特性的时候这些差异更加明显。这些系统提供的语义对构建服务发现有很大作用。zookeeper只提供原始的K/V值存储，并要求开发人员自己构建自己的系统来提供服务发现功能。consul提供了一个坚固的服务发现框架，这样就提升了开发的工作效率。客户端简单的注册服务，然后使用DNS或者HTTP接口来发现服务。其他其他则需要你自己定制自己的解决方案。一个令人信服的服务发现框架必须包含健康检测和考虑失败的可能性。原生的系统使用心跳检测、周期性的更新和TTL来确保发现服务异常。这个系统需要知道工作节点的数量和固定数量服务器上的需求。此外，故障检测窗口需要TTL机制。zookeeper提供了短暂节点的K/V条目，当客户端断开链接则删除该条目。这是比心跳检测更复杂的系统，但是也有增加客户端难的问题。所有客户端必须维护到zookeeper服务的连接活跃，并发送活跃消息，而且，这种客户端比较厚重，很难编写，易出BUG。consul使用一个完全不同的体系进行健康检查。不只是在server节点，consul client运行在集群中的每一个节点上，这些clients是gossip pool的一部分，提供包括分布式健康监测的功能。gossip协议提供了一个高效的故障检测机制，可以扩展到任何集群规模，而没有任何工作集中在某台服务器上客户端也支持在本地进行更丰富的健康监测。而zookeeper的短暂节点是一个非常原始的活跃度检查。客户端可以检查web服务器的状态返回码，内存利用率、磁盘使用情况等等。consul clients暴露出了一个HTTP接口，避免像zookeeper一样暴露给客户端一些复杂的系统。consul提供一流的服务发现、健康检查、K/V存储、多数据中心服务。支持任何简单的K/V存储，所有这些其他系统都需要额外的工具和lib库。通过client节点，consul提供了一个简单的API接口。

转载于:https://my.oschina.net/guol/blog/353397