eureka & zookeeper &consul均可以用来做注册中心和服务发现，总体上看就是一个理念不同的落地实现。
CAP设计理念
C：Consistency(强一致性)
A：Availability(可用性)
P：Partition tolerance(分区容错性)
CAP理论的核心是：一个分布式系统不可能同时很好地满足一致性，可用性和分区容错性这三个需求，因此，可以分成三大类，CA原则，CP原则，AP原则
CA：单点集群，满足一致性，可用性的系统，通常在扩展性上不太强大
CP：满足一致性，分区容错性的系统，通常性能不是特别高
AP：满足可用性，分区容错性的系统，通常可能对一致性要求低一些
现在大多数的分布式系统都需要保证分区容错性（P），CP指的是当某个微服务不可用时，会提示报错信息说明该服务不可用，可见保证强一致性会牺牲高可用性。AP指的是微服务不可用时，并不会报错，而是向用户返回之前缓存的数据，此时微服务真实数据和用户所看到的数据不一致，可见高可用性牺牲了数据一致性。所以，现在分布式系统的设计理念要么是CP(强一致性)，要么是AP(高可用性)
举个现实生活中的例子，淘宝在双十一时访问量巨大，那么我们应该选择CP还是AP呢？
选择CP，那么当一个微服务宕机了服务就会出现不可用的情况，而这不是我们想看到的，我们设想的是：我们允许一些数据出现差错，但是服务依然可用，过后及时修复即可，而这正是AP的设计理念，所以这个例子上我们选择AP
eureka & zookeeper &consul三者比较
| 组件名 | 语言 | CAP | 服务健康检查 | 对外暴露接口 | spring cloud集成 |
|---|---|---|---|---|---|
| Eureka | Java | AP | 可配支持 | HTTP | 已集成 |
| Consul | Go | CP | 支持 | HTTP/DNS | 已集成 |
| Zookeeper | Java | CP | 支持 | 客户端 | 已集成 |