Nacos源码结构和AP模式注册中心实现介绍

提示：扫一扫查出行
【扫一扫了解最新限行尾号】
复制提示

前言

NacosAP模式源码分析目录

微服务下的注册中心如何选择
Nacos使用和注册部分源码介绍
Nacos服务心跳和健康检查源码介绍
Nacos服务发现

Nacos源码结构介绍

Nacos版本基于1.4.0版本，整体的项目结构如下：

看到目录，第一眼的感觉就是职责分明，给人的感觉就是高手，关于源码部分我也没全看完，目前只是注册中心相关看完了，配置中心的就是略微看了一下，我先给大家介绍下重点的模块的作用的，到时候大家再结合上面几篇文章去理解源码:

address模块: 主要查询nacos集群中节点个数以及IP的列表;
api模块: 主要给客户端调用的api接口的抽象;
client模块: 主要是对依赖api模块和common模块,对api的接口的实现,给nacos的客户端使用;
cmdb模块: 主要是操作的数据的存储在内存中,该模块提供一个查询数据标签的接口;
config模块: 主要是服务配置的管理, 提供api给客户端拉去配置信息,以及提供更新配置的,客户端通过长轮询的更新配置信息.数据存储是Mysql;
naming模块: 主要是作为服务注册中心的实现模块,具备服务的注册和服务发现的功能;
console模块: 主要是实现与前端进行交互.具有权限校验、服务状态、健康检查等功能;
core模块: 主要初始化属性加载，监听器相关内容，用于加载nacos的default的配置信息，config和naming都依赖于这个包；

我觉得上面8个模块相对来说是比较重要，对于大家研究Nacos源码是必须要掌握的，关系间的依赖如下:

模块之间的调用关系如下:

看到调用关系就可以感觉出来，整体上源码不算太难，耐心看看还是可以看懂的。

Nacos AP模式源码核心部分介绍

服务注册

Nacos Client通过/nacos/v1/ns/instance接口将服务信息(包括服务的名称、IP、端口、状态等信息)注册到Nacos Server的注册表中，存放于类ServiceManager的内部对象Map<String, Map<String, Service>> serviceMap，这是一个两层Map的嵌套结构，第一层的Key是Namesapce名称，第二层的Key是Group名称和Service名称的组合，第二层的Value是Service的对象。

服务心跳

用户服务和订单服务注册后，每个客户端会通过定时任务来维持一个定时心跳来持续通知Nacos Server，默认 5s发送一次心跳;

服务健康检查

Nacos Server通过定时任务检查注册服务实例的健康状况，对于超过15s没有收到客户端心跳的实例会将它的 healthy属性置为false(客户端服务发现时不会发现)，如果某个实例超过30秒没有收到心跳，直接剔除该实例(被剔除的实例如果恢复发送心跳则会重新注册);

服务同步

服务同步我觉得主要分为两方面同步，一是Nacos Server集群之间的同步，会过/nacos/v1/ns/instance/distro/datum互相同步服务实例的信息，二是服务的消费者同步变更新到客户端,服务消费者(Nacos Client)会接收服务端的UDP推送过来的服务变更信息(检测到不正常的服务的时候服务发生变更)，及时更新到本地缓存中，这是Nacos的亮点和其他注册中心不一样的地方，面试的时候可以和面试官聊，会让面试官眼前一亮的，因为UDP本身是不可靠的，不能保证所有的变更信息都可以同步到客户端，所以消费者还有一个定时任务的兜底机制;

谈谈收获

看完这部分源码收获我觉得主要有两方面的收获:

技术方面

技术方面的收获的是最多的，这里简单聊几个例子:

从整体的框架的设计，还是到模块中类实现的设计，单一原则体现的淋淋尽致，下图是整体框架设计，体现到代码上就是每个模块职责很清晰，依赖关系很明确，另外框架层面的做的插件化的思想、高可用的思想，都是我们可以借鉴学习的;
很多技术细节的实现很精妙，比如服务变更时候的异步队列的设计、CopyOnWrite的思想、Spring事件机制的应用等等，这些都在我的博客中源码分析的细节中讲到,大家可以稍微花一些功夫看看;