Spring Cloud Netflix之Eureka 相关概念

为什么不应该使用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剔除。