Nacos注册中心和配置中心流程原理

一、Nacos注册中心

　　1、服务启动后---->服务注册原理

• springCloud集成Nacos实现原理： 服务启动时，在spring-cloud-commons包下 spring.factories文件中自动装配，当webServer初始话完成后，会注册监听事件。调用Nacos的register注册服务
• springCloudAlibaba实现原理，springCloudAlibaba使用的是Nacos为注册中心，自动装配的配置类是 DubboLoadBalanceRestTemplateAutoConfiguration，原理和上述一致，基于事件监听，不过事件类型不通，spring CloudAlibaba使用了@EvevntListener（ApplicationStartEvent.class）　，该事件是在应用程序初始化上下文后执行，即refresh()方法初始话上下文　

　　2、服务注册时---->与Nacos建立心跳原理

• 服务调用registerInstance方法进行服务注册，registerInstance方法中，会调用addBeatInfo方法与Nacos Server服务建立心跳。
• 服务端是实现”心跳检测“原理：即executorService.schedule(BeatTask beatTask)定时线程定时执行 入参为心跳包数据
  • 　　服务 启动一个定时线程-----（每隔5s）----->向Nacos服务发送BeatInfo心跳数据包
  • 　　服务 启动一个监视线程-----（）----->用来检测上面的定时线程发送完数据包后，Nacos服务的回应，如果Nacos服务未回应，则认为Nacos服务异常。

　　3、Nacos收到服务注册信息---->与服务建立心跳检测原理

• Nacos收到服务注册原理：服务调用Nacos的open API进行服务注册，Nacos处理时，实际上时创建了一个concurrentHashMap将服务的信息以Namespace/group/缓存到服务内存中。
• Nacos收到心跳数据原理：Nacos服务init完成后，会定时监听上述 第二步 服务发来的心跳包，如果等待超时后，没有收到数据包，则认为服务异常healthy为false，会更新concurrentHashMap缓存的服务地址列表数据。　
  • 　　更新服务的地址列表数据后，会向所有的服务 主动推送Push一个最新的服务地址列表数据
  • 　　基于数据一致性协议，会将最新的 服务地址列表数据同步到Nacos集群的其他节点上

　　4、服务端之间进行远程调用---->调用Nacos获取远程服务地址列表数据原理

• 服务端获取远程调用服务地址列表数据原理：基于Nacos OpenAPI完成 获取远程服务地址列表数据，进而完成服务之间的远程调用。同时本地会缓存一份地址列表数据（这里说一下，如果使用的是feign那么服务之间的调用协议是Http，如果是Dubbo，那么可以自定义协议，或者Dubbo协议）

　　5、服务本地会缓存一份服务提供者地址列表数据---->Nacos实现服务提供者地址列表数据 动态感知

• 一旦涉及到缓存，就要涉及缓存数据的一致性。在微服务的调用中，服务调用者会缓存一份 服务提供者的地址列表数据，如果这份缓存数据和 Nacos注册中心的 服务提供者地址列表数据不一致。会造成服务消费者进行远程调用时出错。如果客户端的负载均衡没有做好，会造成严重问题。

Nacos解决 服务消费者动态感知 服务提供者地址 列表数据原理：（一般有两种方式Push和Pull，Nacos都提供了）

• 　　Pull模式：服务消费者 主动拉取，在调用selectInstance时，可以subscribe为true实现订阅，客户端会有 一个HostReactor update的定时线程-----（每隔10s）---->获取一次服务提供者地址列表数据。这里定时为10s，比上面第二步5s上报心跳大，一定程度上保证了服务消费者获取的地址列表数据的准确性
• 　　Push模式：Push模式需要依赖上述的第二步，Nacos会监听服务提供者的心跳数据包，并更新最后一次的心跳时间，如果超时了，那么说明服务提供者异常，会更新地址列表数据。并主动Push给服务消费者。
• 　　服务消费者收到Push数据原理：服务消费者收到最新的地址列表数据后，会将数据交给上述 Pull模式的 update定时线程来处理。站在服务消费者的角度，相当于服务消费者主动Pull了一次最新数据。这么做的原因是：保持服务消费者 只有一个线程感知接收服务提供者的地址列表数据。避免了Pull和Push如果多个线程处理，因为时间差造成的地址列表数据不一致的情况。

二、Nacos注册中心 原理 架构图

三、nacos配置中心原理：

　　1：配置的动态刷新客户端如何感知，有两种方式完成客户端主动Pull拉取配置，Nacos Server主动Push配置数据
　　　　nacos采取的是Pull模式来完成配置的管理和动态刷新
　　　　1： Pull模式： 长轮询机制
　　　　　　nacos采用了长轮询机制实现，客户端发起一个Pull拉取配置请求，nacos server建立一个延时任务队列，每隔29.5s处理一个任务，
　　　　　　处理任务便是花费0.5s检查配置有没有变更。不管有没有变更，都返回配置数据给客户端。
　　　　　　之所以叫长轮询，是因为客户端和nacos建立的连接是一个30s的长连接。
　　　　　　缺点：没有实时性，配置无变化会发起空pull,连接浪费资源。不过这里的缺点在下面的push都解决了。
　　　　2： Push模式：
　　　　　　当通过nacos dashboard或者nacos api修改了配置后，nacos检查pull任务队列，可能会在任务中29.5s内的任意时刻，开始处理任务，
　　　　　　和上述流程一致，检查配置变更数据，返回给Pull请求最新配置。所以Push模式实质上还是利用了Pull请求的任务来完成。
PS: 客户端本身会有一个定时线程每隔10ms检查一次本地配置（硬盘中存储）和内存（JVM）配置是否一致。通过上述动态刷新的只是内存中的配置。

四、naocs配置中心流程图