1.介绍

现在提到做服务发现、分布式协调同步可以想到很多工具:zookeeper、eureka、etcd、Consul(直接集成了服务发现的系统,不用自己实现)等等。很多时候选择哪一个,关键是看对CAP的选择。

本篇主要简单讨论下zk和eureka这两个。

2. 关于服务发现

根据 服务发现方案梳理及NetflixEureka简介一文可知,做分布式下的服务发现还是使用eureka更好,也就是AP特性的分布式协调工具。

在我们的讨论中, zk就是CP类工具的代表,而eureka就是AP类工具的代表。

CP不适合服务发现的原因主要是:采用CP的方式,有时候因为网络故障就无法返回可用的主机(其实某些主机是健康的,只不过由于网络故障和CP的特性,导致无法返回可用服务器信息)。而采用AP就不一样了,假设产生网络故障,仍然可以拿到可用服务器的信息,只不过有些信息可能不一致。而对于服务发现来讲,这种不一致信息远比得不到信息要好得多。因为服务地址可能变动不会非常频繁,很多时候这种不一致信息仍然是正确的。

3. 关于ZK

毋容置疑,ZK是个伟大的产品。其在分布式服务协同领域是最佳选择。只不过在服务发现领域不太适合其CP特性而已。虽然有评论说其也可以开启AP特性,不过好像仍然不是设计的很完美。

ZK很成熟、资料很多,这是它的优点。

当然就算不讨论CAP,ZK也有其本身维护上的困难,需要正确的使用ZK。ZK偶尔甚至有选主失败的情况。

4. 关于eureka

网络分割问题:当网络交换机出故障会导致不同子网间通讯中断。网络把集群分割成了独立的子网。

eureka特点:

4.1 节点平等,容忍N-1故障

Eureka各个节点都是平等的,几个节点挂掉不会影响正常节点的工作,剩余的节点依然可以提供注册和查询服务。区别ZK容忍(N+1)/2个错误

4.2 自我保护机制:

Eureka还有一种自我保护机制,如果在15分钟内超过85%的节点都没有正常的心跳,那么Eureka就认为客户端与注册中心出现了网络故障,此时会出现以下几种情况:
没有正常的心跳,那么Eureka就认为客户端与注册中心出现了网络故障,此时会出现以下几种情况:

  1. Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务
  2. Eureka仍然能够接受新服务的注册和查询请求,但是不会被同步到其它节点上(即保证当前节点依然可用)
  3. 当网络稳定时,当前实例新的注册信息会被同步到其它节点中

因此, Eureka可以很好的应对因网络故障导致部分节点失去联系的情况,而不会像zookeeper那样使整个注册服务瘫痪。

Eureka作为单纯的服务注册中心来说要比zookeeper更加“专业”,因为注册服务更重要的是可用性,我们可以接受短期内达不到一致性的状况。不过Eureka目前1.X版本的实现是基于servlet的Java web应用,它的极限性能肯定会受到影响。期待正在开发之中的2.X版本能够从servlet中独立出来成为单独可部署执行的服务。

参考资料:

  1. 服务发现方案梳理及NetflixEureka简介
  2. 为什么不应该使用ZooKeeper做服务发现
  3. 云端中间层负载均衡工具 Eureka
  4. Spring Cloud Netflix Eureka源码导读与原理分析