Nacos是阿里开源的一个新框架，在分布式的架构中，Nacos同时扮演着服务注册中心和配置中心的角色。今天主要讲的是Nacos作为服务注册中心。
分布式中著名的CAP理论，任何一种服务注册中心都只能实现其中的两个特性，一般是AP（注重可用性）或者CP（注重一致性）。
Eureka就是一个AP的服务注册中心，任何一个Eureka Server都是独立的，可存储所有的服务注册信息，即使任意一台Eureka Server宕机，其余的机器都可以照常工作，保证高可用性，但是不保证数据是一致的；
Zookeeper是一个CP的服务注册中心，所有的服务注册信息都存储在leader的机器上，同步给其他的follewer，可以保证强一致性，若leader宕机，则不能提供服务注册的功能了，需要重新选举，无法保证高可用性；
Nacos在 1.0.0 正式支持 AP 和 CP 两种一致性协议并存。一个是基于简化的 Raft 的 CP 一致性，一个是基于自研协议 Distro 的 AP 一致性。Raft 协议基于 Leader 进行写入，其 CP 也并不是严格的，只是能保证一半所见一致，以及数据的丢失概率较小。Distro 协议则是参考了内部 ConfigServer 和开源 Eureka，在不借助第三方存储的情况下，实现基本大同小异。
Eureka和Zookeeper都不能支持大量的服务实例，Eureka因为所有的服务实例在每一台Eureka Server中都保存了，大量的服务实例会产生大量的心跳检测等信息，导致Eureka Server无法支持高并发的操作。
Zookeeper的话，会将服务实例的上线下线通知到每一个服务实例，如果频繁的上下线的话，会去通知大量的服务实例，导致短时间网络压力增大，性能下降。
而Nacos 在开源版本中，服务实例注册的支撑量约为 100 万，服务的数量可以达到 10 万以上。在实际的部署环境中，这个数字还会因为机器、网络的配置与 JVM 参数的不同，可能会有所差别。
Nacos相比较于其他的服务中心还是有一定优势的。
Nacos服务注册发现步骤
1、服务提供者将注册信息写入到Nacos注册中心的服务注册表中
2、服务注册中心将服务提供者的实例交给Service Holder（服务持有容器）处理，服务实例将会挂载在Service Holder的空间下
3、服务注册成功后，提供者将与服务中心维持心跳，未能及时发送心跳的服务将会被剔除
4、服务发现支持两种场景
消费者可以直接向注册中心发送获取某个服务实例的请求，这种情况下注册中心将返回所有可用的服务实例给消费者，但是一般不推荐这种情况
服务的消费者向注册中心订阅某个服务，并提交一个监听器，当注册中心中服务发生变更时，监听器会收到通知，这时消费者更新本地的服务实例列表，以保证所有的服务均是可用的。
原文链接：https://blog.csdn.net/LO_YUN/article/details/100181873