【Nacos】 - 技术栈

Nacos 介绍

Nacos（Dynamic Naming and Configuration Service）是阿里巴巴开源的一个动态服务发现、配置管理和服务管理平台，致力于帮助开发者更轻松地构建云原生应用。

起源与发展历程

Nacos的起源可以追溯到2008年阿里巴巴的"五彩石项目"，该项目旨在完成微服务拆分和业务中台建设。在阿里内部，Nacos的前身（Configserver/Diamond/Vipserver）经历了十年双十一的洪峰考验，沉淀了稳定可靠的核心竞争力。

2018年3月，Nacos首次正式对外开源；同年8月进入Apache孵化阶段。2019年4月，Nacos 1.0 GA版本发布，标志着可以大规模在生产环境中使用。2020年，Nacos 2.0通过架构优化实现了10倍性能提升，成为国内开源项目活跃度Top 10

Nacos的核心功能

功能模块	核心能力	主要价值
服务发现与管理	服务注册与发现健康检查负载均衡 DNS服务	动态管理服务实例自动剔除不健康节点
动态配置管理	集中配置管理实时推送版本控制灰度发布	配置变更无需重启应用支持一键回滚:配置管理 →历史版本 →输入`Date ID`和`Group`→详情、回滚、比较
服务治理	元数据管理流量权重多租户隔离权限控制	精细化的服务流量管控和多环境隔离

Nacos解决了什么问题

在微服务架构中，主要面临两大挑战：服务实例动态变化 和配置管理复杂化。Nacos通过以下方式解决：

挑战	传统方式	Nacos
服务发现问题	需要维护服务IP列表，当服务扩缩容时手动更新	Nacos提供自动服务注册与发现，服务实例启动时自动注册，消费者通过服务名动态获取可用实例列表
配置管理问题	配置写在代码或文件中，修改后需要重新打包部署	实现配置中心化管理，配置变更实时推送到应用，无需重启
健康检查问题		自动检测服务实例健康状态，将不健康实例从发现列表中剔除，避免请求失败

对比

维度	无Nacos	有Nacos
服务调用	硬编码IP地址，服务扩容需修改代码	通过服务名动态发现，自动获取可用实例
配置更新	修改配置→打包→部署→重启，周期长	控制台修改配置→实时推送→秒级生效
故障处理	手动下线故障节点，响应慢	自动健康检查，实时剔除不健康实例
环境管理	多套环境配置分散管理，易出错	Namespace隔离，统一管理开发/测试/生产环境
版本控制	无配置版本历史，变更无法回滚	完整版本记录，支持一键回滚
运维效率	人工运维，重复劳动	自动化管理，降低运维成本

安装

配置

三种配置的作用时机

构建时 (pom.xml)

↓ 打包成 jar

运行时准备 (环境变量)

↓ 启动应用

运行时覆盖 (命令行参数)

pom.xml 配置（构建时）
作用时机：Maven 打包时

dev dev

用途：

控制依赖版本

打包时替换配置文件中的占位符

决定打包哪些资源

application.yml 中使用 pom 的变量

spring:

profiles:

active: @env@ # Maven 打包时会替换成 dev/test/prod

特点：打包后就固定了，运行时无法改变

环境变量（运行时准备）
作用时机：启动应用前设置

Linux/Mac

export SERVER_PORT=8080

export SPRING_PROFILES_ACTIVE=prod

java -jar app.jar

Windows

set SERVER_PORT=8080

java -jar app.jar

Docker

docker run -e SERVER_PORT=8080 myapp

用途：

容器化部署（Docker/K8s）

CI/CD 流水线注入配置

操作系统级别的配置

特点：

对整个进程生效

适合敏感信息（不会出现在命令历史）

Spring Boot 会自动读取 SPRING_APPLICATION_NAME 这类环境变量

命令行参数（运行时覆盖）

作用时机：启动应用时指定

java -jar app.jar

--server.port=8080

--spring.profiles.active=prod

--spring.datasource.url=jdbc:mysql://localhost:3306/db

用途：

临时测试

快速覆盖配置

脚本化启动

特点：优先级最高，会覆盖所有其他配置

实际场景对比

场景 1：本地开发

pom.xml 已配置 dev profile

mvn spring-boot:run

简单，使用默认配置

场景 2：Docker 部署

Dockerfile

ENV SPRING_PROFILES_ACTIVE=prod

ENV DATABASE_URL=jdbc:mysql://prod-db:3306/app

CMD ["java", "-jar", "app.jar"]

用环境变量，因为容器化标准做法

场景 3：临时调试

生产环境临时改端口

java -jar app.jar --server.port=9999

用命令行参数，快速且不影响其他配置

场景 4：多环境打包
dev

mvn clean package -Pdev # 打包时决定

优先级总结

命令行参数 (--server.port=8080)↓ 覆盖

环境变量 (SERVER_PORT=8080)

↓ 覆盖

Nacos 远程配置

↓ 覆盖

application.yml (可能包含 pom 变量)

↓ 覆盖

默认值

选择建议

配置类型推荐方式原因

依赖版本 pom.xml 构建时决定

应用名称 application.yml 固定不变

数据库地址 Nacos 环境相关

容器部署环境变量容器标准

临时测试命令行参数快速覆盖

核心原则：越固定的配置越早设置，越灵活的配置越晚设置。

Nacos的核心原理

架构分层

Nacos采用分层架构设计，包括用户层、业务层、内核层和插件层：

用户层：提供OpenAPI、Console控制台、多语言SDK、CLI命令行等接入方式
业务层：实现服务管理、配置管理、元数据管理等核心业务功能
内核层：解决一致性协议、存储、高可用等底层问题
插件层：支持用户管理、权限管理、监控等扩展能力

双协议一致性

Nacos独创性地支持两种一致性协议，根据场景自动选择：

AP模式（Distro协议）：优先保证可用性，适合服务发现场景。即使部分节点故障，系统仍可正常工作
CP模式（Raft协议）：优先保证一致性，适合配置管理场景。确保所有节点配置数据一致

配置推送机制

Nacos采用长轮询（Long Polling）机制实现配置实时推送：

客户端与Nacos Server建立长连接
客户端定期发送配置监听请求
配置变更时，服务端立即响应请求返回新配置
客户端收到配置后更新本地缓存

这种机制既保证了配置推送的实时性（毫秒级生效），又避免了频繁轮询对服务器造成的压力。

健康检查机制

Nacos支持多层次的健康检查：

客户端心跳：服务实例定期发送心跳，超时未收到则标记为不健康
服务端主动探测：支持TCP、HTTP、MySQL等多种协议的主动健康检查
Agent上报：适用于复杂网络环境