Nacos 不仅可以作为注册中心，也可以作为配置中心。本章讨论作为注册中心的核心功能。
一. 服务注册
Nacos Client会通过发送REST请求的方式向Nacos Server注册自己的服务，提供自身的元数据，比如ip地址、端口等信息。Nacos Server接收到注册请求后，就会把这些元数据信息存储在一个双层的内存Map中。
具体注册类：NacosServiceRegistry
//namespace: 一级隔离，如不同环境隔离
//Group：二级隔离，比如灰度,蓝绿发布等.
//servicename： 服务名
Map<namespace,Map<Group::servicename,Service>>
Service中，还有一层Map,实现不同集群，如上海机房，北京机房。集群间是可以通信的，但是有时候为了性能，可以优先调用同集群服务
private Map<String, Cluster> clusterMap = new HashMap<>();
Cluster：
> 服务提供者属性配置是否是临时节点
// 持久化实例
private Set<Instance> persistentInstances = new HashSet<>();
// 临时实例
private Set<Instance> ephemeralInstances = new HashSet<>();
1.1 客户端启动注册原理
api文档地址：https://nacos.io/zh-cn/docs/open-api.html
1.2 服务端注册原理
服务端接收到客户端注册实例请求后。InstanceController 执行服务端注册逻辑。 注册实例分两种： ephemeral 和persistent。 ephemeral是AP实现，persistent为CP实现。注册中心的场景使用AP，效率高。 配置中心使用CP。
AP
AP实现，注册节点时，使用ephemeral 节点直接存储在内存中。集群中某个节点接收到注册请求时，在本地完成注册后，同步给其他节点，同步过程中不同节点存在短暂的数据不一致，且每个节点都是可用的。
- getOrCreate 对应的Service
- 亮点1： 将注册请求包装为任务-->放入阻塞队列中
- 亮点1： 开启线程循环获取阻塞队列中的任务，实现异步处理
- 亮点2：处理注册实例请求时，针对实例所属集群，按集群采用CopyOnWrite机制包装读写安全问题。
CP
注册中心使用场景很少使用CP，所以这里不详细解释。
Nacos使用另一个Paxos算法的简易算法Raft算法解决一致性问题。
Raft算法通常通过两部分保证一致性： Leader选举和数据两阶段递交。
Nacos Raft算法是阿里自己实现的，只保证了Leader选举部分，数据递交并没有使用两阶段递交，所有实际上CP的实现有小问题。
- 集群启动时基于Raft算法选举Leader。
- 服务端接收到注册请求后，由Leader负责注册注册。
- Leader首先将数据保持在文件中，然后异步存入内存。使用CountDownLatch 实现简易的raft算法写入1/2以上节点才返回成功，否则抛出异常，客户端重试。 这种实现存在问题，及时给客户端返回失败了，但其实Leader节点已经保存到内存中。
二. 服务发现
服务发现代码其实很简单。
- 第一次调用时，从服务端拉取服务的所有实例放入本地缓存，同时迭代延迟调用获取服务实例接口更新本地缓存。同时注册一个UDP接口。
- 当服务实例变更时，根据注册的UDP接口，采用UDP协议通知给客户端。
三. 心跳检查
客户端发送心跳
客户端在执行namingService.registerInstance之前，首先执行addBeatInfo。
addBeatInfo中，addBeatTask 延迟指定时间异步发送心跳给服务端，发送后再相同的间隔迭代调用addBeatTask方法，不断循环发送心跳，发送给服务端后，在服务端更新该实例最后心跳时间。
服务端健康检查
服务端在接收到注册实例请求后，如果该服务第一次注册，在createEmptyService中，第一次创建Service并init，初始化时，创建一个定时器，延迟5秒后，每5秒做一次服务下所有实例的健康检查。
1.如果一个客户端超过15秒没有发送心跳，服务端标记该实例为--healthy为false
2.超过30秒没有发送心跳，则直接删除。
