Appearance
Nacos 基础
单体应用时代这些问题不明显：一个应用、一个配置文件、一个数据库连接，启动脚本里写死就行。服务拆多以后，订单服务有多台实例，库存服务也有多台实例，某个实例发布重启后 IP 和端口可能完全变了；同时，连接池大小、限流开关、灰度参数这些配置又不适合每次都登录机器改文件再重启。Nacos 解决的就是这两类问题："服务地址会变化"和"配置需要集中变更"。
Nacos 的全称是 Dynamic Naming and Configuration Service，名字已经标出了两条核心能力：
| 能力 | 做什么 | 常见场景 |
|---|---|---|
| Naming（服务注册与发现） | 服务实例的登记和查询 | order-service 下面当前有哪些可用的 IP:PORT |
| Configuration（配置中心） | 配置的保存、发布、监听和回滚 | application.yaml 改了之后应用读到新值 |
一、运维视角下的组件构成
从运维角度看，Nacos 不只是浏览器里那个控制台页面。它至少包含这几部分：
| 部分 | 做什么 | 部署依赖 |
|---|---|---|
| Nacos Server | 提供配置、注册、查询、推送接口的服务端进程 | Java 17+、端口、配置文件 |
| 控制台 | 人在浏览器里查看和修改配置、服务、权限、集群状态 | 8080 端口 |
| 客户端 SDK | 业务应用用它注册实例、读取配置、监听变更 | 应用侧的 nacos-client 依赖 |
| MySQL | 保存配置内容、用户账号、权限、历史版本 | 集群模式必须依赖外部数据库 |
| 集群通信 | 多个 Nacos 节点之间同步状态、保持一致性 | gRPC 和 Raft 端口互通 |
很多排错卡在"控制台正常但业务不正常"之间。控制台能登录只说明管理入口可用；业务应用还要能连到服务端 API、通过鉴权、注册实例、读取配置——这几个环节跟控制台是不同的端口和路径。
二、在整个架构里的位置
请求进系统时先经过网关或 Nginx，Nacos 在旁边提供"查服务地址"和"取配置"的能力。调用方拿到实例列表后，请求由客户端框架直接发给目标实例——不会每次都穿过 Nacos。这个位置决定了排查时的优先级：接口 502、网关超时、Pod 网络不通，第一现场通常在入口或网络层；如果服务列表里缺实例、配置没下发、客户端启动时就报 Nacos 连接异常，再回到 Nacos 排查。
三、服务注册与发现的交互方式
服务提供方把自己的地址登记到 Nacos，调用方向 Nacos 查询服务名下有哪些可用实例：
服务和实例是两个不同的对象。服务是逻辑名称，比如 order-service；实例是具体的进程地址，比如 192.168.10.21:8080。一个服务下面可以有多个实例，发布、扩容、缩容、机器故障时实例列表会变化。
服务发现的常见字段：
| 字段 | 含义 | 示例 |
|---|---|---|
| 服务名 | 逻辑服务名称 | order-service |
| 分组 | 服务分组 | DEFAULT_GROUP |
| 命名空间 | 环境或租户隔离 | public、prod |
| 实例 IP/端口 | 具体进程地址 | 192.168.10.21:8080 |
| 健康状态 | 是否可被调用 | healthy=true |
| 权重 | 客户端选择实例时的参考 | 1.0 |
| 元数据 | 版本、机房、灰度标签等附加信息 | version=v2 |
Nacos 里有临时实例和持久实例的区别。普通微服务进程大多是临时实例——由客户端 SDK 保持心跳，进程停了、心跳断了，实例被标记为不健康然后摘除。持久实例更像一条人工维护的固定记录，不会因为客户端连接断开就自动消失，适合少量固定后端或需要手动管理的服务条目。
四、配置中心的三段定位
配置中心保存应用的运行配置，YAML、properties、JSON、纯文本都可以。一份配置靠三段组合来定位：
text
namespace + group + dataId| 字段 | 说明 | 示例 |
|---|---|---|
namespace | 命名空间，常用于环境隔离 | public、dev、prod |
group | 分组，同一命名空间内进一步分组 | DEFAULT_GROUP |
dataId | 配置标识，习惯写成文件名形式 | application.yaml |
配置发布后 Nacos 会推送变更通知给监听该配置的客户端。但应用能不能热更新，取决于客户端框架和业务代码——Nacos 只负责推送，"推送到了"和"业务变量已经换成新值"之间有距离。启动配置（数据源、端口等）通常需要重启；动态配置（开关、阈值、灰度比例）如果应用框架支持且代码写了监听，可以运行时生效。
配置中心最有运维价值的几个能力：集中发布（不用登机器改文件）、历史版本（知道什么时候谁改了什么东西）、回滚（改错了可以退回去）、权限控制（控制谁能改生产配置）、变更推送（应用实时感知配置变化）。
五、namespace、group、dataId 的实例
三者组合起来可以同时支持多个环境和多个业务线：
| namespace | group | dataId | 含义 |
|---|---|---|---|
dev | DEFAULT_GROUP | order-service.yaml | 开发环境订单服务配置 |
prod | DEFAULT_GROUP | order-service.yaml | 生产环境订单服务配置 |
prod | PAY_GROUP | pay-service.yaml | 生产环境支付服务配置 |
排查"配置读不到"时，三段必须一起对照——不同 namespace 下可以有完全同名的 dataId 和 group，只看 dataId 很容易误判。
六、和 Kubernetes Service 的关系
两者都能让应用找到服务，但不在同一层：
| 对比项 | Nacos | Kubernetes Service |
|---|---|---|
| 所在层 | 应用层服务发现 + 配置管理 | 集群网络抽象 |
| 使用方式 | 客户端 SDK 查服务读配置 | Pod 通过 DNS 或 ClusterIP 访问 |
| 注册对象 | 服务名、实例、配置、元数据 | Service、EndpointSlice、Pod |
| 配置管理 | 内置，带版本和回滚 | ConfigMap / Secret，无版本概念 |
| 常见体系 | Spring Cloud Alibaba | K8s 原生工作负载 |
K8s 里也可以跑 Nacos。Spring Cloud 应用已经深度依赖 Nacos 做服务发现和配置中心时，迁到 K8s 后通常保留 Nacos，K8s Service 负责集群网络入口。两者可以并存，职责不同。新项目如果全跑在 K8s 里，是否继续用 Nacos 取决于团队技术栈、配置管理的复杂度、灰度能力需求和对 Nacos 的运维成本。
七、Nacos 3.x 的几个关键变化
实验使用的 Nacos 3.2.1 和旧版资料有几处差异：
| 项 | Nacos 3.2.1 实际情况 |
|---|---|
| 控制台端口 | 默认 8080（旧版是 8848/nacos） |
| 服务端 API 端口 | 8848，/nacos 路径 |
| Java 版本 | 需要 Java 17+ |
| API 版本 | 新接口以 /v3 为主，旧 /v1 资料不能完全照搬 |
| 鉴权 | 启动脚本对鉴权配置项检查更严格，Token Secret 等必须有效填充 |
旧资料经常直接访问 8848/nacos 打开控制台，Nacos 3.x 会提示控制台改到了 8080/next/。8848 更偏服务端 API 和客户端通信入口。
八、运维关注点总览
| 方向 | 关注什么 |
|---|---|
| 部署 | Java 版本、端口、启动参数、systemd、集群文件 |
| 存储 | MySQL 连接、表结构、备份、schema 版本匹配 |
| 配置 | namespace/group/dataId 三段对齐、历史版本、回滚、灰度 |
| 服务 | 临时/持久实例、心跳、健康状态、权重、元数据 |
| 集群 | 节点状态、端口互通、版本一致、cluster.conf |
| 权限 | 登录账号、Token、鉴权参数三节点一致性 |
| 排错 | 客户端连接、配置不生效、服务掉线、节点异常 |
控制台正常不等于业务正常。控制台是给人看的，服务端 API 和客户端通信才是应用真正依赖的。