为什么不应该使用ZooKeeper做服务发现
英文链接:
Eureka! Why You Shouldn’t Use ZooKeeper for Service Discovery:
http://www.knewton.com/tech/blog/2014/12/eureka-shouldnt-use-zookeeper-service-discovery/
中文链接:
http://blog.csdn.net/jenny8080/article/details/52448403
Eureka vs. Zookeeper：
https://groups.google.com/forum/#%21topic/eureka_netflix/LXKWoD14RFY
Netflix Shares Cloud Load Balancing And Failover Tool: Eureka!
https://techblog.netflix.com/2012/09/eureka.html
在分布式系统领域有个著名的 CAP定理（C- 数据一致性；A-服务可用性；P-服务对网络分区故障的容错性，这三个特性在任何分布式系统中不能同时满足，最多同时满足两个）；
ZooKeeper是个 CP的，即任何时刻对ZooKeeper的访问请求能得到一致的数据结果，同时系统对网络分割具备容错性;
在Eureka平台中，如果某台服务器宕机，Eureka不会有类似于ZooKeeper的选举leader的过程；客户端请求会自动切换 到新的Eureka节点；当宕机的服务器重新恢复后，Eureka会再次将其纳入到服务器集群管理之中,
所以，再也不用担心有“掉队”的服务器恢复以后，会从Eureka服务器集群中剔除出去的风险了。Eureka甚至被设计用来应付范围更广 的网络分割故障，并实现“0”宕机维护需求。当网络分割故障发生时，每个Eureka节点，会持续的对外提供服务（注：ZooKeeper不会）：接收新 的服务注册同时将它们提供给下游的服务发现请求。这样一来，就可以实现在同一个子网中（same side of partition），新发布的服务仍然可以被发现与访问。
注： 高延迟与网络分割问题 原文为network partitions。意思是当网络交换机出故障会导致不同子网间通讯中断;
正常配置下，Eureka内置了心跳服务，用于淘汰一些“濒死”的服务器；如果在Eureka中注册的服务， 它的“心跳”变得迟缓时，Eureka会将其整个剔除出管理范围（这点有点像ZooKeeper的做法）。这是个很好的功能，但是当网络分割故障发生时， 这也是非常危险的；因为，那些因为网络问题（注：心跳慢被剔除了）而被剔除出去的服务器本身是很”健康“的，只是因为网络分割故障把Eureka集群分割 成了独立的子网而不能互访而已。
如果Eureka服务节点在短时间里丢失了大量的心跳连接（注：可能发生了网络故障），那么这个 Eureka节点会进入”自我保护模式“，同时保留那些“心跳死亡“的服务注册信息不过期。此时，这个Eureka节点对于新的服务还能提供注册服务，对 于”死亡“的仍然保留，以防还有客户端向其发起请求。当网络故障恢复后，这个Eureka节点会退出”自我保护模式“。所以Eureka的哲学是，同时保 留”好数据“与”坏数据“总比丢掉任何”好数据“要更好，所以这种模式在实践中非常有效。
Eureka还有客户端缓存功能（注：Eureka分为客户端程序与服务器端程序两个部分，客户端程序负责向外提供注册与发现服务接口）。 所以即便Eureka集群中所有节点都失效，或者发生网络分割故障导致客户端不能访问任何一台Eureka服务器；Eureka服务的消费者仍然可以通过 Eureka客户端缓存来获取现有的服务注册信息。甚至最极端的环境下，所有正常的Eureka节点都不对请求产生相应，也没有更好的服务器解决方案来解 决这种问题时；得益于Eureka的客户端缓存技术，消费者服务仍然可以通过Eureka客户端查询与获取注册服务信息，这点很重要; 由于Eureka客户端具有注册表缓存信息，所以即使所有的Eureka服务器都停机，它们也可以运行得很好;
进一步了解 Eureka
Eureka基本架构图
architecture-overview
上图简要描述了Eureka的基本架构，由3个角色组成：
-
Eureka Server
- 提供服务注册和发现
-
Service Provider
- 服务提供者，服务启动的时候会将自己的服务信息注册到Eureka
-
Service Consumer
- 服务消费者，从Eureka中获取已注的服务信息，用于调用服务生产者
需要注意一点是：一个Service Provider既可以是Service Consumer，也可以是Service Provider。
集群模式下的Eureka
上图更进一步的展示了3个角色之间的交互。
- Service Provider会向Eureka Server做Register（服务注册）、Renew（服务续约）、Cancel（服务下线）等操作。
- Eureka Server之间会做注册服务的同步，从而保证状态一致
- Service Consumer会向Eureka Server获取注册服务列表，并消费服务
Eureka的工作原理
Eureka 组件分为两部分：Eureka server和 Eureka client。而客户端又分为 Application Service 客户端和 Application Client 客户端两种。
Eureka 的工作机制每个 region 都有自己的 Eureka 服务器集群，每个 zone 至少要有一个 Eureka 服务器以应对 zone
名词解释
Renew:续约
Renew（服务续约）操作由Service Provider定期调用，类似于heartbeat。目的是隔一段时间Service Provider调用接口，告诉Eureka Server它还活着没挂，不要把它踢掉。通俗的说就是它们两之间的心跳检测，
避免服务提供者被剔除掉
Cancel（服务下线）
一般在Service Provider挂了或shut down的时候调用，用来把自身的服务从Eureka Server中删除，以防客户端调用到不存在的服务。
Fetch Registries(获取注册信息)，
Fetch Registries由Service Consumer(服务消费者)调用，用来获取Eureka Server上注册的服务info。
Eviction(剔除)
Eviction（失效服务剔除）用来定期在Eureka Server检测失效的服务，检测标准就是超过一定时间没有Renew的服务。
Eureka架构图
Eureka架构图如下图所示，github地址:https://github.com/netflix/eureka
document地址:https://github.com/Netflix/eureka/wiki/Eureka-at-a-glance
Application Service 在启动时注册到 Eureka 服务器，之后每 30 秒钟发送心跳以更新自身状态,即Renew(续约)。如果该客户端没能发送心跳更新，它将在 90 秒之后被其注册的 Eureka 服务器剔除，即Eviction(剔除)。
来自任意 zone 的 Application Client 可以获取这些注册信息(每隔 30 秒查看一次)并依此定位到在任何区域可以给自己提供服务的提供者(即Fetch Registries)，进而进行远程调用。
服务提供者本身携带的Eureka Client既能服务注册，服务续约，也能通过client定位服务和调用其它的服务。
Renew(服务续约)
服务续约 Renew操作会在Service Provider端定期发起，用来通知Eureka Server自己还活着
eureka.instance.leaseRenewalIntervalInSeconds
Renew频率。默认是30秒，也就是每30秒会向Eureka Server发起Renew操作。
eureka.instance.leaseExpirationDurationInSeconds
服务失效时间。默认是90秒，也就是如果Eureka Server在90秒内没有接收到来自Service Provider的Renew操作，就会把Service Provider剔除。