概述
nacos的服务发现是一个service --> cluster --> instance模型。服务存储集群列表。
一致性协议通过ConsistencyService来操作。ConsistencyService是个解耦层,使用户不用关系实现的协议(如最新的代码raft组件已标记废弃,改用Distro)。
添加服务:
查看是否已添加—ConsistencyService存储(key:服务metakey前缀+命名空间id+命名空间key连接符(##)+服务名
服务注册
服务在启动时,client通过NacosServiceRegistry.register方法调用,客户端调用服务端InstanceController的register方法,通过serviceManager注册实例。
添加实例:
服务上报有临时模式和持久模式(ephemeral:true/false)
# 默认false
spring:
cloud:
nacos:
discovery:
ephemeral: true
临时和持久化的区别主要在健康检查失败后的表现,持久化实例健康检查失败后会被标记成不健康,而临时实例会直接从列表中被删除。
涉及到AP,CP的内容就得看consistency模块了。
在CAP理论中, 一个分布式系统中, Consistency(一致性)、 Availability(可用性)、Partition tolerance(分区容错性),三者不可得兼。
- 一致性(C):在分布式系统中的所有数据备份,在同一时刻是否同样的值。(等同于所有节点访问同一份最新的数据副本)
- 可用性(A):在集群中一部分节点故障后,集群整体是否还能响应客户端的读写请求。(对数据更新具备高可用性)
- 分区容忍性(P):以实际效果而言,分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性,就意味着发生了分区的情况,必须就当前操作在C和A之间做出选择。
CAP原则的精髓就是要么AP,要么CP,要么AC,但是不存在CAP。如果在某个分布式系统中数据无副本, 那么系统必然满足强一致性条件, 因为只有独一数据,不会出现数据不一致的情况,此时C和P两要素具备,但是如果系统发生了网络分区状况或者宕机,必然导致某些数据不可以访问,此时可用性条件就不能被满足,即在此情况下获得了CP系统,但是CAP不可同时满足 。
AP模式不支持数据一致性,所以只支持服务注册的临时实例,CP模式支持服务注册的永久实例,满足配置文件的一致性
配合前面的naming模块,也就是在集群注册临时服务时,使用distro协议。session断了数据丢失。
nacos的服务发现中有个比较重要的节点管理ServerMemberManager
/**
* Register necessary component to distro protocol for HTTP implement.
*/
@PostConstruct
public void doRegister() {
componentHolder.registerDataStorage(KeyBuilder.INSTANCE_LIST_KEY_PREFIX,
new DistroDataStorageImpl(dataStore, distroMapper));
componentHolder.registerTransportAgent(KeyBuilder.INSTANCE_LIST_KEY_PREFIX, new DistroHttpAgent(memberManager));
componentHolder.registerFailedTaskHandler(KeyBuilder.INSTANCE_LIST_KEY_PREFIX,
new DistroHttpCombinedKeyTaskFailedHandler(globalConfig, taskEngineHolder));
taskEngineHolder.registerNacosTaskProcessor(KeyBuilder.INSTANCE_LIST_KEY_PREFIX,
new DistroHttpDelayTaskProcessor(globalConfig, taskEngineHolder));
componentHolder.registerDataProcessor(consistencyService);
}
distro同步任务