Nacos客户端通过Open API 的形式发送服务注册请求。Nacos服务端收到请求后，做以下三件事：
构建一个Service对象保存到ConcurrentHashMap集合中使用定时任务对当前服务下的所有实例建立心跳检测机制基于数据一致性协议将服务数据进行同步。 分析Nacos服务地址动态感知原理
服务消费者不仅需要获取服务提供者的地址列表，还需要在服务实例出现异常时监听服务地址的变化。
Nacos客户端有一个HostReactor类，它的功能时实现服务的动态更新，基本原理时：
客户端发起事件订阅后，在HostReactor中有一个UpdateTask线程，每10s 发送一次Pull请求，获得服务端最新的地址列表。对于服务端，它和服务端提供者的实例之间维持了心跳检测，一旦服务提供者出现异常，则会发送一个Push消息给Nacos客户端，也就是服务消费者。服务消费者收到请求之后，使用HostReactor中提供的proceeServiceJSON解析信息，并更新本地服务地址列表。
配置中心
使用说明
官方建议， 通过namespace来区分不同的环境，而group可以专注在业务层面的数据分组。这两个的使用必须提前进行基本的定调，避免使用上的混乱。
namespace需要提前在控制台创建group不需要提前在控制台创建data id是nacos中某个配置集的id, 通常用于组织划分系统的配置集。
spring cloud alibaba nacos config中有两个注意点：
spring.cloud.nacos.config.ext-config[n].data-id的值 必须要带文件的扩展名。如yaml、properties、json等。spring.cloud.nacos.config.ext-config[n].data-id配值多个data id时，n的值越大，优先级越高。 通过自定义扩展的data id配置，即可以解决多个应用的配置共享问题，由可以支持一个应用有多个配置文件的情况。需要注意，在ext-config和${spring.application.name}.${file-extension:properties}都存在的情况下，后者的优先级更高。 原理分析
配置管理的4个操作：
获取配置：GET /nacos/v1/cs/configs监听配置：POST /nacos/v1/cs/configs/listener发布配置：POST /nacos/v1/cs/configs删除配置：DELETE /nacos/v1/cs/configs
这些操作分为两种类型，分配配置的CRUD和配置的动态监听。
CRUD默认的持久化，使用的时Derby数据库，一般生产环境要改为mysql数据库。
动态监听一般来说，客户都和服务端之间的数据交互无非两种方式：pull和push。
pull: 客户端从服务端主动拉取数据
这种模式下，客户端需要定时从服务端拉取一次数据，由于定时任务会存在一定的时间间隔，所以不能保证数据的实时性。并且在服务端配置长时间不更新的情况下，客户端的定时任务会做一些无效的pull。push: 服务端主动把数据推送给客户端
这种模式下，服务端需要维持与客户端的长连接，如果客户端的数量比较多，那么服务端需要耗费大量的内存资源来保持每个连接，并且为了检测连接的有效性，还需要心跳机制维持每隔连接的状态。
Nacos采用的时pull模式，但不是简单的pull， 而是一种长轮询机制，它结合了push和pull两者的优势。这种方式的特点是：当客户端发起请求时，如果服务端的配置和客户端的配置保持一致，则服务端会Hold住这个请求，在指定的时间段内一直不返回结果，直到配置发生变化或时间到了。
一般这个长连接的会话超时时间默认时30s。
