nacos的研究

注册中心：注册和发现的原理

服务注册的完整过程

• 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。