Eureka、Zookeeper和Consul 的区别

主要区别的话，看CAP选择，大部分注册中心，就是在这个定理去选择的，具体怎么选择，看下文

CAP定理：指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可同时得到。

一致性（C）：在分布式系统中的全部数据备份，在同一时刻是否一样的值。（全部节点在同一时间的数据彻底一致，越多节点，数据同步越耗时）

可用性（A）：负载过大后，集群总体是否还能响应客户端的读写请求。（服务一直可用，并且是正常响应时间）

分区容错性（P）：分区容忍性，就是高可用性，一个节点崩了，并不影响其它的节点（100个节点，挂了几个，不影响服务，越多机器越好）

再进一步解释CAP理论： 就是说在分布式存储系统中，最多只能实现上面的两点。而因为当前的网络硬件确定会出现延迟丢包等问题，因此分区容忍性是咱们必须须要实现的。因此咱们只能在一致性和可用性之间进行权衡

C A 知足的状况下，P不能知足的缘由：
数据同步(C)须要时间，也要正常的时间内响应(A)，那么机器数量就要少，因此P就不知足

CP 知足的状况下，A不能知足的缘由：
数据同步(C)须要时间, 机器数量也多(P)，可是同步数据须要时间，因此不能再正常时间内响应，因此A就不知足

AP 知足的状况下，C不能知足的缘由：
机器数量也多(P)，正常的时间内响应(A)，那么数据就不能及时同步到其余节点，因此C不知足

使用场景 就是楼主的注册中心选择：
Zookeeper和Consul ：CP设计，保证了一致性，集群搭建的时候，某个节点失效，则会进行选举行的leader，或者半数以上节点不可用，则没法提供服务，所以可用性无法知足

Eureka：AP原则，无主从节点，一个节点挂了，自动切换其余节点可使用，去中心化

结论：分布式系统中P,确定要知足，因此只能在CA中二选一
没有最好的选择，最好的选择是根据业务场景来进行架构设计
若是要求一致性，则选择zookeeper、Consul，如金融行业
若是要去可用性，则Eureka，如电商系统

 

--------------------------------------------------------------------------

 

最大的区别是Eureka保证AP, Consul为CP。

 

Consul强一致性(C)带来的是：

1. 服务注册相比Eureka会稍慢一些。由于Consul的raft协议要求必须过半数的节点都写入成功才认为注册成功
2. Leader挂掉时，从新选举期间整个consul不可用。保证了强一致性但牺牲了可用性。

 

Eureka保证高可用(A)和最终一致性：

1. 服务注册相对要快，由于不须要等注册信息replicate到其余节点，也不保证注册信息是否replicate成功
2. 当数据出现不一致时，虽然A, B上的注册信息不彻底相同，但每一个Eureka节点依然可以正常对外提供服务，这会出现查询服务信息时若是请求A查不到，但请求B就能查到。如此保证了可用性但牺牲了一致性。

 

其余方面，eureka就是个servlet程序，跑在servlet容器中; Consul则是go编写而成。