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如果多个线程处理，因为时间差造成的地址列表数据不一致的情

况。