总体架构🎛️
整体架构分为：用户层，业务层，内核层，插件。用户层主要是用户直接操作服务或者实例；业务层就是服务发现和配置管理，内核层则是nacos的高可用性的设计，插件就是可扩展功能。
; 用户层：
- OpenApi: 暴露标准的Rest风格的HTTP接口
- Console： 控制台页面
- SDK: 多语言sdk，java，python各种语言
- Agent: Sidecar 模式运行，通过标准 DNS 协议与业务解耦(好像和ServiceMesh有关，不懂)
- CLI: 命令行对产品进行轻量化管理，像 git ⼀样好用。（直接复制的，没百度到，不懂）
业务层：
- 服务管理：实现服务 CRUD，域名 CRUD，服务健康状态检查，服务权重管理等功能
- 配置管理：实现配置管 CRUD，版本管理，灰度管理，监听管理，推送轨迹，聚合数据等功能
- 元数据管理：提供元数据 CURD 和打标能力，为实现上层流量和服务灰度非常关键。这里的元数据其实就是包括服务端点(endpoints)、服务标签、服务版本号、服务实例权重、路由规则、安全策略等描述服务的数据。
内核层：
- 插件机制：实现三个模块可分可合能力，实现扩展点 SPI 机制，用于扩展自己公司定制。
- 事件机制：实现异步化事件通知，SDK 数据变化异步通知等逻辑，是 Nacos 高性能的关键部分。
- 日志模块：管理日志分类，日志级别，日志可移植性（尤其避免冲突），日志格式，异常码+帮助文档。
- 寻址模式：解决 Server IP 直连，域名访问，Nameserver 寻址、广播等多种寻址模式，需要可扩展。
- 推送通道：解决 Server 与存储、Server 间、Server 与 SDK 间高效通信问题。
- 容量管理：管理每个租户，分组下的容量，防止存储被写爆，影响服务可用性。
- 流量管理：按照租户，分组等多个维度对请求频率，长链接个数，报文大小，请求流控进行控制。
- 缓存机制：容灾目录，本地缓存，Server 缓存机制，是 Nacos 高可用的关键。
- 启动模式：按照单机模式，配置模式，服务模式，DNS 模式模式，启动不同的模块。
- ⼀致性协议：解决不同数据，不同⼀致性要求情况下，不同⼀致性要求，是 Nacos 做到 AP 协议的关键。
- 存储模块：解决数据持久化、非持久化存储，解决数据分片问题。
插件：
- Nameserver：解决 Namespace 到 ClusterID 的路由问题，解决用户环境与 Nacos物理环境映射问题。
- CMDB：解决元数据存储，与三方 CMDB 系统对接问题，解决应用，人，资源关系。
- Metrics：暴露标准 Metrics 数据，方便与三方监控系统打通。
- Trace：暴露标准 Trace，方便与 SLA 系统打通，日志白平化，推送轨迹等能力，并且可以和计量计费系统打通。
- 接入管理：相当于阿里云开通服务，分配身份、容量、权限过程。
- 用户管理：解决用户管理，登录，SSO 等问题。
- 权限管理：解决身份识别，访问控制，角色管理等问题。
- 审计系统：扩展接口方便与不同公司审计系统打通。
- 通知系统：核心数据变更，或者操作，方便通过 SMS 系统打通，通知到对应人数据变更。
服务发现🎮
nacos服务发现的数据模式是 服务-集群-实例的三层模型；nacos中注册的服务可以分为两种，一种是临时实例，大部分服务都是临时的，就是正常实现业务功能的服务都是临时的；另外一种是永久实例，比如像数据库这种的；主要的区别就是健康检查的方式不同。
临时实例：客户端主动上报，也就是注册的服务主动向服务端发送心跳，每隔几秒发送一次，一旦服务端没有在一段时间内没有收到客户端的心跳，就会将服务标记为不健康，再过一段时间仍然没有收到心跳检测，就会一出这个实例。
永久实例：
持久化服务的实例的在被主动删除前⼀直存在的特性，探活的定时任务会不断探测服务的健康
状态，并且将无法探测成功的实例标记为不健康。但是有些时候会有这样的场景，有些服务不希望
去校验其健康状态，Nacos 也是提供了对应的白名单配置，用户可以将服务配置到该白名单，那么
Nacos 会放弃对其进行健康检查，实例的健康状态也始终为用户传入的健康状态
集群模式下的健康检查：
ncaos中的一个服务只会被一个nacos集群中的一个服务端，也就是一个注册节点所负责，其余节点只是保留这个注册服务的副本信息，每次这个注册服务向所负责的节点发送心跳之后，这个负责的节点会将这个健康服务的信息同步到其他注册节点；如果其他注册节点在一段时间内没有收到非自己负责的服务的同步的健康信息，就会标记为不健康。
定义服务：
- 命名空间（nameSpace）：Nacos 数据模型中最顶层、也是包含范围最广的概念，用于在类似环境或租户等需要强制隔离的场景中定义。Nacos 的服务也需要使用命名空间来进行隔离。（我一般用于区分不同环境）
- 分组（group）： Nacos 数据模型中次于命名空间的⼀种隔离概念，区别于命名空间的强制隔离属性，分组属于⼀个弱隔离概念，主要用于逻辑区分⼀些服务使用场景或不同应用的同名服务，最常用的情况主要是同⼀个服务的测试分组和生产分组、或者将应用名作为分组以防止不同应用提供的服务重名。（我一般用于区分不同类型，比如mysql，redis这种）
- 服务名（Name）：该服务实际的名字，⼀般用于描述该服务提供了某种功能或能力。
配置管理📃
配置作为分布式系统中非强⼀致数据，因此阿里配置中心是采用 AP ⼀致性协议。⼀致性的核心是 Server与 DB 保持数据⼀致性，从而保证 Server 数据⼀致；Server 之间都是对等的。数据写任何⼀个 Server,优先持久化，持久化成功后异步通知其他节点到数据库中拉取最新配置值，并且通知写入成功。
名词概念：
- 命名空间（nameSpace）: 常用场景之⼀是不同环境的配置的区分隔离，例如开发测试环境和生产环境。如果在没有指定 Namespace 的情况下，默认使用 public 命名空间。
- 分组（group）：Nacos 中的⼀组配置集，是配置的维度之⼀，如果未填写配置分组的名称，则配置分组的名称默认采用 DEFAULT_GROUP，（我一般也是用配置类型区分：mysql，redis这种）
- 配置ID（Data ID）: Nacos 中的某个配置集的 ID。配置集 ID 是划分配置的维度之⼀,Data ID 通常用于划分系统的配置集，这个和自定义的命名空间id不一样，Data ID生成的名称默认是：p r e f i x − {prefix}-p r e f i x −{spring.profiles.active}-${file-extension}
配置基础模型：
- Nacos 提供可视化的控制台，可以对配置进行发布、更新、删除、灰度、版本管理等功能。
- SDK 可以提供发布配置、更新配置、监听配置等功能。
- SDK 通过 GRPC 长连接监听配置变更，Server 端对比 Client 端配置的MD5 和本地 MD5是否相等，不相等推送配置变更。
- SDK 会保存配置的快照，当服务端出现问题的时候从本地获取
; 配置存储模型（数据库中的表）：
- config_info 存储配置信息的主表，里面包含 dataId、groupId、content、tenantId等数据。
- config_info_beta 灰度测试的配置信息表，存储的内容和 config_info 基本相似。有⼀个 beta_ips 字段用于客户端请求配置时判断是否是灰度的 ip。
- config_tags_relation 配置的标签表，在发布配置的时候如果指定了标签，那么会把标签和配置的关联信息存储在该表中。
- his_config_info 配置的历史信息表，在配置的发布、更新、删除等操作都会记录⼀条数据，可以做多版本管理和快速回滚。
配置动态变更：
SDK 通过 GRPC 长连接监听配置变更，Server 端对比 Client 端配置的MD5 和本地 MD5是否相等，不相等推送配置变更。
NacosSync⛳
- NacosSync 是⼀个支持多种注册中心的同步组件,基于 Spring boot 开发框架,数据层采用Spring Data JPA ，遵循了标准的 JPA 访问规范，支持多种数据源存储,默认使用 Hibernate实现,更加方便的支持表的自动创建更新。
- 使用了高效的事件异步驱动模型, 支持多种自定义事件,使得同步任务处理的延时控制在 3s, 8C 16G 的单机能够支持 6K 的同步任务。
- NacosSync 除了单机部署,也提供了高可用的集群部署模式，NacosSync 是无状态设计，将任务等状态数据迁移到了数据库,使得集群扩展非常方便。
- 抽象出了 Sync 组件核心接口,通过注解对同步类型进行区分，使得开发者可以很容易的根据自己需求，去扩展不同注册中心，目前已支持的同步类型：
- Nacos 数据同步到 Nacos
- Zookeeper 数据同步到 Nacos
- Nacos 数据同步到 Zookeeper
- Eureka 数据同步到 Nacos
- Consul 数据同步到 Nacos
Original: https://blog.csdn.net/ZRL1996/article/details/127822149
Author: 快点到周五
Title: nacos概念学习
原创文章受到原创版权保护。转载请注明出处：https://www.johngo689.com/659350/
转载文章受原作者版权保护。转载请注明原作者出处！