笔记系列之注册中心组件的选择

基本功能

先了解一下那么多的注册中心组建，他们都需要提供哪些基本功能

• 注册中心的API

1. 服务注册接口：服务的提供方调用此接口完成服务的注册
2. 服务下线接口：服务的提供方调用此接口完成服务的下线
3. 心跳检查：服务的提供方调用此接口完成服务的状态上报
4. 服务查询：消费者通过订阅或者定时拉取来获得注册中心的服务列表信息
5. 服务变更查询：当服务发生变更的时候，消费者通过此接口获取最新的服务信息

• 服务的高可用
• 存储格式和位置
• 服务健康检查
• 服务状态变更通知
• 白名单机制：生产隔离、灰度发布

分布式系统一致性协议

 一致性协议的算法主要有：Paxos、Raft、ZAB

• Paxos：是一种基于消息传递的一致性算法，学习成本比较高，它与传统的主备方式最大的区别就是：Paxos只需要超过半数以上的副本都还在线且相互通信正常，就认定集群或者分布式系统就还能够提供正常服务，而且数据不会丢失
• Raft：它是Paxos的简化版，学习成本相较而言比较低，它跟Paxos一样，只要保证超过半数的节点都还正常就可以了，像Redis的哨兵模式其实就用到了Raft算法进行选举
• ZAB：是zookeeper实现分布式数据一致性的核心算法，ZAB借鉴了Paxos算法，它不是通用的算法，而是专门为zookeeper设计的支持崩溃恢复的原子广播协议

---

ZooKeeper

探讨

个人觉得ZooKeeper不适合做注册中心

不过，从另个角度来看，它作为一个分布式协同服务，ZooKeeper的地位是无可厚非的，也是不二的选择，但是对于分布式架构中的注册中心就显得有气无力了

因为ZooKeeper会有一种情况，当master节点因为网络故障或者其他原因与其他节点是去联系时，剩下的节点会重新选举leader，这个逻辑没问题，问题在于选举leader时间过长，而且选举过程中整个ZooKeeper集群是阻塞不可用的，这就会导致整个分布式系统直接宕机，在云部署环境下，因为网络问题使得整个zk集群失去master节点的事情出现还是可能性比较大的，虽然服务最终能恢复，但是长时间的服务不可用，在互联网行业，可能就会丢失大量订单流水，这就很难让架构系统接受这种情况的发生

综上所述：如果是作为注册中心，可用性A要大于一致性C

其实了解ZooKeeper的都知道，它是遵循CP原则的，它能够保证数据一致性，但是保证不了机器在下线或者宕机时服务的可用性

---

疑问：为啥zk不能是AP呢？

原因是zk使用到的是ZAB一致性算法，所有的设计都是为了实现强一致性，如果是用在分布式协调系统，用zk是完全没有毛病的，但是如果用于注册中心的服务注册与发现，就有点不太合适了

---

Eureka

Eureka的优势和运行原理等知识点，在这个标题下就不做赘述了哈

通过Eureka的了解，他的设计思路就是为了解决注册中心的稳定性和高可用性

Eureka为了保证注册中心的高可用性，容忍了数据的非强一致性，服务节点、Client-Server之间的数据都有可能出现不一致的问题，所以Eureka比较适用于跨机房、对注册中心服务可用性要求较高的使用场景，它也是专门为注册中心服务的微服务组件，出生就是注册中心

---

Nacos 

关于Nacos的基础知识，就移驾到我博客下Nacos专栏去看一下吧，这里就不做赘述了

Nacos的话，个人觉得是最好的一个注册中心，只是个人觉得哈，非喜勿喷

为啥呢，原因如下：

• 是阿里出品，开源的，支持基于DNS和RPC的服务发现
• 最主要的是它支持CP也支持AP，是可以配置的，毕竟灵活
• 还有一个比较有趣的是，Nacos除了提供了注册中心的注册和发现功能，还提供了类似SpringCloudConfig远程配置中心的功能
• 也有一套比较适用于中国人开发和使用的Web可视化页面，可以更直观、更精确的配置和观察节点信息

---

Consul 

这个基本知识同样不做赘述了

Consul和ZooKeeper一样，遵循的是CP模型，它使用的是Raft来保证强一致性，而放弃了可用性

---

ETCD 

ETCD也是支持CP模型的，同样不支持可用性 

---

综上所述

在分布式架构中，牺牲可用性的ZooKeeper、Consul、ETCD在服务发现场景并没有多大的优势，反而Eureka和Nacos强调可用性，毕竟在服务发现场景中，可用性的优先级要大于一致性

还有以下几种原因：

1、CP和AP，在注册中心下，首选AP，所以只能从Eureka和Nacos中选择，那这俩怎么选择呢？我们开发使用注册中心或者使用其他工具第一个目的就是为了节省开发量，那就很显然，Nacos为开发节省了很多事情，如果是我，首选Nacos

2、ETCD和Consul是用GO写的，而其他几个都是JAVA写的，论后期自行开发和维护再或者是找框架的bug，做JAVA的也很好入手

3、高可用的话，没啥说，都支持

4、社区活跃度的话，Eureka已经不更新了，而Consul业界都可以代替Eureka了，其他的都还很活跃，尤其是Nacos，毕竟是阿里出品嘛