nacos注册中心源码流程分析

作为一个注册中心，和eureka类似，核心的功能点：

1.服务注册：nacos客户端携带自身信息向nacos服务端进行注册。

2.服务心跳：客户端定时向服务端发送心跳，告知服务端自己处于可用状态

3.服务健康检查：服务端定时检查客户端是否有发送心跳，如果超过15s没有收到心跳，那么就会将该客户端实例设置为不健康状态，如果超过30s没有收到心跳则会剔除该客户端实例

4.服务同步：服务端为了高可用，通常都是集群模式，那么集群之间需要进行数据的同步。

5.服务发现：客户端向服务端查询所有注册的服务列表。客户端获取到之后会放入自己的本地缓存，需要使用的时候，先从本地缓存拿，没有再去服务获取。同时还有定时任务，去服务端拉取注册列表，更新本地缓存，如果失败拉取的间隔时间会根据失败次数增加。

源码分析：

从客户端开始入手，切入点当然是spring-cloud-starter-alibaba-nacos-discovery包的spring.factories文件中的自动配置类

1.最为关键的就是NacosDiscoveryAutoConfiguration 和 NacosServiceRegistryAutoConfiguration 这两个配置类了，eureka是通过SmartLifecycle整合进spring的，从配置类中创建的NacosAutoServiceRegistration这个类，追溯一下可以看到这个是实现了ApplicationListener接口，所以nacos是通过这个接口整合进spring的

2.nacos源码中很多地方都是初始化的时候就设置好了定时任务，或者线程池，后续的任务都是直接扔进去执行就是了。

3.nacos提供了AP和CP 两种模式。非持久化实例注册，数据放在内存中，和eureka类似，集群节点之间都是点对点的。如果是持久化实例，则是CP模式，集群节点会有leader和follower,客户端注册的数据会写入磁盘，节点重启时会从磁盘上把数据读取出来。

4.和eureka不同的是，nacos还有主动推送功能，eureka的注册列表发生改变的时候，eureka是失效读写缓存，等待下一次只读缓存（如果使用了）来更新时，重建读写缓存，或者客户端拉取数据时重建读写缓存。nacos并没有使用多级缓存。当注册列表发生改变时，会发送ServiceChangeEvent事件，然后主动向客户端推送信息

源码关键流程图：基于1.4.0