CAP理论

开篇先过一下作为分布式系统的基础理论的CAP理论,它描述的是一个分布式系统在以下三个特性中：

一致性(Consistency)：所有节点在同一时间具有相同的数据
可用性(Availability)：保证每个请求不管成功或者失败都有响应
分隔容忍(Partition tolerance)：系统中任意信息的丢失或失败不会影响系统的继续运作

最多满足其中的两个特性。也就是下图所描述的。分布式系统要么满足CA,要么CP，要么AP。无法同时满足CAP。

微服务组件

注册中心

就我个人认为，应该属于微服务的大脑部分，
注册中心的选型，目前要考虑的一个因素就是CAP理论

Apache Zookeeper -> CP

Apache Zookeeper 听说之前是使用比较广泛的，经常是Zookeeper + Doubbo这个无敌组合，当然，这个典型的套餐官网上也是有推荐的
在Dubbo官网中有这一句话

当然，在官网处还有这一句兼容性声明说明：

因 2.0.8 最初设计的 zookeeper 存储结构不能扩充不同类型的数据，2.0.9 版本做了调整，所以不兼容，需全部改用 2.0.9 版本才行，以后的版本会保持兼容 2.0.9。2.2.0 版本改为基于 zkclient 实现，需增加 zkclient 的依赖包，2.3.0 版本增加了基于 curator 的实现，作为可选实现策略。

建议使用 2.3.3 以上版本的 zookeeper 注册中心客户端

[Consul] -> CP

Consul 是一种服务网格解决方案，提供具有服务发现、配置和分段功能的全功能控制平面。这些功能中的每一个都可以根据需要单独使用，也可以一起使用以构建完整的服务网格。Consul 需要一个数据平面并支持代理和本地集成模型。Consul 附带了一个简单的内置代理，因此一切都可以开箱即用，而且还支持 3rd 方代理集成，例如 Envoy。

In CAP terms, Consul uses a CP architecture, favoring consistency over availability. (在CAP术语中，Consul 使用 CP 架构，支持一致性而不是可用性。)

Spring Cloud Eureka -> AP

Spring Cloud Netflix 在设计 Eureka 时就紧遵AP原则（尽管现在2.0发布了，但是由于其闭源的原因，但是目前 Ereka 1.x 任然是比较活跃的）。

Eureka Server 也可以运行多个实例来构建集群，解决单点问题，但不同于 ZooKeeper 的选举 leader 的过程，Eureka Server 采用的是Peer to Peer 对等通信。这是一种去中心化的架构，无 master/slave 之分，每一个 Peer 都是对等的。在这种架构风格中，节点通过彼此互相注册来提高可用性，每个节点需要添加一个或多个有效的 serviceUrl 指向其他节点。每个节点都可被视为其他节点的副本。

Eureka 服务器没有后端存储，但注册中心中的服务实例都必须发送心跳以保持其注册最新（因此这可以在内存中完成）。客户端还有一个 Eureka 注册的内存缓存（因此他们不必为每个服务请求都去注册中心）。