1. CAP 理论
根据 CAP 理论，一个分布式系统不可能同时满足C(一致性)、A(可用性)和P(分区容错性)。
分区容错性在是分布式系统中必须要保证的，所以只能在A和C之间权衡。
2. Service Discovery
在选择 分布式框架 做 Service Discovery 时，
返回脏数据也比什么都没有好，
不能保证当发生短暂的network partition时，会发生什么情况（下面ZK 部分说明）
当分布式框架不可用时（网络等原因），即 A（可用性） 不满足时，就不能提供 Service Discovery 功能。
因此Service Discovery 对 A（可用性）要求高于 C（一致性）。
参考： https://medium.com/knerd/eureka-why-you-shouldnt-use-zookeeper-for-service-discovery-4932c5c7e764
2.1 zookeeper
Zookeeper保证的是CP
zk 不保证 A（虽然可以客户端缓存等方式补充 A）
当 network partition时，zk 重新 leader election 会花费较长时间（各looking节点经过几轮比较 zxid、sid 大小，票数超过 quorum 数量后，成为 leading 节点），在这期间服务注册功能不可用。
leader 选举数量小于quorum 的 partition里的服务器会自动关闭（连到这些服务的 Client 会收到 KeeperState.Disconnected 事件断开连接，虽然可以使用 zk 的 Read Only Mode读数据，但不能再写数据，提供注册服务功能 ）
2.2 Eureka
Eureka 是AP
保证 A（可用性）的前提下，所有 Eureka Server 节点都是对等节点，没有 leader选举、transaction log 复制。
就算部分 Eureka Server 节点宕机，甚至所有节点宕机（客户端缓存），也不会影响服务注册和发现功能，Eureka Client 可能使用脏数据（不保证 C（一致性））
network partition时（或 Eureka Server 统计心跳失败比例 15 分钟低于 85%），Eureka 进入 self-preservation mode，Eureka Server不再移除没收到心跳而过期的服务，同时还接收服务注册和发现功能
Eureka Client 虽然拿到的可能是脏数据（比如 服务提供者已经下线），会调用一个无效服务，但可以通过容错机制（重试、降级、熔断）等解决
在保证 A（可用性）的前提下，返回脏数据也比什么都没有好
2.2.1 Eureka FAQ
- leader replicate 给其他节点用什么保证成功，Ack 或 network ？
Eureka Server 没有 leader，所有都是对等节点。Eureka Server replicate 给其他节点依赖 network，成功时返回 200，失败时（多种情况）返回 404，调用端发现是 404会重新发起请求。- replicate 是同步还是异步？
同步- 数据 replicate 是否是多数派（quorum）？
不是 quorum 方式，是依赖于数据版本（应用实例的 lastDirtyTimestamp 大小）- 是否支持动态配置？
TODO Eureka Server 默认是配置文件，peerEurekaNodes 实例化这些节点。是否支持动态配置要再去看一下源码。
