为什么需要注册中心？

在RPC服务和微服务诞生的时候，就已经有了注册中心的需求了。

在最初的架构体系中，集群的概念还不那么流行，且机器数量也比较少，此时直接使用DNS+Nginx就可以满足几乎所有RESTful服务的发现。相关的注册信息直接配置在Nginx。但是随着微服务的流行与流量的激增，机器规模逐渐变大，并且机器会有频繁的上下线行为，这种时候需要运维手动地去维护这个配置信息是一个很麻烦的操作。所以开发者们开始希望有这么一个东西，它能维护一个服务列表，哪个机器上线了，哪个机器宕机了，这些信息都会自动更新到服务列表上，客户端拿到这个列表，直接进行服务调用即可。这个就是注册中心

CAP理论

CAP理论是分布式系统中一个很重要的理论，它描述的是一个分布式系统最多只能满足CAP中的两个条件，不可能同时满足三个条件

• C（Consistency）：这里指的是强一致性。保证在一定时间内，集群中的各个节点会达到较强的一致性，同时，为了达到这一点，一般会牺牲一点响应时间。而放弃C也不意味着放弃一致性，而是放弃强一致性。允许系统内有一定的数据不一致情况的存在
• A (Avalibility)：可用性。意味着系统一直处于可用状态。个别节点的故障不会影响整个服务的运作
• P（Partition Tolerance)：分区容忍性。当系统出现网络分区等情况时，依然能对外提供服务。想到达到这一点，一般来说会把数据复制到多个分区里，来提高分区容忍性。这个一般是不会被抛弃的

市面上比较流行注册中心有：Zookeeper，Eureka，Consul，Nacos

对比项目	Nacos	Eureka	Consul	CoreDNS	Zookeeper
一致性协议	CP+AP	AP	CP	—	CP
健康检查	TCP/HTTP/MYSQL/Client Beat	Client Beat	TCP/HTTP/gRPC/Cmd	—	Keep Alive
负载均衡策略	权重/metadata/Selector	Ribbon	Fabio	RoundRobin	—
雪崩保护	有	有	无	无	无
自动注销实例	支持	支持	不支持	不支持	支持
访问协议	HTTP/DNS	HTTP	HTTP/DNS	DNS	TCP
监听支持	支持	支持	支持	不支持	支持
多数据中心	支持	支持	支持	不支持	不支持
跨注册中心同步	支持	不支持	支持	不支持	不支持
SpringCloud集成	支持	支持	支持	不支持	不支持
Dubbo集成	支持	不支持	不支持	不支持	支持
K8S集成	支持	不支持	支持	支持	不支持

上图可以描述市面流行注册中心的一些特性

Zookeeper

Apache Zookeeper所选择的是CP，也就是放弃了高可用性。

为了达到C，Zookeeper采用的是自己的ZAB协议。这个协议的介绍之前写过一篇博客聊过，就不再赘述了

总得来说，Zookeeper集群在进行消息同步的时候，必须有一半以上结点完成了同步才会返回；而当Master结点挂了或者集群中有过半的结点不能工作了，此时就会触发故障恢复，重新进行Master选举。在这个过程中，整个Zookeeper集群无法对外提供服务，从而实去了A（可用性）

对于大多数的分布式环境来说，特别是数据储存的环境，数据一致性是非常重要的标准。但对于服务发现来说，其实并没有那么严格。就算一个注册中心没有及时获取到实时的服务实例状态，直接把服务列表（可能存在错误）发给客户端，也不会导致灾难性的错误。因为对于客户端来说会有重试机制，少数的实例无法访问不会导致大问题。

Eureka

Spring Cloud Eureka所选择的是AP，放弃了强一致性。

从使用角度来看，Eureka的特点就是使用Java语言来开发的，并且也是Spring Cloud的子项目，所以可以直接通过引入jar包的方式来集成Eureka，这点非常方便

而在架构上，Eureka集群采用的是去中心化结构。也就是说Eureka集群中的各个结点都是平等的，没有主从的概念。通过互相注册的方式来进行消息同步和保证高可用。并且一个Eureka Server结点挂掉了，还有其他同等的结点来提供服务，并不会引发服务的中断。从而来保证A

而在消息同步上，Eureka并不会对消息同步进行保证，既不保证消息正确地传播出去，也不保证接收者一定能接受消息。所以从服务注册角度来说，Eureka的速度是非常快的。但同样的也会带来一定的不一致性。但是之前也说了，在服务注册这种场景，一致性的要求其实并没有很高

另外，Eureka还有一个自我保护机制，用来应对网络问题导致的服务不可用，从而能更进一步地保证可用性。这一点我也在之前的博客有提到

Consul

Consul是HashiCorp公司推出的一个开源工具。它和Eureka一个区别就似乎，Consul是用Go语言编写的，所以无法像Eureka那样直接引入jar包就能集成，它还需要去服务器中进行额外的安装。

Consul的功能相比于Eureka来说也更加强大，因为除了注册中心的功能之外，Consul还能起到配置中心的作用。而Eureka只能当注册中心，想搞配置中心的话，还得搭配Spring Cloud Config+Spring Cloud Bus。其中后者支持Rabbiimq和Kafka两种模式。

Consul它保证的是CP，使用raft协议，要求必须有过半的结点都写入成功才算是注册成功了，并且它也有Master和Follower的概念，在Master挂掉后，也需要自己内部进行新一轮Master选举，在此期间，Consul服务不可用

Nacos

Nacos是阿里巴巴旗下的开源项目，在2018年开源。是Spring Cloud Alibaba的子项目。Nacos一大特性是即支持CP，也支持AP。可以根据需要灵活选择。

Nacos除了注册中心之外，也能充当配置中心的作用。且配置中心可以按照namespace，group等维度来进行数据隔离，来达到不同环境之间配置隔离的功能。

另外值得一提的是，Nacos作为配置中心的持久化机制可以依赖于Mysql来完成（默认依赖于内置数据库）。只需要将Nacos目录下的sql脚本放到mysql中执行（会生成11个表），然后在nacos配置文件里面配一下mysql的账号密码即可。这样使用mysql作为数据源的方式相比于nacos内置数据库来说更容易管理