生态
在微服务的开发过程中，如果使用的是 Dubbo 那就必须使用到 Zookeeper ，在使用 Spring Cloud Eureka 时，自然其功能更强大得多。Spring Cloud Eureka 后来者居上，Dubbo 早在几年前停止了维护，在其停止了维护的几年里正是互联网发展的大好时期，Eureka 借机快速发展，夺得了一大片市场，可以说已经超越了 Dubbo 了，17 年的时候，阿里巴巴又突然宣布重启对 Dubbo 的维护，在其重启的发布会上，其主导维护者也表示，将希望加入 Eureka 的生态…
CAP 定理
原理
一个系统不可能同时满足一致性（C）、可用性(A)、分区容错性（P）
三个指标
- 一致性：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）。
- 可用性：在一个分布式系统的集群中一部分节点故障后，该集群是否还能够正常响应客户端的读写请求。（对数据更新具备高可用性）。
- 分区容错性：大多数的分布式系统都分布在多个子网络中，而每个子网络就叫做一个区（partition）。分区容错的意思是，区间通信可能失败。在一个分布式系统中一般分区容错是无法避免的，因此可以认为 CAP 中的 P 总是成立的。CAP 理论告诉我们，在 C 和 A 之间是无法同时做到。
Zookeeper 保证 CP
- 任何时候对 Zookeeper 的访问请求能得到一致的数据结果，同时系统对网络分割具备容错性
- 在使用 Zookeeper 获取服务列表时，如果此时的 Zookeeper 集群中的 Leader 宕机了，该集群就要进行 Leader 的选举，又或者 Zookeeper 集群中半数以上服务器节点不可用（例如有三个节点，如果节点一检测到节点三挂了 ，节点二也检测到节点三挂了，那这个节点才算是真的挂了），那么将无法处理该请求。所以说，Zookeeper 不能保证服务可用性。
Eureka 保证 AP
- 各个节点是平等的，几个节点挂掉，其他节点依然可以提供服务，首先报证可用性。
- 每个 Eureka Client 本地都有一份它最新获取到的服务注册表的缓存信息，即使所有的 Eureka Server 都挂掉了，依然可以根据本地缓存的服务信息正常工作。
- 如果 Eureka 服务节点在短时间里丢失了大量的心跳连接（注：可能发生了网络故障），那么这个 Eureka 节点会进入自我保护模式。 此时，这个 Eureka 节点对于新的服务还能提供注册服务，对于”死亡“的仍然保留，以防还有客户端向其发起请求。当网络故障恢复后，这个 Eureka 节点会退出自我保护模式。
- Eureka 不能保证每次获取的服务列表都是最新的
总结
对于服务发现来讲，保证服务的高可用尤为重要，哪怕返回前几分钟的服务信息，也比出现网络故障要好。