注册中心:注册和发现的原理
服务注册的完整过程
- 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}
都存在的情况下,后者的优先级更高。
- spring cloud alibaba nacos config中有两个注意点:
原理分析
配置管理的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。