https://tech.dewu.com/article?id=18
Nacos是一款阿里巴巴开源用于管理分布式微服务的中间件，能够帮助开发人员快速实现动态服务发现、服务配置、服务元数据及流量管理等。这篇文章主要剖析一下Nacos作为注册中心时其服务注册与发现原理。
Nacos作为注册中心是为了更好更方便的管理应用中的每一个服务，是各个分布式节点之间的纽带。其作为注册中心主要提供以下核心功能：
服务注册与发现：动态的增减服务节点，服务节点增减后动态的通知服务消费者，不需要由消费者来更新配置。
服务配置：动态修改服务配置，并将其推送到服务提供者和服务消费者而不需要重启服务。
健康检查和服务摘除：主动的检查服务健康情况，对于宕机的服务将其摘除服务列表。
CAP定理是分布式系统中最基础的原则，所以理解和掌握了CAP对系统架构的设计至关重要。分布式架构下所有系统不可能同时满足以下三点：Consisteny（一致性）、Availability（可用性）、Partition tolerance（分区容错性），CAP指明了任何分布式系统只能同时满足这三项中的两项。
分布式系统肯定都要保证其容错性 ，那么可用性和一致性就只能选一个了。简单来说分布式系统的CAP理论就像你想买个新手机，这个手机不可能功能强大、便宜、又好看的，它最多只能满足两点的，要么功能强大便宜、要么功能强大好看、要么便宜好看，不可能同时满足三点。
注册中心在分布式应用中是经常用到的，也是必不可少的，那注册中心，又分为以下几种：Eureka、Zookeeper、Nacos等。这些注册中心最大的区别就是其基于AP架构还是CP架构，简单介绍一下：
Zookeeper：用过或者了解过zk做注册中心的同学都知道，Zookeeper集群下一旦leader节点宕机了，在短时间内服务都不可通讯，因为它们在一定时间内follower进行选举来推出新的leader，因为在这段时间内，所有的服务通信将受到影响，而且leader选取时间比较长，需要花费几十秒甚至上百秒的时间，因此：可以理解为 Zookeeper是实现的CP，也就是将失去A（可用性）。
Eureka：Eureka集群下每个节点之间都会定时发送心跳，定时同步数据，没有master/slave之分，是一个完全去中心化的架构。因此每个注册到Eureka下的实例都会定时同步ip，服务之间的调用也是根据Eureka拿到的缓存服务数据进行调用。若一台Eureka服务宕机，其他Eureka在一定时间内未感知到这台Eureka服务宕机，各个服务之间还是可以正常调用。Eureka的集群中，只要有一台Eureka还在，就能保证注册服务可用（保证可用性），只不过查到的信息可能不是最新的（不保证强一致性）。当数据出现不一致时，虽然A, B上的注册信息不完全相同，但每个Eureka节点依然能够正常对外提供服务，这会出现查询服务信息时如果请求A查不到，但请求B就能查到。如此保证了可用性但牺牲了一致性。
Nacos：同时支持CP和AP架构，根据根据服务注册选择临时和永久来决定走AP模式还是CP模式。如果注册Nacos的client节点注册时ephemeral=true，那么Nacos集群对这个client节点的效果就是AP，采用distro协议实现；而注册Nacos的client节点注册时ephemeral=false，那么Nacos集群对这个节点的效果就是CP的，采用raft协议实现。
本篇文章主要是深入研究一下Nacos基于AP架构微服务注册原理，由于篇幅有限基于CP架构的Nacos微服务注册下次再跟你们分析。