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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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