作为 Spring Cloud Alibaba 的 “核心引擎”，Nacos 凭 “服务注册发现 + 配置中心” 双能力，成了微服务架构的标配。但很多开发者只懂 “表面用法”，一到生产环境就踩坑 —— 集群部署崩了、配置推送延迟、服务注册失败… 今天从底层原理到生产实践，一次性讲透 Nacos，小白也能上手。

一、先搞懂 Nacos 核心架构：2 大能力 + 1 个关键协议

Nacos 的核心是 “动态感知” 和 “数据可靠”，架构上分为两大模块，集群模式下靠 Raft 协议保一致，3 分钟看懂：

1. 架构图速览（收藏这张图就够了）

┌─────────────────────────────────────────────┐
│              Nacos集群（3+节点必选）         │
│  ┌─────────┐  ┌─────────┐  ┌─────────┐     │
│  │ Leader  │  │Follower │  │Follower │     │
│  │（写请求）│  │（读请求）│  │（读请求）│     │
│  └─────────┘  └─────────┘  └─────────┘     │
│  ┌─────────────────────────────────────┐   │
│  │        数据层（MySQL/Derby）         │   │
│  │ - 服务表：service_info              │   │
│  │ - 配置表：config_info               │   │
│  └─────────────────────────────────────┘   │
└─────────────────────────────────────────────┘
         ↑                   ↑
         │                   │
┌────────────────┐  ┌────────────────┐
│ 服务发现客户端  │  │ 配置中心客户端  │
│（微服务应用）   │  │（微服务应用）   │
└────────────────┘  └────────────────┘

2. 两大核心能力底层逻辑

（1）服务注册发现：不是 “拉取”，是 “双向联动”

很多人以为 Nacos 是 “客户端定时拉取服务列表”，其实是 “客户端主动上报 + 服务端心跳检测”，确保服务状态实时准：

• 客户端做 2 件事：

1. 启动时发POST /nacos/v1/ns/instance请求，把服务名、IP、端口注册到服务端；

2. 临时实例（默认）每隔 5 秒发心跳，告诉服务端 “我还活着”。

• 服务端做 2 件事：

1. 15 秒没收到心跳→标记 “不健康”；30 秒没收到→从列表删除；

2. 用BeatReactor线程池管理心跳，数据存在ServiceManager内存 + MySQL 双备份。

（2）配置中心：三维模型解决 “配置混乱”

开发 / 测试 / 生产环境配置混在一起？业务线配置冲突？Nacos 用 “Namespace→Group→Data ID” 三维隔离，一看就懂：

• 配置存在哪：config_info表，内容 Base64 加密，改配置时旧版本存config_info_history，支持回滚。

（3）集群必懂：Raft 协议保数据不丢

集群模式下，为啥 3 个节点比 2 个好？靠 Raft 协议：

1. 选 Leader：节点启动后投票，得票过半的当 Leader（负责写请求，如注册服务）；

2. 写数据流程：Leader 收请求→写本地→同步给多数 Follower→确认后返回 “成功”；

3. 关键提醒：单机用 Derby 数据库，集群必须切 MySQL（主从架构更稳），否则数据会丢！

二、服务发现实战：3 步筛选健康实例，2 种负载均衡

微服务调用最怕 “调用到死实例”，Nacos 早想到了 —— 从服务列表到调用，要过 “三层筛选”，再选 “负载均衡策略”。

1. 实例筛选：只留 “健康可用” 的实例

微服务 A 调用微服务 B 时，客户端自动做 3 层筛选：

1. 状态筛：剔除healthy=false的实例（服务端标为不健康的）；

2. 标签筛：按元数据标签选，比如只调用 “上海集群” 的实例（注册时加metadata.cluster=shanghai）；

3. 权重筛：权重 0 的实例不调用（权重可动态调，用来切流量）。

代码示例（只查上海集群健康实例）：

NamingService namingService = NacosFactory.createNamingService(properties);
// 第三个参数：筛选上海集群实例
List<Instance> instances = namingService.selectInstances(
    "order-service", 
    true, // 只选健康实例
    new ArrayList<>(Collections.singletonList(new StringSelector("cluster=shanghai")))
);

2. 负载均衡：默认 2 种，支持自定义

调用实例时怎么分配流量？Nacos 给了现成方案，不够用还能自己写：

• 默认策略 1：Round Robin（轮询）：实例性能差不多时用，按顺序依次调用；

• 默认策略 2：Weighted Random（加权随机）：实例性能不一样时用，权重高的多被调用；

自定义示例（按响应时间选实例，响应快的优先）：

// 1. 实现AbstractLoadBalancer接口
public class ResponseTimeLoadBalancer extends AbstractLoadBalancer {
    @Override
    public Instance chooseInstance(String serviceName) throws NacosException {
        List<Instance> healthyInstances = getHealthyInstances(serviceName);
        // 按响应时间升序排序
        return healthyInstances.stream()
                .min(Comparator.comparingInt(Instance::getResponseTime))
                .orElse(null);
    }
}
// 2. 配置自定义策略
Properties properties = new Properties();
properties.put(PropertyKeyConst.LOADBALANCE, "com.xxx.ResponseTimeLoadBalancer");
NamingService namingService = NacosFactory.createNamingService(properties);

三、配置中心核心：动态推送 + 灰度发布，不重启应用

改配置要重启应用？太麻烦！Nacos 的 “动态推送” 和 “灰度发布”，解决生产环境配置变更痛点。

1. 动态推送：长轮询机制，实时又高效

为啥 Nacos 配置变更秒级生效？靠 “服务端长轮询”，不是 “客户端定时拉取”：

1. 客户端：发请求给服务端，带 “当前配置 MD5” 和 “超时 30 秒”；

2. 服务端：

• 配置没改→请求挂起，等 30 秒或配置变了再返回；

• 配置改了（MD5 不对）→立即返回 “变更的 Data ID 列表”；

3. 客户端：收到通知→拉新配置→更本地缓存→触发@NacosValue刷新。

关键源码：服务端ConfigServletInner处理长轮询，客户端NacosContextRefresher刷新配置。

2. 灰度发布：配置变更不翻车

全量推配置怕出问题？用灰度发布，先推给部分实例验证：

控制台操作 4 步走（超简单）：

1. 进入配置中心→选要改的配置→点 “灰度发布”；

2. 选灰度类型：按 IP（比如只推给 192.168.1.100）或按权重（只推给权重≥0.5 的）；

3. 点 “发布”，服务端只给满足条件的实例推新配置；

4. 验证没问题→点 “全量发布”，推给所有实例。

3. 敏感配置加密：AES + 自定义，不怕明文泄露

数据库密码、API 密钥存明文？Nacos 支持加密：

• 默认 AES 加密：

1. 服务端nacos/conf/application.properties配 32 位密钥：

nacos.core.auth.cipher.key=ABCDEFGHIJKLMNOPQRSTUVWXYZ123456

2. 配置内容加前缀cipher-[aes]:，比如cipher-[aes]:加密后的密码；

• 自定义加密（如 RSA）：

1. 实现ConfigEncryptor接口，写 encrypt/decrypt 方法；

2. 服务端配nacos.core.config.encryptor=com.xxx.RsaConfigEncryptor。

四、生产部署：3 节点集群 + MySQL 主从，高可用不踩坑

很多人把 Nacos 当单机用，一崩全完！生产环境必须 “3 节点集群 + MySQL 主从 + 异地多活”，步骤给你列好了。

1. 3 节点集群部署（必看）

Nacos 集群最少 3 个节点（奇数，满足 Raft 选举），按这个来：

（1）节点规划

（2）3 步配集群

1. 改 cluster.conf：每个节点的nacos/conf/cluster.conf加所有节点地址：

192.168.1.10:8848
192.168.1.11:8848
192.168.1.12:8848

2. 切 MySQL 持久化：改nacos/conf/application.properties：

spring.datasource.platform=mysql
db.num=1
db.url.0=jdbc:mysql://192.168.1.20:3306/nacos_config?characterEncoding=utf8&connectTimeout=1000&socketTimeout=3000&autoReconnect=true
db.user.0=root
db.password.0=123456

3. 初始化数据库：执行nacos/conf/nacos-mysql.sql，创建nacos_config库和表。

生产提醒：节点放不同服务器，避免单服务器崩了集群挂；端口用默认 8848，好维护。

2. MySQL 主从：数据不丢的关键

Nacos 数据存在 MySQL，单 MySQL 崩了怎么办？搞主从：

• 主库：处理写请求（注册服务、改配置）；

• 从库：处理读请求（查服务列表、拉配置）；

• 配置：db.url.0填主库地址，db.url.1填从库地址，Nacos 自动切换。

3. 异地多活：跨地域服务互通

上海集群和北京集群要互调服务？用 Nacos 异地多活：

• 配置同步：控制台 “配置管理→跨集群同步”，选源集群和目标集群，改配置自动同步；

• 服务发现：客户端订阅异地集群服务，代码示例：

// 订阅上海集群的order-service
namingService.subscribe("order-service", "shanghai", event -> {
    List<Instance> instances = ((NamingEvent) event).getInstances();
    // 本地缓存异地实例，调用时用
});

注意：两地网络要通（比如 VPN），同步延迟控制在 1 秒内，不然调用会慢。

五、性能优化：客户端 + 服务端，高并发不卡顿

10 万级服务实例、每秒 1 万次配置查询，Nacos 会卡吗？做好这几点，性能翻番。

1. 客户端优化：本地缓存减请求

客户端别老问服务端要数据，本地缓存起来：

• 服务列表缓存：首次查完存ServiceInfoHolder，默认 30 秒更一次，非核心服务可设 60 秒（nacos.client.naming.refreshInterval=60）；

• 配置缓存：拉完配置存ConfigService，用 MD5 校验，变了才拉新的。

2. 服务端优化：连接池 + 线程池调优

服务端瓶颈在 “MySQL 连接” 和 “线程”，改这几个参数：

# MySQL连接池（高并发设200+）
spring.datasource.druid.maxActive=200
spring.datasource.druid.minIdle=20
# Netty线程池（处理请求，设CPU核心数×2）
nacos.core.scheduler.corePoolSize=8
nacos.core.scheduler.maxPoolSize=16

3. 批量接口：减少请求次数

一次注册 10 个服务，别发 10 次请求，用批量接口：

• 批量注册服务：POST /nacos/v1/ns/instance/batchRegister；
• 批量查询服务：GET /nacos/v1/ns/instance/batchQuery；

效果：请求次数减 90%，服务端压力大减。

六、问题排查：3 招解决常见坑

生产环境遇到问题别慌，按这个流程查：

1. 服务注册失败？查 3 点

1. 客户端配置：serverAddr对不对？是不是集群所有节点地址；

2. 服务端日志：看nacos/logs/nacos.log，有没有 “Raft 选举失败”“MySQL 连不上”；

3. 网络：客户端能不能 ping 通服务端 8848 端口，防火墙是不是没开。

2. 配置推送延迟？查 2 点

1. 长轮询超时：默认 30 秒，可设短点（nacos.config.longPollTimeout=10000，10 秒）；

2. 缓存没刷新：客户端是不是没加@RefreshScope？@NacosValue要配合这个注解才会刷新。

3. 监控告警：Prometheus+Grafana 搞起来

别等出问题才发现，提前监控：

1. 服务端开监控：nacos/conf/application.properties配management.endpoints.web.exposure.include=*；

2. Prometheus 拉指标：地址http://nacos-ip:8848/actuator/prometheus；

3. Grafana 加模板：导入 Nacos 模板（ID：13221），看服务注册数、配置变更次数。

总结

Nacos 不难，关键是懂 “底层原理 + 生产配置”：

1. 架构上：服务注册靠 “双向心跳”，配置中心靠 “三维隔离”，集群靠 Raft 保一致；

2. 部署上：3 节点集群 + MySQL 主从，异地多活跨地域互通；

3. 优化上：客户端缓存减请求，服务端调优抗高并发；

4. 排查上：日志 + 监控，提前发现问题。

按这个指南来，Nacos 在生产环境稳如老狗，微服务治理再也不用踩坑！