1.简单介绍
Nacos 致力于帮助您发现、配置和管理微服务。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据及流量管理。
Nacos是不仅仅是注册中心还是配置中心。类比于Eureka（Zookeeper、Consul）和config。
2.nacos的优势
1）eureka 2.0闭源码了
2）开箱即用，上手简洁，界面美观，背靠国内大厂（经受双十一的考验），中英文文档
3）nacos使用的raft协议,nacos集群的一致性要远大于eureka集群
4）nacos功能更加丰富，社区更加活跃
补充：Raft 的数据一致性策略
Raft 协议强依赖 Leader 节点来确保集群数据一致性。即 client 发送过来的数据均先到达 Leader 节点，Leader 接收到数据后，先将数据标记为 uncommitted 状态，随后 Leader 开始向所有 Follower 复制数据并等待响应，在获得集群中大于 N/2 个 Follower 的已成功接收数据完毕的响应后，Leader 将数据的状态标记为 committed，随后向 client 发送数据已接收确认，在向 client 发送出已数据接收后，再向所有 Follower 节点发送通知表明该数据状态为committed。
3.nacos与各注册中心对比图
nacos与各注册中心对比图（来自互联网）
4.nacos的关键特性：
1）服务注册发现和服务健康检测
Nacos支持基于DNS和基于RPC的服务发现，服务端可以通过SDK或者Api进行服务注册，相应的服务消费者可以使用DNS或者Http查找的方式获取服务列表。Nacos同时提供对服务的实时健康检查，阻止不健康的主机或服务发送请求(与Eureka类似),Nacos有友好的控制台界面。
2）动态配置服务：
Nacos支持动态的配置管理，将服务的配置信息分环境、分类别外部管理，并且支持热更新。不过与Config不同Nacos的配置信息存储与数据库中，支持配置信息的监听和版本回滚。
3）动态DNS服务：
支持权重路由，更容易地实现中间层负载均衡、更灵活的路由策略、流量控制以及数据中心内网的简单DNS解析服务。动态DNS服务还能让您更容易地实现以 DNS 协议为基础的服务发现，以帮助您消除耦合到厂商私有服务发现 API 上的风险。
4）服务及元数据管理
Nacos 能从微服务平台建设的视角管理数据中心的所有服务及元数据，包括管理服务的描述、生命周期、服务的静态依赖分析、服务的健康状态、服务的流量管理、路由及安全策略、服务的 SLA 以及最首要的 metrics 统计数据。
5.nacos生态图--------------Nacos 无缝支持一些主流的开源生态
生态图
6.nacos基础架构
基础架构
Nacos服务发现分为客户端（消费者）和服务端
客户端（消费者）：启动时，从服务端读取指定服务名称的实例列表，缓存到本地。每隔10秒向服务端短轮询一次服务的实例列表。
服务端：通过心跳检测，发现服务提供者出现心跳超时，push消息到消费者，（消费者会基于udp协议建立一个监听，一旦接收到服务端传来的数据，就会更新本地缓存）。
7.逻辑架构图
逻辑架构图
服务管理：实现服务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系统打通，通知到对应人数据变更
OpenAPI：暴露标准Rest风格HTTP接口，简单易用，方便多语言集成
Console：易用控制台，做服务管理、配置管理等操作
SDK：多语言sdk
Agent：dns-f类似模式，或者与mesh等方案集成
CLI：命令行对产品进行轻量化管理，像git一样好用
8）数据模型
nacos数据模型
1）Namespace（环境隔离）:
用于进行租户粒度的配置隔离，不同的命名空间下，可以存在相同的Group或者DataId的配置。Namespace的常用场景之一是不同环境的配置的分区隔离。默认为public，没有指定命令空间时都会默认卡区该命名下。
2）group（区域隔离）
据业务需求，对不同的服务以及配置进行分组，通过不同的字符串名(分组名)来表示不同的分组。nacos中如果未显示的分组，默认划分在DEFAULT_GROUP分组中。
3）Service/DataId（个体隔离）
Data ID在Nacos中可以理解为就是一个Spring Cloud应用的配置文件名,每个配置集都可以被一个有意义的名称标识。Data ID 通常采用类 Java 包（如 com.taobao.tc.refund.log.level）的命名规则保证全局唯一性
补充：
【1】Group+DataId组合在当前命名空间下是唯一的，即同一分组下，不会出现多个相同DataId的配置
【2】不同的Namespace和Group间服务是隔离的，即服务注册到不同的分组时，无法使用OpenFeign指定服务名负载调用
【3】Namespace+Group+DataId组合是唯一的，即不同命名空间下可有相同分组以及相同DataId,但同一个命名空间下Group与DataId则是唯一的
9）服务领域模型
服务领域模型
10）配置领域模型
围绕配置，主要有两个关联的实体，一个是配置变更历史，一个是服务标签（用于打标分类，方便索引），由 ID 关联。
配置领域模型
网友评论