前言

CAP定理

CAP定理已经深入每个开发者心里，我们一起回顾下，下面摘自维基百科定义。

CAP定理（CAP theorem），又被称作布鲁尔定理（Brewer's theorem），它指出对于一个分布式计算系统来说，不可能同时满足以下三点：

• 一致性（Consistency）：等同于所有节点访问同一份最新的数据副本
• 可用性（Availability）每次请求都能获取到非错的响应——但是不保证获取的数据为最新数据
• 分区容错性（Partition tolerance）以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择

举例说明

例如：有5个节点被网络分区，分区1有三个节点，分区2有两个节点。

• 如果保证两个分区节点都可用（AP），由于网络不通，那么无法保证两个分区数据一致性（CP）
• 如果保证两个分区数据一致性（CP），由于网络不通，那么会导致至少一个分区不可用
• 如果既想保证所有节点一致性，还要保证节点都可用（CA），那么网络就必须是好的，不能出现网络分区，失去了分区容错性（P）

因此，三者不可兼得。

架构图示

『服务提供者』将自己在注册中心注册，『服务消费者』通过服务名将『服务提供者』的节点找出来，最后向『服务提供者』发起RPC调用。

注册中心本质在提供服务和节点之间的注册查询服务，也就是说注册中心是服务之间交互辅助作用。

其他功能

除了注册中心提供基本的服务注册和节点查询外。我们还想注册中心有以下功能：

健康检查

注册中心返回的服务提供者节点是好的，是能提供服务的，不健康的就别提供了。

健康保护

虽然不想你把不好的节点给我，但是如果服务大部分节点都不好了，流量全部偏移到健康节点，可能把健康的节点也打挂掉。

所以需要一个不好节点的范围加以保护，避免雪崩。

流量分配

希望注册中心能够支持流量均衡，并能够支持按照一定的规则在注册节点中分配流量。

故障场景

当注册中心发生故障时，需要尽可能保障服务调用的可用性。下面分几种场景

注册中心瘫痪

这种场景是指整个注册中心机房/可用区故障或者注册中心本身故障无法对外提供服务。

• 新服务提供者注册不上去
• 新启动的服务消费者订阅不了

备注： 这种场景应该只影响新启动的『服务提供者』和『服务消费者』，对已有的服务不应该产生影响，需要故障演练做到不影响。

注册中心分区

当注册中心发生分区时，根据上面CAP定理和示例，有两种选择，选择CP或者AP。

• 选择两个分区数据一致性（CP），牺牲至少一个分区不可用
• 选择两个分区节点都可用（AP），牺牲两个分区数据一致性

选择两个分区数据一致性（CP）

假如其中一个分区（不可用），本分区的的服务不能再从注册中心获取节点信息，类似本注册中心分区全部瘫痪。此时要求服务能够剥离注册中心后不影响服务之间调用。

选择两个分区节点都可用（AP）

两个分区数据一致性，分区1和分区2的注册节点可能不同，从而造成流量可能发生倾斜。

备注：从架构来看，看发生网络分区，选择AP发生的流量倾斜远远好于选择CP导致分区的不可用。尽管分区不可用有一些缓存手段能保证服务可以继续交互。

Zookeeper使用通过Zab协议保证数据的一致性，实现了CAP定理中的CP，通过上面分析注册中心更适合AP。至于保证一致性的在网络分区时有分区不可用，上面已经分析过。

擅长

Zookeeper被广泛的用在分布式协调中，例如：Pulsar、Kafka、Flink、Hadoop等。

不足

性能

由于Zookeeper的写操作由Leader负责，我们线上9个zk节点，只有一个节点负责写请求，增加节点并不能分担Leader的写压力，那意味着只要服务到了一个量级必然会影响zk集群的性能。

多语言

除了Java语言外，缺少其他语言对Zookeeper客户端良好封装，给使用者带来一定的挑战。

心跳检测

当Zookeeper作为注册中心时，依赖其基于session的心跳检测不能证明服务节点是不是好的。换句话说，使用zk的心跳作为注册中心健康检测是不合适的。