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

前言

NacosAP模式源码分析目录

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事件机制的应用等等，这些都在我的博客中源码分析的细节中讲到,大家可以稍微花一些功夫看看;

写作方面

这部分其实还没形成一个完整的思想，只是初步的一个思考，关于这种源码分析的，以后会采用以下方式:

框架选型的思考, 分析类似中间件对比；
框架搭建和使用介绍;
源码代码模块介绍和框架模块功能性的描述，类似就是做一个整体功能介绍;
每个模块功能源码的分析，附带时序图和类图关系，后面我会对Nacos系列的文章的内容进行一个改造;
完成每个模块的介绍以后会统一做代码的整体关键步骤的源码分析图和总结；

结束

欢迎大家点点关注，点点赞!