自我保护模式
当节点间网络中断时会发生什么？
在节点间网络中断的情况下，可能会发生一些事情。
-节点间的心跳失败，服务检测到这种情况并进入自我保护模式（self-preservation）保护当前状态。
-注册操作可能发生在孤立的服务上，这种情况会导致部分客户端可以拿到新的注册信息而有部分则拿不到。
当网络连接恢复到稳定状态后，服务会自动退出自我保护模式并进行自我修复。一旦节点间正常通信，注册信息将自动完成节点间的同步。根本原则是，在网络发生中断期间，服务应尽可能保持可用可恢复，尽管在此期间客户端会拿到不同的服务信息。
为什么不使用HA proxy进行负载均衡？
由于AWS自身问题，实例会频繁上下线。ASGs可以根据流量来扩展或撤下实例。假如我们使用HAproxy则会面对这样的挑战，需要处理这种动态特性。而这正是Eureka所具备的。
有一种情况，当需要作为会话保持有状态的中间层代理时，可以使用HAProxy对Eureka进行补充。但是大多数情况下我们的中间层服务是无状态的，因此我们没有理由在会增加网络跳转的情况依旧使用代理。另一个原因是Eureka client会缓存拿到的注册表信息，使得系统具备弹性。通过HAProxy就存在这方面的不足，系统没有自我恢复能力。
为什么不使用Curator/Zookeeper做服务注册？
Zookeeper和Eureka确实提供了一些重叠的功能，特别是复制注册信息这方面。Eureka也可以用Zookeeper做注册信息缓存和同步，但这只是Eureka提供的一小部分功能。 Eureka还提供了信息同步之外的其他功能：
-提供注册、心跳、注销操作等REST接口。
-能够在集群负载复杂的EIP环境下，保持信息及时更新，以及部署回滚，以及弹性伸缩和自我恢复功能等。
-针对不稳定网络状况的容灾和自我恢复功能。 Zookeeper的强大之处在于它的选举（leader election），命令更新（ordered updates），以及分布式一致性保证（distributed synchronization along with its consistency guarantees (quorums)）。
除了注册表复制之外，上述任何一项都不适用与Eureka所能解决的如下问题：
-需要有一个方法像Eureka一样为Zookeeper分配EIPs。
-处理当Zookeeper失效的情况。
另外，Eureka是建立在没有依赖任何外部组件的基础上进行的。
-大部分服务依赖Eureka启动。
-降低复杂度。
-避免另一个故障点。
