从 Nacos 3.0.3 启动日志看架构演进：Server API 与 Console 分离实践

本文基于一次 Kubernetes 集群中 Nacos 3.0.3 三节点集群的真实启动日志，拆解 Nacos 3.0 的模块化启动流程、集群发现机制，以及这些变化对 K8s 部署和运维的实际影响。

一、背景

Nacos 3.0 相比 2.x 最显著的变化之一，是将 Console（控制台） 从 Server 中解耦，形成独立的 Web 模块。这一变化在启动日志里体现得非常直观：同一个 Pod 内会先后出现 三个横幅，分别代表核心 Server、Server API 和 Console。

我们部署的环境是：

Kubernetes，命名空间 yichen-default
StatefulSet nacos-cluster，3 副本
Headless Service nacos-cluster-hs 提供稳定 DNS
客户端入口 Service nacos-cluster
外部存储（MySQL），非嵌入式 Derby

下面结合完整日志逐段分析。

二、日志全景与启动时间线

日志从 14:44:38 开始，到 14:45:02 Console 启动成功，总耗时约 24 秒。关键节点如下：

时间	事件
14:44:38	打印集群成员列表，三个 FQDN 解析正常
14:44:39 ~ 14:44:53	`Nacos Server is starting...` 周期性打印，核心 Server 启动中
14:44:54	`Nacos started successfully in cluster mode with external storage in 17782 ms`
14:44:54	打印 Nacos Server API 3.0.3 横幅，Port 8848
14:44:55 ~ 14:44:59	`Nacos Server API is starting...`
14:44:59	`Nacos Server API started successfully in 5423 ms`
14:45:00	打印 Nacos Console 3.0.3 横幅，Port 8080
14:45:00 ~ 14:45:01	`Nacos Console is starting...`
14:45:02	`Nacos Console started successfully in 2959 ms`

整个过程 无 ERROR，属于健康启动。三个模块串行启动：先核心 Server，再 Server API，最后 Console。这种顺序保证核心注册/配置能力优先可用，控制台稍后就绪。

text 复制代码

Nacos Server 3.0.3
Running in cluster mode, All function modules
Pid: 1

这是 Nacos 启动器打印的总览信息，说明：

版本 3.0.3
运行在 集群模式，不是单机模式
启用了 全部功能模块
Pid: 1 说明容器主进程就是 Nacos，没有额外 shell 包裹

紧接着打印集群成员：

text 复制代码

The server IP list of Nacos is [
nacos-cluster-0.nacos-cluster-hs.yichen-default.svc.cluster.local:8848,
nacos-cluster-1.nacos-cluster-hs.yichen-default.svc.cluster.local:8848,
nacos-cluster-2.nacos-cluster-hs.yichen-default.svc.cluster.local:8848
]

这说明 nacos.member.list 配置生效，三个 Pod 的 FQDN 都能被正确识别。这也是 Headless Service 必须设置 publishNotReadyAddresses: true 的原因：Pod 还没 Ready 时，成员列表就要能解析到彼此，否则集群组不起来。

text 复制代码

Nacos Server API 3.0.3
Running in cluster mode, All function modules
Port: 8848

这是 核心 API 模块 的横幅。Nacos 3.0 把对外 HTTP API 明确命名为 "Server API"，监听 8848，负责：

服务注册与发现
配置发布与拉取
集群内部通信

日志随后打印：

text 复制代码

Nacos Server API is starting...
Nacos Server API started successfully in 5423 ms

说明 API 模块在核心 Server 启动完成后，又花了约 5.4 秒完成自己的初始化。

text 复制代码

Nacos Console 3.0.3
Running in cluster mode, All function modules
Port: 8080
Console: http://10.42.14.93:8080/index.html

这是 控制台模块 的横幅，监听 8080。注意这里打印的 10.42.14.93 是当前 Pod IP，不是 Service IP，说明 Console 监听在 0.0.0.0:8080，并通过本机地址展示访问入口。

日志随后：

text 复制代码

Nacos Console is starting...
Nacos Console started successfully in 2959 ms

Console 独立启动，约 3 秒完成。这正是 Nacos 3.0 架构升级的核心：控制台不再与 8848 端口耦合，可以独立部署、独立限制访问。

四、为什么会有两个 "Running in cluster mode"？

很多同学第一次看到会疑惑：为什么 Server API 和 Console 都打印 "Running in cluster mode, All function modules"？

原因是 Nacos 3.0 将原本单体应用拆成了多个模块，每个模块启动时都会打印自己的运行模式。当前镜像仍然是"all-in-one"打包，所以三个模块在同一个进程、同一个 Pod 内依次启动，但每个模块都有自己的启动横幅和生命周期日志。

这带来两个实际好处：

安全隔离 ：可以只把 8848/9848 暴露给业务，把 8080 限制在管理网络。
灵活部署：未来可以把 Console 拆成独立 Deployment，甚至一个 Console 管理多个 Nacos 集群。

五、外部存储与启动耗时

日志中这一行很关键：

text 复制代码

Nacos started successfully in cluster mode with external storage in 17782 ms

external storage 表示 Nacos 使用了外部数据库（通常是 MySQL），而不是内嵌 Derby。集群模式下必须使用外部存储，否则三个节点数据无法共享。

核心 Server 启动耗时约 17.8 秒，主要花在：

数据库连接与表结构检查
集群成员初始化
配置缓存加载

随后 Server API 又花了 5.4 秒 ，Console 花了 3.0 秒 。总启动时间约 24 秒，对于 Nacos 3 节点集群属于正常范围。这也解释了为什么 StatefulSet 的 startupProbe 要设置 failureThreshold: 30、periodSeconds: 10，给足 5 分钟启动窗口。

六、对 K8s 部署的启示

结合我们使用的 StatefulSet 和 Service 清单，这份日志验证了几个关键设计：

1. Headless Service 必须启用 `publishNotReadyAddresses`

日志中三个 FQDN 在启动早期就能解析，说明 Headless Service 的 publishNotReadyAddresses: true 生效。否则 Pod 未 Ready 时 DNS 不发布，成员列表解析失败，集群会卡在启动阶段。

2. 探针端口要对准 Console 的 8080

Nacos 3.0 的健康端点位于 Console 模块：

text 复制代码

/nacos/v3/console/health/readiness
/nacos/v3/console/health/liveness

端口是 8080，不是 8848。我们的 StatefulSet 探针配置正确。但要注意：如果 nacos.security.ignore.urls 没有放行 /v3/console/health/**，探针可能返回 401。日志启动成功不代表探针一定通过，建议实测：

bash 复制代码

kubectl exec -it nacos-cluster-0 -- \
  curl -i http://127.0.0.1:8080/nacos/v3/console/health/readiness

3. PDB 保护多数派

三节点集群配合 minAvailable: 2 的 PDB，可以保证节点维护时最多主动驱逐一个 Nacos Pod，避免 JRaft 多数派丢失。注意 PDB 不约束滚动更新，StatefulSet 更新时仍会逐 Pod 重建。

4. 资源限制要留余量

日志显示启动阶段有较多初始化工作。当前 requests: 500m/1Gi、limits: 1500m/2Gi 对三节点集群是合理起点。如果配置数据量大，启动时间会进一步拉长，startupProbe 的 5 分钟窗口要保留。

七、常见误区与排查建议

看到两个 Banner 以为重复启动

不是。这是 Server API 和 Console 两个模块各自打印，属于 Nacos 3.0 正常行为。
只暴露 8848，忘记 9848

Nacos 2.x/3.x 客户端使用 gRPC，端口是 8848 + 1000 = 9848。客户端入口 Service 必须同时放行 8848 和 9848。
Console 访问不通

Console 监听 8080，不是 8848。K8s 内访问用 nacos-cluster:8080，本地调试用 port-forward：
bash 复制代码
```
kubectl -n yichen-default port-forward svc/nacos-cluster 8080:8080
```
集群成员列表只有一个 IP

检查 nacos.member.list 是否包含三个 FQDN，以及 Headless Service 的 publishNotReadyAddresses 是否为 true。
启动成功但探针失败

优先检查健康端点是否返回 401，以及 SERVER_SERVLET_CONTEXTPATH=/nacos 是否生效。

八、总结

这份 Nacos 3.0.3 启动日志是一份很典型的"架构演进说明书"：

三个 Banner 对应核心 Server、Server API、Console 三个模块；
串行启动 保证核心能力优先可用；
Headless DNS 让三节点集群在 K8s 中稳定组建；
外部存储 是集群模式的必要条件；
Console 独立 8080 为安全隔离和灵活部署打下基础。

从运维角度看，日志无 ERROR、成员列表完整、三个模块均启动成功，说明当前 Nacos 集群状态健康。后续重点应放在：健康探针实测、PDB 与滚动更新策略、以及客户端入口 8848/9848 的连通性验证。

Nacos 3.0 的模块化不是简单的"多打印一个 Banner"，而是为云原生环境下的安全、可观测和可运维性做的结构性升级。理解这些日志，才能把集群部署得稳、排障排得快。

从 Nacos 3.0.3 启动日志看架构演进：Server API 与 Console 分离实践