Nacos 相关概念整理

咱们先从最基础的说起：Nacos 到底是什么？简单讲，它是阿里巴巴开源的一款工具，专门给微服务架构用的，核心就是帮咱们解决两个大问题 ——“服务地址不好管” 和 “配置文件太分散”，属于 SpringCloud Alibaba 里的核心组件，不用依赖其他额外工具，就能一站式搞定微服务里的服务和配置管理，而且经过阿里双十一大促这种高并发场景验证，稳定性没问题。

一、Nacos 的核心定位：解决微服务的两大痛点

微服务里有两个常见麻烦：一是服务多了，每个服务的 IP、端口记不住，硬写在代码里改起来麻烦；二是每个服务都有自己的配置文件（比如 application.yml），改配置要重启服务，多环境（开发、测试、生产）的配置还容易乱。Nacos 就是针对这两个痛点来的，主要干两件事：帮服务 “登记住址” 并让其他服务找到（服务注册与发现），以及把所有配置集中存起来、改配置不用重启服务（配置管理），另外还能帮 Sentinel 这类组件存规则，避免重启后规则丢失。

二、核心功能一：服务注册与发现（管 “服务地址”）

简单理解，这个功能就像 “服务的通讯录”—— 服务启动时主动把自己的 “联系方式”（IP、端口、服务名）告诉 Nacos，其他服务要调用它时，直接从 Nacos 查通讯录，不用记具体地址。

1. 服务怎么 “登记”（服务注册）

比如商品微服务要注册到 Nacos，流程很简单：

• 第一步：商品微服务里加个 Nacos 的依赖，再在配置文件里写 Nacos 的地址（比如localhost:8848）；
• 第二步：启动商品微服务，它会自动发请求给 Nacos，说 “我是 product-service（服务名），我的 IP 是 192.168.1.100，端口 8081，现在活着呢”；
• Nacos 收到后，会把这些信息存在一个 “分类账本” 里（文档里叫 “双层内存 Map”，简单说就是先按服务名分组，再按每个服务的实例 ID 存具体信息，查起来快）；
• 之后商品微服务会每隔 5 秒给 Nacos 发一次 “心跳”，证明自己还活着 —— 这一步很重要，要是没发心跳，Nacos 就知道服务可能挂了。

2. Nacos 怎么 “维护通讯录”（健康检查）

Nacos 不会光存着地址就不管了，它会定期检查服务是不是还活着：

• 如果 15 秒没收到某个服务的心跳，就给这个服务标上 “不健康”，不让其他服务调用它；
• 如果 30 秒还没收到心跳，就直接把这个服务从通讯录里删掉；
• 要是后来服务恢复了，重新发心跳，Nacos 还会把它加回通讯录。

3. 其他服务怎么 “查通讯录”（服务发现）

比如订单微服务要调用商品微服务，不用硬写 8081 端口，流程是：

• 订单微服务启动时，会告诉 Nacos “我要订阅 product-service 的地址”；
• Nacos 把商品微服务的所有可用实例（比如 8081、8082 两个端口的实例）列表发给订单微服务，订单微服务会存在自己本地；
• 订单微服务还会每隔 30 秒去 Nacos 更刷新一次列表，确保拿到的都是活的服务；
• 最后订单微服务从列表里选一个实例调用（比如结合负载均衡，轮流选 8081 和 8082），这样就算商品微服务加了新实例、或者某个实例挂了，订单微服务也能自动适应。

三、核心功能二：配置管理（管 “配置文件”）

以前每个微服务的配置都存在自己的 application.yml 里，改个数据库密码要重启服务，开发、测试、生产环境的配置还得分别改，特别麻烦。Nacos 的配置管理就是把所有配置集中存起来，解决这些问题。

1. 配置怎么 “集中存”（配置存储）

Nacos 里存配置，靠三个维度区分，避免乱掉：

• DataID：配置文件的唯一名字，默认格式是 “服务名 - 环境名。配置格式”，比如 product-service-dev.yaml（商品服务开发环境的 YAML 配置）；
• Group：配置分组，默认叫 DEFAULT_GROUP，比如可以把 “开发组用的配置” 放一个组，“测试组用的” 放另一个组；
• 命名空间：更大的隔离维度，比如给 “项目 A” 和 “项目 B” 分别建命名空间，避免配置混在一起。

存的时候，直接在 Nacos 控制台把本地 application.yml 里的内容复制过去就行，之后微服务就不用带本地配置文件了，直接从 Nacos 拉。

2. 改配置不用重启服务（动态刷新）

以前改配置要重启服务，现在用 Nacos 不用了：

• 第一步：在微服务的类上加个 @RefreshScope 注解（告诉微服务 “这个类的配置能动态更变”）；
• 第二步：在 Nacos 控制台改配置，比如把商品库存阈值从 100 改成 200；
• Nacos 会主动告诉微服务 “配置改了”，微服务会拉取新配置，自动生效 —— 整个过程不用重启服务，比如商品服务里判断库存的逻辑，立马就能用新的阈值。

3. 配置能共享，不用重复写（配置共享）

很多配置是重复的，比如多个服务都用同一个数据库连接池参数，Nacos 能让这些配置只写一次：

• 同一服务不同环境共享：比如商品服务的开发、测试环境都需要数据库连接参数，就把这些参数存在 product-service.yaml（不带环境名）里，开发环境的 product-service-dev.yaml 只写开发独有的配置（比如开发库地址），测试环境同理；
• 不同服务共享全局配置：比如所有服务的日志级别都是 INFO，就建一个 global-config.yaml，每个服务在配置里说 “我要引用这个全局配置”，这样改日志级别只改全局配置就行。

4. 配置有优先级，避免冲突（配置优先级）

如果多个地方都有同一个配置（比如本地有、Nacos 也有），Nacos 有明确的优先级：bootstrap 开头的文件（比如 bootstrap.yml）> Nacos 远程配置 > application 开头的文件（比如 application.yml）—— 简单说，远程配置比本地配置优先级高，bootstrap 比 application 优先级高，避免改了远程配置没生效的问题。

四、额外功能：帮其他组件存规则（规则持久化）

文档里还提到，Nacos 能帮 Sentinel 存规则 —— 比如 Sentinel 的流控规则（每秒最多允许多少请求），默认存在内存里，服务重启就没了。用 Nacos 存就能解决这个问题：

• 第一步：微服务里加个依赖，告诉它 “用 Nacos 存 Sentinel 规则”；
• 第二步：在 Nacos 里建个配置文件，用 JSON 写好流控规则（比如 “/sentinel2 接口每秒最多 2 个请求”）；
• 微服务启动时会自动从 Nacos 拉取这个规则，就算重启，再次拉取规则还在，不用重新配置。

五、总结：Nacos 到底好用在哪

简单说，它是微服务的 “管家”：

• 管服务：不用记 IP 端口，服务挂了自动剔除，新服务加进来自动识别；
• 管配置：配置集中存，改了不用重启，重复配置能共享；
• 还能帮其他组件存规则，避免重启丢配置。不用装多个工具（比如以前用 Eureka 管服务、Config 管配置），一个 Nacos 全搞定，对开发和运维都友好。