浅谈SpringCloud里面的Eureka(和ZooKeeper的对比) |我的资源库露水湾

Spring Cloud Eureka

我们使用微服务，微服务的本质还是各种 API 接口的调用，那么我们怎么产生这些接口、产生了这些接口之后如何进行调用那？如何进行管理哪？

答案就是 Spring Cloud Eureka，我们可以将自己定义的 API 接口注册到 Spring Cloud Eureka 上，Eureka 负责服务的注册于发现，如果学习过 Zookeeper 的话，就可以很好的理解，Eureka 的角色和 Zookeeper 的角色差不多，都是服务的注册和发现，构成 Eureka 体系的包括：服务注册中心、服务提供者、服务消费者。

上图中描述了（图片来源于网络）：

1、两台 Eureka 服务注册中心构成的服务注册中心的主从复制集群；
2、然后服务提供者向注册中心进行注册、续约、下线服务等；
3、服务消费者向 Eureka 注册中心拉去服务列表并维护在本地（这也是客户端发现模式的机制体现！）；
4、然后服务消费者根据从 Eureka 服务注册中心获取的服务列表选取一个服务提供者进行消费服务。

1、在 Eureka 平台中，如果某台服务器宕机，Eureka 不会有类似于 ZooKeeper 的选举 leader 的过程；客户端请求会自动切换到新的 Eureka 节点；当宕机的服务器重新恢复后，Eureka 会再次将其纳入到服务器集群管理之中；而对于它来说，所有要做的无非是同步一些新的服务注册信息而已。所以，再也不用担心有“掉队”的服务器恢复以后，会从 Eureka 服务器集群中剔除出去的风险了。Eureka 甚至被设计用来应付范围更广的网络分割故障，并实现“0”宕机维护需求。（多个 zookeeper 之间网络出现问题,造成出现多个 leader，发生脑裂）当网络分割故障发生时，每个 Eureka 节点，会持续的对外提供服务（注：ZooKeeper 不会）：接收新的服务注册同时将它们提供给下游的服务发现请求。这样一来，就可以实现在同一个子网中（same side of partition），新发布的服务仍然可以被发现与访问。

2、正常配置下，Eureka 内置了心跳服务，用于淘汰一些“濒死”的服务器；如果在 Eureka 中注册的服务，它的“心跳”变得迟缓时，Eureka 会将其整个剔除出管理范围（这点有点像 ZooKeeper 的做法）。这是个很好的功能，但是当网络分割故障发生时，这也是非常危险的；因为，那些因为网络问题（注：心跳慢被剔除了）而被剔除出去的服务器本身是很”健康“的，只是因为网络分割故障把 Eureka 集群分割成了独立的子网而不能互访而已。

幸运的是，Netflix 考虑到了这个缺陷。如果 Eureka 服务节点在短时间里丢失了大量的心跳连接（注：可能发生了网络故障），那么这个 Eureka 节点会进入”自我保护模式“，同时保留那些“心跳死亡“的服务注册信息不过期。此时，这个 Eureka 节点对于新的服务还能提供注册服务，对于”死亡“的仍然保留，以防还有客户端向其发起请求。当网络故障恢复后，这个 Eureka 节点会退出”自我保护模式“。所以 Eureka 的哲学是，同时保留”好数据“与”坏数据“总比丢掉任何”好数据“要更好，所以这种模式在实践中非常有效。

3、Eureka 还有客户端缓存功能（注：Eureka 分为客户端程序与服务器端程序两个部分，客户端程序负责向外提供注册与发现服务接口）。所以即便 Eureka 集群中所有节点都失效，或者发生网络分割故障导致客户端不能访问任何一台 Eureka 服务器；Eureka 服务的消费者仍然可以通过 Eureka 客户端缓存来获取现有的服务注册信息。甚至最极端的环境下，所有正常的 Eureka 节点都不对请求产生相应，也没有更好的服务器解决方案来解决这种问题
时；得益于 Eureka 的客户端缓存技术，消费者服务仍然可以通过 Eureka 客户端查询与获取注册服务信息，这点很重要。
4、Eureka 的构架保证了它能够成为 Service 发现服务。它相对与 ZooKeeper 来说剔除了 Leader 节点的选取或者事务日志机制，这样做有利于减少使用者维护的难度也保证了 Eureka 的在运行时的健壮性。而且 Eureka 就是为发现服务所设计的，它有独立的客户端程序库，同时提供心跳服务、服务健康监测、自动发布服务与自动刷新缓存的功能。但是，如果使用 ZooKeeper 你必须自己来实现这些功能。Eureka 的所有库都是开源的，所有人都能看到与使用这些源代码，这比那些只有一两个人能看或者维护的客户端库要好。