Nacos是阿里于2018年开源的项目，其核心定位是『一个更易于帮助云原生应用的动态服务发现、配置和服务管理平台』。本质上其是由VIPServer、ConfigServer和Diamond这三个重要中间件产品整合而来。目前Nacos已加入CNCF landscape。
其开源该项目的初衷：

通过打造Dubbo + Nacos的组合释放在Dubbo在未来云原生及Service Mesh时代，加强其在大规模微服务治理、流量治理、服务集成与服务共享等服务平台能力建设上的威力；
加紧其对接主流生态进度，包括Spring Cloud和Kubernetes云原生体系；

架构以及概念

服务 (Service)

服务是指一个或一组软件功能（例如特定信息的检索或一组操作的执行），其目的是不同的客户端可以为不同的目的重用（例如通过跨进程的网络调用）。Nacos 支持主流的服务生态，如 Kubernetes Service、gRPC|Dubbo RPC Service 或者 Spring Cloud RESTful Service。

服务注册中心 (Service Registry)

服务注册中心，它是服务，其实例及元数据的数据库。服务实例在启动时注册到服务注册表，并在关闭时注销。服务和路由器的客户端查询服务注册表以查找服务的可用实例。服务注册中心可能会调用服务实例的健康检查 API 来验证它是否能够处理请求。

服务元数据 (Service Metadata)

服务元数据是指包括服务端点(endpoints)、服务标签、服务版本号、服务实例权重、路由规则、安全策略等描述服务的数据。

服务提供方 (Service Provider)

是指提供可复用和可调用服务的应用方。

服务消费方 (Service Consumer)

是指会发起对某个服务调用的应用方。

配置 (Configuration)

在系统开发过程中通常会将一些需要变更的参数、变量等从代码中分离出来独立管理，以独立的配置文件的形式存在。目的是让静态的系统工件或者交付物（如 WAR，JAR 包等）更好地和实际的物理运行环境进行适配。配置管理一般包含在系统部署的过程中，由系统管理员或者运维人员完成这个步骤。配置变更是调整系统运行时的行为的有效手段之一。

配置管理 (Configuration Management)

在数据中心中，系统中所有配置的编辑、存储、分发、变更管理、历史版本管理、变更审计等所有与配置相关的活动统称为配置管理。

名字服务 (Naming Service)

提供分布式系统中所有对象(Object)、实体(Entity)的“名字”到关联的元数据之间的映射管理服务，例如 ServiceName -> Endpoints Info, Distributed Lock Name -> Lock Owner/Status Info, DNS Domain Name -> IP List, 服务发现和 DNS 就是名字服务的2大场景。

配置服务 (Configuration Service)

在服务或者应用运行过程中，提供动态配置或者元数据以及配置管理的服务提供者。

逻辑架构及其组件介绍

（学会这样画图）

服务管理：实现服务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一样好用

具体细节可以参考官方文档，很超神的那种文档。

使用方式

管理端

安装后可以通过链接http://localhost:8848/nacos/index.html 来访问。

程序使用

目前包含了多种多样的对接方式：

Nacos Spring；
Nacos Spring Boot；
Nacos Spring Cloud；
Nacos Dubbo；

功能点剖析

注册中心
服务注册
支持持久化实例注册：当实例下线（宕机）后，保留实例，只是将该实例状态置为不健康
支持临时实例注册：临时实例，需要通过上报心跳的方式保活，若一段时间内没有上报心跳，支持将该实例从服务下的实例列表中删除
服务级别『元数据metadata』不会自动注销（Nacos支持服务、集群和实例多级别的元数据信息，与服务实例可以被自动注销相对的，服务本身的元数据信息不能随着服务的下线而丢失,因为这些元数据通常是在创建服务时有人为设定上去的（例如负载均衡策略，权重规则，保护阈值等）。这意味着同一个服务的实例的上上下下，再注册上来的时候，应该依然保有服务原来设定的相关的元数据信息。）

产品上创建服务

服务列表

服务订阅者列表

健康检查

心跳上报方式；
服务端主动探测；

服务发现
具备「保护阀值」功能

配置中心

部署监控
nacos支持通过暴露metric数据接入第三方监控系统监控nacos运行状态，目前支持prometheus，es和influxdb。官网给出了结合prometheus和grafana监控Nacos，如下图，详情请参考官网。
继 Kubernetes 之后，Prometheus成为第二个正式从 CNCF 毕业的开源项目。Nacos及Nacos-Sync支持Prometheus metrics也是Nacos「拥抱云原生」的第一步。

prometheus采集metric信息
通过访问http://{ip}:9090/graph可以看到prometheus的采集数据，在搜索栏搜索nacos_monitor可以搜索到Nacos数据说明采集数据成功

Grafana显示metric信息

生态

Dubbo生态
在阿里内部环境中，Dubbo和Nacos天然结合在一起，在外部，由于Nacos的缺失，传统注册中心（zk）解决方案让Dubbo在服务治理、流量治理、服务运营和管理方面的能力被削弱了，Nacos的开源将助力Dubbo释放其已有的威力。从V0.6版本开始支持了Dubbo的服务注册和配置管理。

Spring Cloud生态
Nacos会无缝支持Spring Cloud，为Spring Cloud用户其提供更简便的配置中心和注册中心的解决方案，使用Nacos不用再仅仅为使用服务和配置，就需要使用Spring Cloud Eureka Server，Spring Cloud Config Server，Git，RabbitMQ/Kafka 起码四个开源产品。

对接Spring Cloud生态的实质：

实现了spring-cloud-starter-alibaba-nacos-discovery。
TODO

Service Mesh

Nacos支持Istio MCP协议
实现的逻辑就是启动一个gRPC Server来进行MCP数据的传输，代码可以参考。

认证鉴权
认证采用的是JWT Token（JSON Web Token），通过用户用户名和密码获取一个token，后续每次请求都会带上token来表明身份。

鉴权
Nacos采用的鉴权系统使用的是基于角色的访问控制RBAC（Role-Based policies Access Control）模式。
已管理员账号nacos登录平台，进行一下操作：
管理用户

管理角色

管理权限