最后一件事！ etcd 和consul 是用 go 编写的，因此维护它们比像 Zookeeper 这样的 Java 解决方案要容易得多。您所需要的只是 consul / etcd 二进制文件。没有依赖项，没有链接库，没有jvm。
I've looked extensively at Zookeeper/Curator, Eureka, etcd, and consul. Zookeeper/Curator and Eureka are in many ways the most polished and easiest to integrate if you are in the Java world. Etcd is pretty cool and very flexible, but It is really just a HA key store so you would have to write a lot of code to turn it into an opinionated service discovery system.
Consul is (to me) the best of both worlds. It is an opinionated service discovery system written on top of serf, using raft for cluster consensus and gossip for communication. It exposes the discovery / registration endpoints with a well documented REST api, and also allows you to discover services with DNS SRV records, and register services with configuration (i.e. so you can register a database or application you can't integrate a client with, or if you just want to keep your service discovery decoupled from your app)
I've written a blog post about consul where you can learn more and walk through my "try it out" demo
One last thing! etcd & consul are written in go, so maintaining them is much easier then java solutions like zookeeper. All you need is the consul / etcd binary. no dependencies, no linked libraries, no jvm.
There's a very promising alternative to ZooKeeper called etcd (github.com/coreos/etcd), written by CoreOS team. Unlike Doozerd, etcd is being actively developed.
[EDIT] The Hashicorp crew, of Vagrant and Packer fame, are cooking "a decentralized solution for service discovery and orchestration" called Serf.
[EDIT2] Hashicorp strikes again ! They just released Consul, built on top of Serf. The pitch: "a solution for service discovery and configuration, completely distributed, highly available, scalable to thousands of nodes and services across multiple datacenters".
Yes, there is also Doozerd (https://github.com/ha/doozerd). Take a good look at it, it's a nice, single binary distributed coordination service developed by Heroku. With bindings/libraries for java/python/ruby/node. Very easy to get started with and play around.
OpenReplica from my research group is a highly available FOSS coordination service for data centers. It can be used for implementing locking, fail over, leader election, group membership and other coordination services. It differs from ZooKeeper in two critical ways:
It uses an object-oriented API. This makes it much easier to write coordination services. Synchronization code for OpenReplica looks exactly like its textbook counterpart; there is no need to master a file and upcall-based API like in ZooKeeper and Chubby.
It enables dynamic membership updates to the replica set. There is no need for static configuration files. The system is integrated into DNS (authoritative, slave for OpenReplica, or Amazon Route 53).
We actively support the system, do not hesitate to let us know if you have further questions.
There's a project called Noah on github that looks interesting, it says that it's "loosely based on Apache ZooKeeper" https://github.com/lusis/Noah with REST support being a key feature (ZK has this as a contrib/option rather than built in).
The advantage is, you're getting a very simple cluster-manager and you're able to combine this with your favorite configuration, deployment or continuous integration tool.
I know this post is quite old, but someone who is looking at all possible alternatives I would also like to suggest JGroups library which is mature enough to be used in production environment. I have used it successfully in one of my projects mainly for distributed coordination and to share messages between cluster. It also support AWS support in addition to its flexible architecture where you can customize its stack to get what you need. I suggest you to have a look at it
发布评论
评论（11）
我广泛研究了 Zookeeper/Curator、 Eureka、etcd 和 consul。如果您身处 Java 世界，Zookeeper/Curator 和 Eureka 在很多方面都是最完善且最容易集成的。 Etcd 非常酷且非常灵活，但它实际上只是一个 HA 密钥存储，因此您必须编写大量代码来将其变成一个固执己见的服务发现系统。
Consul（对我来说）是两全其美的。它是一个在 serf 之上编写的固执己见的服务发现系统，使用 raft 进行集群共识，使用 gossip 进行通信。它通过记录良好的 REST api 公开发现/注册端点，还允许您使用 DNS SRV 记录发现服务，并使用配置注册服务（即，您可以注册无法与客户端集成的数据库或应用程序，或者如果你只是想让你的服务发现与你的应用程序解耦）
我写了一个关于 consul 的博客文章，您可以在其中了解更多信息并浏览我的“尝试it out”演示
我还讨论了 使用 etcd 进行服务发现& docker 如果您想了解有关自定义代码的更多信息。
最后一件事！ etcd 和consul 是用 go 编写的，因此维护它们比像 Zookeeper 这样的 Java 解决方案要容易得多。您所需要的只是 consul / etcd 二进制文件。没有依赖项，没有链接库，没有jvm。
I've looked extensively at Zookeeper/Curator, Eureka, etcd, and consul. Zookeeper/Curator and Eureka are in many ways the most polished and easiest to integrate if you are in the Java world. Etcd is pretty cool and very flexible, but It is really just a HA key store so you would have to write a lot of code to turn it into an opinionated service discovery system.
Consul is (to me) the best of both worlds. It is an opinionated service discovery system written on top of serf, using raft for cluster consensus and gossip for communication. It exposes the discovery / registration endpoints with a well documented REST api, and also allows you to discover services with DNS SRV records, and register services with configuration (i.e. so you can register a database or application you can't integrate a client with, or if you just want to keep your service discovery decoupled from your app)
I've written a blog post about consul where you can learn more and walk through my "try it out" demo
I've also discussed service discovery with etcd & docker if you want to see more about what that custom code might look like.
One last thing! etcd & consul are written in go, so maintaining them is much easier then java solutions like zookeeper. All you need is the consul / etcd binary. no dependencies, no linked libraries, no jvm.
ZooKeeper 有一个非常有前途的替代方案，名为 etcd (github.com/coreos/etcd)，由 CoreOS 团队编写。与 Doozerd 不同，etcd 正在积极开发中。
There's a very promising alternative to ZooKeeper called etcd (github.com/coreos/etcd), written by CoreOS team. Unlike Doozerd, etcd is being actively developed.
刚刚发现 Accord (C) 和 OpenReplica/ConCoord (Python)，这可能是有趣的解决方案
[编辑] 以 Vagrant 和 Packer 闻名的 Hashicorp 团队正在开发“一种用于服务发现和编排的去中心化解决方案”，名为 农奴。
[EDIT2] Hashicorp 再次出击！他们刚刚发布了构建在 Serf 之上的 Consul。宣传语：“服务发现和配置的解决方案，完全分布式，高度可用，可扩展至跨多个数据中心的数千个节点和服务”。
Just discovered Accord (C) and OpenReplica/ConCoord (Python) which may be interesting solutions
[EDIT] The Hashicorp crew, of Vagrant and Packer fame, are cooking "a decentralized solution for service discovery and orchestration" called Serf.
[EDIT2] Hashicorp strikes again ! They just released Consul, built on top of Serf. The pitch: "a solution for service discovery and configuration, completely distributed, highly available, scalable to thousands of nodes and services across multiple datacenters".
是的，还有 Doozerd (https://github.com/ha/doozerd)。仔细看看，它是 Heroku 开发的一个很好的、单一的二进制分布式协调服务。具有 java/python/ruby/node 的绑定/库。非常容易上手和玩耍。
Yes, there is also Doozerd (https://github.com/ha/doozerd). Take a good look at it, it's a nice, single binary distributed coordination service developed by Heroku. With bindings/libraries for java/python/ruby/node. Very easy to get started with and play around.
看看Serf。 此处对 Zookeeper 和其他工具进行了比较。
Take a look at Serf. There is a comparison vs Zookeeper and others here.
我的研究小组的 OpenReplica 是一个针对数据中心的高度可用的 FOSS 协调服务。它可用于实现锁定、故障转移、领导者选举、组成员身份和其他协调服务。它与 ZooKeeper 有两个关键区别：
它使用面向对象的 API。这使得编写协调服务变得更加容易。 OpenReplica 的同步代码看起来与教科书上的同步代码完全相同；无需像 ZooKeeper 和 Chubby 那样掌握文件和基于上行调用的 API。
它支持对副本集进行动态成员资格更新。不需要静态配置文件。该系统集成到 DNS（权威、OpenReplica 的从属或 Amazon Route 53）中。
我们积极支持该系统，如果您有其他问题，请随时告诉我们。
OpenReplica from my research group is a highly available FOSS coordination service for data centers. It can be used for implementing locking, fail over, leader election, group membership and other coordination services. It differs from ZooKeeper in two critical ways:
It uses an object-oriented API. This makes it much easier to write coordination services. Synchronization code for OpenReplica looks exactly like its textbook counterpart; there is no need to master a file and upcall-based API like in ZooKeeper and Chubby.
It enables dynamic membership updates to the replica set. There is no need for static configuration files. The system is integrated into DNS (authoritative, slave for OpenReplica, or Amazon Route 53).
We actively support the system, do not hesitate to let us know if you have further questions.
github 上有一个名为 Noah 的项目看起来很有趣，它说它“松散地基于 Apache ZooKeeper” https://github .com/lusis/Noah，REST 支持是一个关键功能（ZK 将其作为贡献/选项而不是内置）。
There's a project called Noah on github that looks interesting, it says that it's "loosely based on Apache ZooKeeper" https://github.com/lusis/Noah with REST support being a key feature (ZK has this as a contrib/option rather than built in).
有不同的工具可以针对不同的工程权衡进行优化。
其他的有些有趣，但通常未经证实。如果用于生产用途，请不要弄错。
There are different tools that optimize for different engineering trade-offs.
The others are somewhat interesting but generally unproven. Don't get this wrong if intended for production usage.
我发现了 Zookeeper、etcd 和 Doozer 的比较：
http://devo.ps/blog/zookeeper-vs-doozer-vs- etcd/
Serf (serfdom.io) 也是一个很好的解决方案，因为它很简单！但您必须考虑到，SERF 只是一个集群管理器，它使您能够将自定义事件发送到所有集群节点。这很好，但是您必须编写自己的 shell 脚本（也称为事件）。
请参阅此示例：“
" 优点是，您将获得一个非常简单的集群管理器，并且可以将其与您最喜欢的配置、部署或持续集成工具结合起来。
I'd found this comparison of Zookeeper, etcd and Doozer:
http://devo.ps/blog/zookeeper-vs-doozer-vs-etcd/
Serf (serfdom.io) is also a nice solution as it is simple! But you must consider, SERF is just a cluster-manager which enables you to send custom events to all cluster nodes. Thats nice, but you have to write your own shell scripts (aka events).
See this example: "https://www.digitalocean.com/community/articles/how-to-set-up-a-serf-cluster-on-several-ubuntu-vps"
The advantage is, you're getting a very simple cluster-manager and you're able to combine this with your favorite configuration, deployment or continuous integration tool.
我知道这篇文章已经很老了，但是对于正在研究所有可能的替代方案的人，我还想建议 JGroups 库，它足够成熟，可以在生产环境中使用。我已在我的一个项目中成功使用它，主要用于分布式协调和在集群之间共享消息。除了其灵活的架构之外，它还支持 AWS 支持，您可以在其中自定义其堆栈以满足您的需要。我建议您看一下
I know this post is quite old, but someone who is looking at all possible alternatives I would also like to suggest JGroups library which is mature enough to be used in production environment. I have used it successfully in one of my projects mainly for distributed coordination and to share messages between cluster. It also support AWS support in addition to its flexible architecture where you can customize its stack to get what you need. I suggest you to have a look at it
看起来Corosync也像ZooKeeper。
It seems Corosync is also like ZooKeeper.