Nacos源码分析系列之整体分层架构

1. 整体功能逻辑架构

引用Nacos官方公布的整体功能逻辑图

简单剖析下这张功能架构图：

• Console：控制台，用于运维或者具备权限的开发人员后台管控Nacos集群运行
• SDK：客户端接入的API，当然肯定包括各种框架的接入适配，比如Spring、SpringBoot、SpringCloud等，还有对多语言的支持
• Agent：业务零侵入，不再需要SDK
• CLI：命令行对产品进行轻量化管理
• OpenAPI：暴露标准Rest风格HTTP接口，简单易用，方便多语言集成
• 服务管理：实现服务CRUD，域名CRUD，服务健康状态检查，服务权重管理等功能
• 配置管理：实现配置管CRUD，版本管理，灰度管理，监听管理，推送轨迹，聚合数据等功能
• 元数据管理：提供元数据CURD 和打标能力
• 插件机制：实现三个模块可分可合能力，实现扩展点SPI机制
• 事件机制：实现异步化事件通知，sdk数据变化异步通知等逻辑
• 日志模块：管理日志分类，日志级别，日志可移植性（尤其避免冲突），日志格式，异常码+帮助文档
• 回调机制：sdk通知数据，通过统一的模式回调用户处理。接口和数据结构需要具备可扩展性
• 寻址模式：解决ip，域名，nameserver、广播等多种寻址模式，需要可扩展
• 推送通道：解决server与存储、server间、server与sdk间推送性能问题
• 容量管理：管理每个租户，分组下的容量，防止存储被写爆，影响服务可用性
• 流量管理：按照租户，分组等多个维度对请求频率，长链接个数，报文大小，请求流控进行控制
• 缓存机制：容灾目录，本地缓存，server缓存机制。容灾目录使用需要工具
• 启动模式：按照单机模式，配置模式，服务模式，dns模式，或者all模式，启动不同的程序+UI
• 一致性协议：解决不同数据，不同一致性要求情况下，不同一致性机制
• 存储模块：解决数据持久化、非持久化存储，解决数据分片问题
• Nameserver：解决namespace到clusterid的路由问题，解决用户环境与nacos物理环境映射问题
• CMDB：解决元数据存储，与三方cmdb系统对接问题，解决应用，人，资源关系
• Metrics：暴露标准metrics数据，方便与三方监控系统打通
• Trace：暴露标准trace，方便与SLA系统打通，日志白平化，推送轨迹等能力，并且可以和计量计费系统打通
• 接入管理：相当于阿里云开通服务，分配身份、容量、权限过程
• 用户管理：解决用户管理，登录，sso等问题
• 权限管理：解决身份识别，访问控制，角色管理等问题
• 审计系统：扩展接口方便与不同公司审计系统打通
• 通知系统：核心数据变更，或者操作，方便通过SMS系统打通，通知到对应人数据变更

2. 现有落地的分层架构(从代码层次)

阅读源码技巧：首先我们必须要具备分层架构思维，将一套原本很复杂的工程代码，各个击破，这样才能吃透整个源码。

结合笔者这么多年阅读源码的经验，我会优先看框架整体的技术栈以及公共模块，并且找到框架的入口。

Nacos整体基础框架：

• SpringBoot
• Tomcat
• Mysql
• Netty
• Spring

公共模块：

• naming
• config
• address

笔者会优先考虑分析这三个模块的源码，并串联整个框架；框架串联完毕之后，会串联整个框架生态，从而会形成自己的技术生态。