最近由于项目需要以微服务方式重构，在注册中心选择上有很多个选择，之前是首选的Eureka，但由于2.0后不更新了，所以将方向转为了其他分布式注册中心，目前比较倾向于Consul，看了一下，网上说的一些比较都不尽翔实，带上了很多主观因素。索性去看下官网，恰好官网有对这些注册中心的比较，下面是我源自官网的一些译文。
简述
Eureka是一个服务发现工具，体现在client/server架构上，每个数据服务节点都是一个Eureka服务器，一般来说每个可用区域有一个。（PS：Eureka的数据分布在多个数据节点中，这也是Eureka在接下来需要面临的数据复制TTL问题）举一个典型的例子：EurekaClient使用了嵌入SDK的方式去注册和发现服务。对于客户端没有一个强一致的控制力，比如Eureka的服务发现用的是Ribbon。
Eureka根本原因
Eureka提供了一个弱一致服务视图，因为上段提到的每个数据服务节点都是一个Eureka服务器，导致它需要尽最大努力去复制这些，以尽可能的解决一致性问题。当一个Client注册到Server时，Server将会尝试把这个一个服务复制到其他的服务上，但并不保证此次操作的可靠性。服务注册有一个短的TTL，需要客户端和服务器保持心跳，不健康的服务或节点将会被服务器KILL掉，造成超时或被从注册中心移除。服务发现的请求将会被路由至其他服务，由于这种尽力的复制，可能会导致服务过期或数据丢失的问题。正是这种简易模型，以至于更加适用于简单的集群管理和他的高扩展性。
Consul功能
Consul提供了一些更加丰富的功能，包含了丰富的健康度检查，KV存储（PS：想到了WOT的咪咪5#滑稽），和多数据中心预知。Consul需要在每个数据中心都有一套服务，每个客户端都有一个代理，这一点和Ribbon相似。Consul的代理在大部分应用中和Consul没有太大关系。服务注册经过配置文件，DNS发现，或负载均衡来实现。
Consul优势
Consul 提供了强一致保证，是因为服务复制使用了Raft协议（Raft协议可以看我后续的文章）。Consul支持一套丰富的监看检查，包含TCP/HTTP/Nagios/Sensu的兼容脚本，或者像Eureka的TTL一样。客户端阶段参与了一些不太重要的健康度检查，比如分配了一些健康度检查的工作，和Eureka的集中式心跳不同，分布式心跳将对服务注册/发现带来更强的伸缩性和扩展性。服务发现请求会被路由到已被确定的Consul中，这样可以在默认情况下具有强一致性。同样也允许已被过时版本的客户端处理其服务，从而保证像Eureka一样线性和可伸缩性的工作。
Consul的强一致性
Consul的强一致性意味着它可以用来作为服务选举和集群服务协调时的服务控制(PS：像ZK一样用来做一致性处理的)。Eureka没有相似的功能，如果需要进行协调或具有更强一致性需求服务的话需要使用ZK来达到。
接下来我会将每个服务中心对比一下，会在接下来的章节中发出。
结论
Consul提供了面向微服务体系架构所需的工具包。包含了服务发现，还有丰富的健康度检查，锁，KV存储，多数据中心支持，事件系统和ACL等。但是Consul和生态系统工具都想要以最小的形式集成来满足需求，避免像Eureka一样需要通过客户端SDK的方式来集成。Eureka是Netflix OSS 套件中的一部分，他对Netflix来说，Netflix 需要他和同架构应用程序保持更高的耦合度。然而结果呢，Eureka只解决了一小部分问题，要想解决其他问题，正如上面所说的，需要其他部件来协同解决（ZK）。
有时间我会将这些挨个看一遍，再翻译出来，感兴趣的持续关注一下，哈哈。