简介
Eureka是Netflix开源的服务发现组件,自身为一个基于REST风格的服务。包含SERVER和
CLIENT两部分。Spring Cloud将它集成在子项目Spring Cloud Netflix中，实现微服务的注册与发现。结构如图:
Paste_Image.png
由图可知:
① Eureka Server提供服务发现能力，微服务启动时，会向Server注册相关信息（如端口、IP、服务名称等），而Server会将其存储起来。
② 微服务启动后，会周期性的（默认30秒）向Eureka Server发送心跳以续约自己的“租期”。如果Eureka Server在一定时间内没有接收到某个微服务实例的心跳（默认为90秒）则会注销该实例。（"=. = " 就和咱租房子一样，连续几次不交房租总会被撵出去的~）
③ 默认情况下，咱Eureka Server也是Eureka Client。多个Server实例之间通过互相之间的复制来实现服务注册表中数据的同步。
④ Eureka Client会缓存服务注册表中的信息。这样的好处可以降低Eureka Server的抗压能力，并且这样就算Server的所有节点都冗掉，消费者依旧可以使用缓存中的信息找到对应的服务提供者并完成调用。
结论：Eureka通过检查心跳，客户端缓存等机制，提高了系统的灵活性、可用性等。
==============================================================
Eureka与Zookeeper的简单对比
Zookeeper:
在分布式系统领域著名的 CAP定理中(C- 数据一致性;A-服务可用性;P-服务对网络分区故障的容错性，这三个特性在任何分布式系统中不能同时满足，最多同时满足两个);ZooKeeper是个 CP的，即任何时刻对ZooKeeper的访问请求能得到一致的数据结果，同时系统对网络分割具备容错性;但是它不能保证每次服务请求的可用性(在极端环境下，ZooKeeper可能会丢弃一些请求，消费者程序需要重新请求才能获得结果,如网络原因以及硬件原因造成)。
Eureka:
Eureka在处理时，满足CP的同时，因为他的内置心跳机制,如果短时间内丢失大量的心跳连接【可能发生硬件故障，网络故障等】,那么这个Eureka节点将会进入“自我保护”模式，此时将保留“死亡心跳”的服务注册信息不过期。此时，这个Eureka节点对于新的服务还能提供注册服务，对 于”死亡“的仍然保留，以防还有客户端向其发起请求。当网络故障恢复后，这个Eureka节点会退出”自我保护模式“。所以Eureka的哲学是，同时保 留”好数据“与”坏数据“总比丢掉任何”好数据“要更好.
注：文章参考官网、个人理解以及相关博客整理
