0. 启动调试 console
- 加入 VM option:
-Dnacos.standalone=true -Dnacos.functionMode=naming
- 启动 console 项目,查看 banner
1. service 与 instance 的逻辑关系
每个服务可以有多个实例,每个实例又区分为两种实例,一种为临时实例,一种是非临时实例,它们的关系在 ServiceManager 中保存,具体的 service、instance、cluster 类都在 com.alibaba.nacos.api.naming.pojo
包下,对外的接口主要是 service、instance 的 CRUD 操作。其中有个 cluster 的逻辑结构,属于 service 和 instanc 之间,对应的是某个 service 有多少个 instance,就有多少个 cluster
2. service 的操作
nacos 本身支持两种协议,一种是 Raft 一种是 Distro
而 service 创建操作使用了 Raft 协议
2.1 请求的是 Leader 节点时
先在本节点发布 service change 事件,接着通过 http 发送到其它节点,同步该服务创建操作,如果这个请求超过 5s,就认为该操作失败。里面使用了代理类 consistencyDelegate,除了临时节点,其它类型的一致性操作统一走 Raft 协议,最终会到 RaftCore.signalPublish() 方法,遍历其它注册中心节点,POST 请求 /v1/ns/raft/datum/commit 接口,该接口主要做了如下判断:对比请求节点的 term 是否比自己大,如果请求节点的 term 大于等于自己节点的 term ,就执行该任务,将服务信息同步到本节点
2.2 请求的是非 Leader 节点时
如果当前节点是非 leader,直接得到 leader 节点的 url,并请求 /v1/ns/raft/datum/ 接口,将 service 创建事件给 leader 处理。注意,本节点的 term 是没有变的,这种情况下 leader 接收到请求后 term 会增加,并同步到其它节点,其它节点判断 leader 的 term 和自己等于或大于时就执行该操作
1 | public void signalPublish(String key, Record value) throws Exception { |
3. instance 的操作
instance 增加时,如果没有对应的 service,会默认创建该 service,如果已经有了 service ,会直接塞入到该 service 的 instanceList 中,具体细节在 ServiceManager 中进行操作。
接着判断增加的 instance 是否临时来使用不同的一致性协议,如果为临时实例,使用 distro 协议,如果非临时实例,使用 raft 协议。distro 协议大致为定时任务广播其它节点+保存内存,其中广播的接口为 /distro/dump。
distro 协议为自制协议,AP