- 博客(239)
- 资源 (3)
- 收藏
- 关注
RSS订阅原创 连接断了 3 秒内自动切到备用节点：Nacos 2.x 客户端的 4 项底层革新
如果未来你用的是 3.x 客户端，RpcClient 的实现可能有变化，但连接管理的设计思路（统一连接、双向流、自动重连）预计保持不变。评论区留数字：1=2.x 客户端，体验过推送加速 2=1.x 还没升级 3=1.x 客户端连 2.x 服务端（降级模式） 4=不确定版本。1.x 到 2.x 的四项革新：连接管理从分散到统一、推送从轮询到双向流、容错从被动到主动重连、版本从固定到协商降级。这篇文章拆开这 4 个能力——每一个都有具体的源码类名、连接状态流转图、和 1.x 的对比。
2026-07-20 17:18:07
310
原创 Nacos 改了一行配置，飞书群里 30 秒内收到了通知：自定义配置变更通知插件实战
你们的 Nacos 配置变更有通知机制吗？生产环境里，一行配置改错了，服务出问题，排查了半小时才发现是配置问题。如果配置变更的时候能推一条通知到运维群里，发现时间可以从 30 分钟缩短到 30 秒。preChange 中任何一个返回 false，整个变更被拦截。配置变更前和变更后都可以触发你自定义的逻辑。Nacos 控制台里有一个"历史版本"功能，能看到谁在什么时间改了哪行配置。
2026-07-13 10:05:13
240
原创 公司不让装 MySQL，Nacos 接了 PostgreSQL 跑了 6 个月：ExternalDataSourcePlugin 实战
你可以写一个 ExternalDataSourcePlugin 把 MySQL 替换成 PostgreSQL、TiDB、OceanBase 或其他兼容 JDBC 的数据库。他们的基础设施里只有 PostgreSQL、或者用的是 TiDB / OceanBase 这样的分布式数据库。如果你用的是 2.0.x，需要升级或使用 MySQL。你们的 Nacos 用的什么数据库？OceanBase 的 Oracle 模式 SQL 方言和 MySQL 不兼容，需要单独适配（和 PostgreSQL 类似的工作量）。
2026-07-13 10:03:57
303
原创 接了 LDAP 之后，Nacos 的用户管理从“谁都能登录“变成了“只有 AD 里有的人才行“：自定义鉴权插件实战
*** 插件类型标识（和 application.properties 中的 auth.system.type 对应）*//*** 从请求中提取身份信息（如 Token、用户名）*//*** 验证身份是否合法（检查 Token 是否有效、用户是否存在）*//*** 生成访问凭证（登录成功后返回 Token）*/方法调用时机你的实现插件加载时返回"ldap"每个请求进来时从 Header 提取 TokenToken 验证阶段校验 Token 有效性login()
2026-07-13 09:59:39
244
原创 实战：用HealthCheckProcessor实现Redis探活插件
*** 执行健康检查* @param task 健康检查任务，包含实例信息* @param cluster 集群信息*//*** 返回这个 Processor 处理的检查类型名称* 必须和实例注册时指定的 healthCheckType 一致*/方法作用你的实现执行实际的健康检查逻辑连 Redis 发 PINGgetType()返回检查类型标识"REDIS"getOrder()（可选）排序优先级默认 1000。
2026-07-11 14:49:38
229
原创 Nacos 的 SPI 扩展点有 12 个，你只需要知道这 5 个：插件机制从原理到优先级排序
你只需要写一个实现类，打个 jar 包，放到 Nacos 的 plugins 目录下。Nacos Server 启动时扫描 plugins 目录 → 读 META-INF/services → 实例化 → 初始化 → 排序 → 注册。如果你在 2.0.0 上开发的插件，升级到 2.1.x 后可能需要适配接口变更。这篇文章拆开 Nacos SPI 的加载流程源码，搞清楚它和 Java SPI 的区别、扩展点的优先级怎么排、你写插件时需要知道的最小接口集合。不需要改任何配置文件（除了插件自身需要的配置参数）。
2026-07-11 14:33:30
390
原创 控制台点一次“服务列表“，后端拦截器链和查询走了这条路：控制台模块源码解析
这篇文章拆开 console 模块，看清楚控制台的三件事：API 怎么设计、服务/配置数据怎么查、权限校验的拦截器链怎么工作。你点"编辑配置"再点"发布"，权限是在哪一层拦下没权限的用户的？若你用的是更早版本，控制台 API 与 naming/config 的 Controller 是耦合在一起的，包路径会有差异。打开 Nacos 控制台，点"服务管理 → 服务列表"，页面刷出一堆服务名、实例数、健康状态。点进某个服务的详情，除了实例列表，还要展示服务级元数据（保护阈值、选择器等）。
2026-07-09 15:50:09
334
原创 一条配置发布，服务端如何做到“改一次全网秒级生效“：配置管理模块源码走读
时间点谁的动作原因30s客户端超时时间客户端设定的请求超时29.5s服务端主动返回提前 500ms 返回，避免客户端先超时导致请求浪费< 29.5s配置变更提前唤醒有变更时立即响应，实现"准实时"长轮询本质是用"可控的延迟"换"低频的连接"。相比每秒轮询，它大幅减少了无效请求；相比服务端主动推送，它不需要维护每个客户端的连接状态（HTTP 场景下）。
2026-07-09 14:38:28
325
原创 服务端收到一个注册请求，从 Controller 到内存 Map 走了 5 层：服务注册模块源码走读
从请求入口开始，拆开一次注册请求在 Nacos-Server 内部的完整链路：Controller 收请求 → ServiceManager 管理服务 → ConsistencyService 决定一致性协议 → 数据落内存 → 异步通知订阅者。是 2.x 的重要变化——每个客户端连接对应一个唯一 clientId，服务端以 client 为维度管理它注册的所有实例。订阅了这个服务的客户端会收到 gRPC 推送，拿到最新的实例列表。这一步是异步的，不阻塞注册请求的返回。这是最关键的分叉点。
2026-07-09 10:25:52
310
原创 一个 startup.sh 背后，Nacos 服务端启动跑了 4 个阶段：服务端启动流程源码解析
你会看到它其实就是一个套了壳的 Spring Boot 应用，但在 Spring 容器启动前后，Nacos 塞进了自己的一整套初始化逻辑。1.x 的启动流程主体一致，但插件加载（SPI）和集群成员管理（MemberLookup）在 2.x 有较大重构，1.x 读者请注意差异。如果你只启动了 1 个节点，或者节点间网络不通，启动日志会一直打印成员发现的重试，看起来像卡死。，因为它提供了 SPI 插件加载和一致性协议的底座，naming 和 config 都依赖它。standalone 模式直接跳过这一步。
2026-07-09 10:23:34
379
原创 连接断了 3 秒内自动切到备用节点：Nacos 2.x 客户端的 4 项底层革新
如果未来你用的是 3.x 客户端，RpcClient 的实现可能有变化，但连接管理的设计思路（统一连接、双向流、自动重连）预计保持不变。评论区留数字：1=2.x 客户端，体验过推送加速 2=1.x 还没升级 3=1.x 客户端连 2.x 服务端（降级模式） 4=不确定版本。1.x 到 2.x 的四项革新：连接管理从分散到统一、推送从轮询到双向流、容错从被动到主动重连、版本从固定到协商降级。这篇文章拆开这 4 个能力——每一个都有具体的源码类名、连接状态流转图、和 1.x 的对比。
2026-07-07 14:02:27
369
原创 getConfig 返回的内容可能是 30 秒前拿到的：配置管理 SDK 从拉取到监听的完整链路
如果你还在用 1.x，长轮询章节的描述适用，gRPC 相关的不适用。如果超时没有变更，返回空列表，客户端重新发起请求。评论区留数字：1=基本实时，2.x 客户端 2=偶尔有 10-30 秒延迟，1.x 长轮询 3=不确定，没测过 4=不用配置推送，都是重启生效。如果你的配置变更发生在客户端刚发起轮询的瞬间，服务端立即返回，延迟接近 0。第 5 步"配置预加载"是 NacosConfigService 特有的——它在初始化时就把所有 addListener 过的配置从服务端拉一遍，填满本地缓存。
2026-07-07 11:48:01
1033
原创 registerInstance 一行代码背后，NamingService 初始化了 7 个组件：服务发现 SDK 核心源码
当 Nacos 服务端不可用时，FailoverReactor 从磁盘读取最后一次成功的缓存数据，保证客户端在断网期间仍能返回（可能过时的）实例列表。这篇文章拆开 NamingService 从构造到工作的全过程——初始化做了什么、注册请求怎么走的、订阅推送怎么收的、心跳怎么发的、本地缓存怎么存的。的初始化已经做了 7 件事：加载配置、解析服务端地址、建立 gRPC 连接、注册认证信息、启动心跳线程、初始化本地缓存、注册服务端变化监听。它为每个注册的实例维护一个 BeatInfo，定时发送心跳。
2026-07-07 11:45:10
342
原创 nacos-client 拆开一看只有 6 个包，但 ClientWorker 一个类就占了 1800 行：客户端整体架构拆解
nacos-client 在后台启动了至少 6 个线程：一个心跳发送线程、一个配置拉取线程、一个 gRPC 连接管理线程、一个 UDP 推送接收线程、一个本地缓存更新线程、一个重连检测线程。你以为你写的是一个普通的 SDK 调用，实际上你启动了一个后台常驻的小型服务。在 Nacos 1.x 里，ClientWorker 使用 HTTP 长轮询做配置监听。接口层定义"你能做什么"，业务层决定"怎么做"，通信层管"怎么连"，基础层管"公共能力"。你注册的 Listener 不是被"调用"的，而是被"通知"的。
2026-07-06 14:58:57
322
原创 Nacos生产落地20条军规：从能跑到不出事
这篇文章把这份清单拆成四个阶段：部署前 → 上线前 → 运行中 → 事故时。不用记住全部 20 条，只需要在每个阶段打开对应的部分。⚠️ 本文适用于基于 Nacos 2.3.x cluster 模式的生产部署。单机模式部署的检查项为 1-4 和 18-20，中间 5-17 不适用。如果你的 Nacos 运行在 K8s 上，部分"操作系统层面"检查项由 K8s 的 liveness/readiness probe 替代。
2026-07-06 14:50:03
243
原创 服务注册不上了，你敲了 5 个命令排查，第 3 个就找到了：8 个高频问题的一键排
某个核心服务突然不可达。你的第一反应是什么？“应该是网络问题。”——过了 10 分钟，不是。“是不是注册中心挂了？”——又过了 5 分钟，8848 端口好好的。“Nacos 日志里有异常吗？”——grep 了半天，没找到。30 分钟过去了。还没有定位到问题。最后发现是客户端版本和 Nacos 服务端版本不兼容——客户端 1.4.2 连了 2.3.0 的服务端，HTTP 请求头格式不对，注册请求被静默丢弃了。
2026-07-06 14:47:07
378
原创 控制台点了 3 下，100 台机器同时重启了：Nacos生产运维的 5 个反直觉操作
Nacos 控制台有批量导出/导入功能。用它改生产配置的风险是——没有 diff、没有审批、没有回滚预览。控制台批量修改的三个黑洞问题后果导入时覆盖已有配置，无差异对比不知道改了哪些行、没改哪些行无审批流程一个人点一下，几百条配置全变回滚只能逐条历史Nacos 的配置历史是单条维度，不支持批量回滚推荐方案# 1. 先导出当前配置（备份）# 2. 通过 API 逐条更新（脚本批量执行，保留 diff 记录）/bin/bash$(date。
2026-07-06 14:08:32
310
原创 Nacos 认证关闭的代价有多大
Nacos 从测试环境推到了生产。部署脚本跑得很顺利——解压、改 cluster.conf、startup.sh。8848 端口通了，服务注册正常，灰度发布正常。20 分钟后，在公网扫到了这个 8848 端口，拿到了所有命名空间下的所有配置——数据库密码、Redis 密码、消息队列的 AK/SK、第三方支付的密钥。全部明文。一览无余。问题出在哪？Nacos 2.x 的认证默认是。里一行默认为 false。新部署的 Nacos 控制台直接裸在 8848 端口上，任何人都能访问。
2026-07-06 13:48:39
507
原创 nacos-client 拆开一看只有 6 个包，但 ClientWorker 一个类就占了 1800 行：客户端整体架构拆解
这两行背后发生了什么？nacos-client 在后台启动了至少 6 个线程：一个心跳发送线程、一个配置拉取线程、一个 gRPC 连接管理线程、一个 UDP 推送接收线程、一个本地缓存更新线程、一个重连检测线程。你以为你写的是一个普通的 SDK 调用，实际上你启动了一个后台常驻的小型服务。这篇文章把 nacos-client 从 Maven 依赖里拉出来，拆开看它到底由哪些模块组成、模块之间怎么配合、你写的每一行 API 背后触发了什么。
2026-07-02 16:19:00
187
原创 5 分钟做完技术选型，3 张对比表只帮你走到门口：Nacos 选型决策树的 6 步推演
过去一个月，你在 Nacos 话题下看了差不多四篇文章——注册中心怎么选、配置中心怎么选、要不要从 ZK 迁过来。每篇结尾都有一张对比表格，让你自己判断。看完了。还是没做出决定。不是表的问题。是决策环境变了——你没有在一个星期内同时换掉注册中心和配置中心。你的情况是：手上有一个正在跑的项目，框架写死了，配置中心不想动，注册中心也不想冒险换。你需要的不是"Eureka vs Consul 哪个好"，而是一个能代入当前位置、给出下一步该怎么走的决策路径。这篇文章不列新的对比表。
2026-07-02 15:08:16
193
原创 Dubbo 从 Zookeeper 迁到 Nacos 后，运维少记了 3 个端口号：两个注册中心的 4 笔账
2018 年进公司接手的第一个 Dubbo 项目。注册中心用的 Zookeeper。我说"记不住"。运维说"习惯了就好"。后来切到 Nacos。纸条上的端口号减到两个：8848（HTTP）和 9848（gRPC）。Dubbo 的服务端口不用和注册中心耦合了——注册信息通过 Nacos 的 API 透传，不是像 ZK 那样把 Dubbo URL 直接写进 ZNode 的 data 里。这篇文章不是要证明 Nacos 比 Zookeeper 好。
2026-07-02 15:03:48
257
原创 如果只比配置中心，Apollo 有 3 个地方让你回不去：Nacos vs Apollo 深度拆解
去年跟一个金融科技团队交流。他们注册中心用的 Nacos，配置中心却单独部署了 Apollo。我说 Nacos 本身就能管配置，你们是不是多维护了一套？对方技术负责人回了一句让我记到现在：“Nacos 的配置管理能用，但 Apollo 有三个东西————在大团队、多部门、多环境的情况下，Nacos 就是追不上。那之后我认真对比了两者。结论是：它们不是在比"谁更好"，而是在比"谁的场景更匹配你的组织形态"。
2026-07-02 14:49:40
388
原创 5 个维度拆完 Nacos、Eureka、Consul：选错注册中心，后面三年都在填坑
2019 年用 Eureka。Spring Cloud 全家桶标配，配合 Ribbon 做负载均衡，很稳。2020 年业务大了，开始需要配置中心。Eureka 只做注册，配不了。于是引入 Apollo。又多了一套部署。2021 年团队觉得维护两套太累，调研了一圈选了 Consul——心想它能同时做注册和配置，还有健康检查，还有 KV 存储。结果 Consul 的配置管理用的是 KV 模型，没有版本回滚、没有灰度发布、没有变更审计。运维疯了。2022 年全面切到 Nacos。
2026-07-02 14:42:44
288
原创 Go 3行代码搞定Nacos注册
2024 年，公司新做了一个 Go 写的实时计算服务。部署完第一件事——要让它能被其他服务发现。注册中心用的是 Nacos。Java 那边有 Spring Cloud Alibaba，切一下就完事了。Go 这边没有 Spring，没有注解，没有 starter。但 Nacos 有 Go SDK。而且不止 Go——Node.js、Python、Rust 都有社区或官方的 SDK。这些 SDK 不管什么语言，底层都走同一条路：Nacos 的 HTTP API 或 gRPC 协议。
2026-06-23 15:21:23
140
原创 Spring Boot原生集成Nacos的3种方式
去年接手了一个 Spring Boot 2.6 的项目。没有 Spring Cloud。没有 bootstrap.yml。注册中心用的是手写的 ZooKeeper 客户端。配置管理靠 Git 仓库 + 手动重启。迁移方案的第一反应：引入 Spring Cloud Alibaba。不行——那套体系依赖 Spring Cloud Context，而 Spring Cloud Context 依赖 bootstrap，整个启动顺序都要改。风险太大。后来走了另一条路：Nacos 官方提供了一个独立的。
2026-06-23 15:06:56
191
原创 5 个注解让服务发现和配置中心同时就位：Spring Cloud Alibaba 集成 Nacos 的完整模板
2022 年公司技术栈改造。当时线上跑着 Eureka 做注册中心，Apollo 做配置中心。两套系统，两拨维护人员，两个端口号要记住，两个健康检查要配，两个告警规则要写。迁移到 Nacos 之后，Eureka 那三台机器回收了。Apollo 那两台也回收了。所有配置文件从 Apollo 的 Portal 搬到 Nacos 控制台，所有服务注册从切到。整个过程里，Spring Cloud Alibaba 的 starter 做了 90% 的工作。你只需要加依赖、配地址、加注解。
2026-06-19 14:00:00
236
原创 临时实例走左边，持久化走右边：拆开 Nacos 源码里决定 AP 还是 CP 的那 3 行 if
三个月后。那台部署的机器已经回收了。控制台里这条记录干干净净消失了。那台部署的机器也回收了。控制台里这条记录还在，状态是"不健康"——挂着，一直挂着，等你手动去删。同一个方法，同一个。两条实例的命运完全不一样，因为。这篇文章把 Distro 和 Raft 在 Nacos 源码里的实现拆开来——不算伪代码，是真正可运行级别的核心逻辑。
2026-06-19 09:00:00
322
原创 # 配置推送延迟从 30 秒打到 10 毫秒：Nacos 1.x 和 2.x 源码级对比
压测发现支付服务的超时时间设太短，需要在 Nacos 控制台把从 3000 改到 5000。改完。保存。发布成功。然后盯着 Grafana 看了 30 秒。超时率纹丝不动。第 31 秒。超时率从 12% 跌到 0.3%。所有实例一次性拉到了新配置。这就是 Nacos 1.x 长轮询的机制——不是推送，是。最快 1 秒，最慢 30 秒，平均 15 秒。取决于你改配置的时刻落在哪个轮询周期里。2.x 把这件事从 30 秒打到了 10 毫秒。不是优化，是底层通信模型换了。
2026-06-18 10:46:20
200
原创 一个 registerInstance 调用，11 个类接力跑了 6 层：Nacos 服务注册源码全拆
你在业务代码里写了这行。服务成功注册到了 Nacos。控制台里多了一条记录。这行代码从你的 JVM 出发，穿过网络，落到 Nacos 服务端，变成 MySQL 里的一行数据。整个过程经过 11 个类，跨越 6 层调用。任何一个环节有 bug，注册就会失败——而且可能不报任何错误。这篇文章用断点调试的方式把整条链路走一遍。每到一个关键类，指给你看它做了什么、把数据传给了谁。
2026-06-18 10:05:49
332
原创 跟着 main 方法走了 700 行，终于看懂 Nacos 是怎么启动的
/ Console 全是 Controller// 不初始化自己的数据模型// 只把前三个模块的 Service 注入进来，通过 REST API 暴露@Autowired// 委托给 naming 模块的 ServiceManager初始化到这里，8848 端口开始接收 HTTP 请求，9848 开始接收 gRPC 连接。启动完成。模式判断：standalone 用 Derby + Distro，cluster 用 MySQL + Raft。这是在 core 模块启动时就决定的。
2026-06-17 14:53:13
439
原创 生产环境换掉一台Nacos机器，我手抖了三次
没有抽象的最佳实践，只有具体条件下的具体选择。换节点：先关旧、再改配置、等五分钟、启新。顺序不对会触发客户端连接风暴。1.x 升 2.x：先服务端逐台滚、后客户端灰度升。不要一步到位。数据迁移：配置走导入导出，服务数据不用搬。MySQL 备份 + cluster.conf 备份缺一不可。跨机房：server-addr 配多地址，心跳超时别太紧。每一次操作前，先在测试环境跑一遍。不是看命令对不对——是看客户端那一侧的反应。你们做过最心惊胆战的 Nacos 运维操作是什么？
2026-06-17 11:31:09
188
原创 一个Listener泄漏干掉了32G内存：Nacos配置管理你不该碰的默认值
周一早上。巡检脚本报了一条我以为是误报的数字。那台跑着订单服务的机器，物理内存 32G，Nacos 客户端的 Java 进程占了 18G。不是 Nacos 服务端——是客户端。一个本该用 200MB 的 SDK。拉出来一看，堆里躺了。每个实例内部挂着一个独立的 HTTP 连接池、一个线程池、一个本地缓存。24,731 个。方法内部每调用一次就注册一个新 Listener，没人去。配置变更越频繁，堆里的 Listener 越多。半年跑了 2 万多个，内存一路涨到 18G。
2026-06-16 15:02:23
986
原创 心跳设15秒、保护阈值0.01：Nacos服务发现你大概率配错了这3个参数
服务发现调优本质上是在故障感知速度和安全兜底之间找平衡心跳：调快能更快发现故障，但增加开销。k8s 环境建议 3 秒。保护阈值：设太高是给自己挖坑——挂了也不踢，调用方拿着死地址请求。生产环境设 0.01 或者干脆不设。实例清除：默认不自动清理，要主动配定期清理策略，别让 MySQL 表膨胀。客户端缓存：Nacos 全挂也能扛一阵，但缓存数据可能过期。权重：改了 weight 必须配自定义 LoadBalancer，Spring Cloud 默认轮询不认 weight。如果你只改一个参数，先改。
2026-06-16 14:03:05
207
原创 半夜三点Nacos挂了没人发现，直到400个服务全红：3张Grafana看板拯救你
注册 TPS（每秒注册次数）# gRPC 连接数趋势# 堆内存使用率# HTTP 平均响应时间 (ms)# 配置推送延迟 (ms)日志：nacos.log 看业务、access.log 看 API 调用、start.out 看启动。access.log 默认关闭需要手动开。Prometheus：Nacos 2.x 原生暴露，无需额外插件。Grafana：官方提供现成 Dashboard JSON，导入即可用。至少建三张看板：总览、性能、资源。告警。
2026-06-16 14:01:54
212
原创 一行配置改了全公司炸锅：Nacos配置管理的6个救命操作
新建：Data ID 用{服务名}-{环境}.yml格式，别全堆 DEFAULT_GROUP。自动刷新：用或，别写轮询。灰度发布：先在 beta 机器上验证，确认没问题再全量。版本回滚：用历史版本功能，不要手动改内容。配置监听：gRPC Push 模式 10~30ms 延迟，秒杀轮询。权限控制：生产环境必须开鉴权，分配读写角色。配置管理最大的价值不是"能改"，而是"改了不出事"。灰度 + 回滚才是生产环境的正确姿势。你们改生产配置一般走什么流程？
2026-06-15 14:48:51
195
原创 一行配置改了全公司炸锅：Nacos配置管理的6个救命操作
新建：Data ID 用{服务名}-{环境}.yml格式，别全堆 DEFAULT_GROUP。自动刷新：用或，别写轮询。灰度发布：先在 beta 机器上验证，确认没问题再全量。版本回滚：用历史版本功能，不要手动改内容。配置监听：gRPC Push 模式 10~30ms 延迟，秒杀轮询。权限控制：生产环境必须开鉴权，分配读写角色。配置管理最大的价值不是"能改"，而是"改了不出事"。灰度 + 回滚才是生产环境的正确姿势。你们改生产配置一般走什么流程？
2026-06-15 14:41:12
405
原创 Pod 重启 IP 就变——Nacos 上 k8s 的三个致命问题与完整解决方案
StatefulSet 不是 Deployment：需要固定 Pod 名 + DNS 做集群发现。Headless Service 不是普通 Service给每个 Pod 独立 DNS。cluster.conf 用 DNS 名不是 IP。Probe 要宽松给 60~120 秒，选举期间容忍失败。MySQL 是必须的：不能指望 Pod 本地的 Derby 来做集群数据同步。绑定 +换 DNS。但每一处都踩过坑才知道。你们 Nacos 跑在什么环境？
2026-06-13 09:36:51
263
原创 3台机器、40分钟、零停机：Nacos生产集群搭建全纪录
MySQL 共享存储：三个节点连同一个 MySQL，数据天然一致。：写三个节点的真实 IP + 9849 端口，不能写 127.0.0.1。逐个启动：间隔 30 秒，避免同时启动导致脑裂。Nginx 统一入口：客户端连 Nginx，不直连任何一台节点。故障验证：关一个节点，确认另两个正常、客户端无感知。从单机到集群，本质上加了三个东西：MySQL 共享存储 + cluster.conf 节点列表 + Nginx 负载均衡。其他配置跟单机一模一样。你们生产环境 Nacos 怎么搭的？
2026-06-12 17:33:05
246
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人