Nacos 2.x通信协议演进：从HTTP到gRPC及端口配置实践

如果你手里维护着 Nacos 2.x，你会发现网上很多教程还停留在“打开 8848 端口，服务就能注册”的老经验，但我建议你把 9848、9849 这两个端口也一并盯死。这不是细节洁癖，而是 Nacos 从 1.x 到 2.x 最被低估的一次内部变化：内部通信协议从 HTTP 体系换成了以 gRPC 为底座的长连接体系。今天这篇就来聊聊这次演进背后做了什么取舍、客户端到服务端到底怎么握手、生产环境要改哪些配置，以及我迁移之后实际踩过的几个坑。

这篇文章适合两类人：一类是正准备把 Nacos 从 1.x 升到 2.x、但又不敢直接动手的运维和开发；另一类是已经在用 2.x、却对“为什么我明明只暴露了 8848 端口，服务却老注册不上去”感到困惑的人。读完以后，你至少能清楚判断：一个 Nacos 2.x 集群，在网络层到底需要放通哪些端口，客户端连接失败时该从哪个方向查，以及老客户端能不能继续混跑。

先说结论：Nacos 2.x 并没有彻底删掉 HTTP 接口，但服务发现和服务配置这条“数据面”的主链路已经切换到 gRPC。HTTP 在 Nacos 里更多退化为管理面、控制台以及给老客户端兜底的兼容通道。理解了这条主次关系，后面所有配置项的调整逻辑就都顺了。

1. 为什么 2.x 一定要换通信底座：HTTP 长轮询的账越算越亏

1.1 1.x 时代的 HTTP 长轮询是怎么“硬扛”海量请求的

Nacos 1.x 的客户端和服务端之间，玩的是纯 HTTP。服务注册是 POST，服务发现是 GET，配置监听是长轮询。长轮询这个机制本身并不复杂：客户端发一个带超时参数的 HTTP 请求过来，服务端如果没有数据变更，就先把连接挂住不返回，等到超时到了或者有变更再响应。

这套设计在规模不大时很优雅，因为它能显著减少空转的请求数量。比如一个配置中心有 100 个客户端在监听同一个配置，1.x 会让这些请求在服务端聚合，大家共享一次“配置有没有变”的检查，而不是各自死循环地刷新。这也是当时 Nacos 1.x 能扛住不少生产流量的原因。

但问题出在“规模上来以后”。服务注册与发现这条链路没有长轮询聚合的红利可以吃。每个实例默认 5 秒发一次心跳，假设你有 10000 个实例，光心跳就是每秒 2000 个 HTTP 请求，还没算上服务消费者的查询请求和配置监听的长连接开销。HTTP/1.1 就算开了 keep-alive，请求头、JSON 序列化、服务端线程调度，每一层都在消耗资源。

1.2 服务治理体量变大后，HTTP 的短板不在“快慢”而在“连接拆装”

很多人对 HTTP 的批评是“慢”，但 Nacos 的场景里，HTTP 真正的问题不是慢，而是“拆”。一次 HTTP 请求，再怎么精简，也要带 method、path、header、cookie 这一堆元数据；响应要经过 JSON 序列化和反序列化。如果只是低频调用还好，当调用量到每秒上万次，这种“每次请求独立封装”的开销就很可观了。

更麻烦的是，HTTP 对“服务端主动推送”这件事天然不友好。1.x 时期做配置变更通知，靠的还是长轮询返回，客户端收到响应后再立刻发起下一次请求，实际上变更通知是有延迟的。服务发现变更的推送，则用了一套 UDP 方案：服务端往客户端上报的地址上扔一个 UDP 数据包。UDP 又没有确认机制，一旦网络抖动丢包，客户端就可能一直拿着旧的服务列表，直到下一次 pull 才纠正。

我当时接手的一个老项目就是这个味道：配置更新后，总有一部分节点的配置不是即时生效，而是要等长轮询超时后下一次请求才拉到新值。排了半天，最后定位到是 UDP 推送丢了包，HTTP 长轮询又没到时间，整个变更周期被拉得很长。这是 1.x 协议栈的结构性限制，不是调调参数就能解决的。

1.3 为什么选 gRPC，而不是自己造一套私有 TCP 协议

有人可能会问：既然 HTTP 连接拆装开销大，那直接用裸 TCP 自定义一套协议不就好了？确实能解决连接复用和序列化问题，但这等于要自己搞定编解码、连接管理、流控、鉴权、负载均衡、超时重试这一整套东西，且每出一种语言的 SDK 就要移植一遍，后续维护成本极高。

gRPC 的好处，是它把底层很多事情标准化了。它基于 HTTP/2，天然支持多路复用，一条 TCP 连接上可以并发跑多个请求，不再需要为每个请求建立独立连接；它默认用 Protobuf 做序列化，序列化结果比 JSON 小不少，反序列化也更快；它还支持 stream 模式，服务端可以把数据持续往客户端推，这正好解决了配置变更和服务发现推送的痛点。

所以 Nacos 2.x 选择 gRPC 并不是追新，而是被真实业务场景逼出来的选择：连接要复用，数据要压缩，变更要能主动推，还要有多语言生态。HTTP/2 的二进制帧、头部压缩、服务端推送这些特性，刚好每一个都打在 Nacos 的痛点上。

2. 看懂 2.x 的内部通信：两个 gRPC 端口和一条“建连-保活-推送”链路

2.1 端口规划：8848、9848、9849，偏移规则的由来

Nacos 2.x 的端口规则，是第一次接触时最容易懵的地方。默认主端口还是 8848，用于 HTTP 管理面和控制台访问。但服务端启动时还会额外监听两个 gRPC 端口：一个是在主端口基础上加 1000，也就是 9848，用于客户端 SDK 连接；另一个是加 1001，也就是 9849，用于集群内服务端节点之间的通信。

这里有一个关键细节：如果你把主端口改成 8888，那 9848 并不会自动变成 9988，除非你同时把偏移量对应调整。Nacos 2.x 里这个偏移量是通过服务端启动时根据主端口动态计算的，所以生产环境里如果你自定义过端口，一定要先把客户端用的 gRPC 端口算清楚，再去开防火墙规则。否则就会出现“主端口能连通，但注册请求一直超时”的诡异现象。

2.2 客户端建立连接的过程：先用 HTTP 拿地址，再用 gRPC 续命

很多初次接触 2.x 的人以为客户端从启动开始就全走 gRPC，这个理解不完全对。nacos-client 2.x 的启动流程其实是分两步的：客户端先通过 HTTP 接口拿到服务端的可用节点列表，再从中选择一个节点建立 gRPC 连接。

第一步拿到节点列表的 URL 一般是类似 /nacos/v1/ns/operator/servers 这样的接口，它返回当前集群里所有存活节点。拿到地址后，客户端按负载策略选一个节点，发起 gRPC 握手。握手成功后，客户端和服务端之间会建立一个长连接，之后的注册、心跳、配置订阅、配置推送，都走这条连接。

这个流程设计有个很现实的好处：服务端节点列表发生变化时，客户端不需要提前配置所有地址，只要有一个入口能访问到 Nacos，就能通过 HTTP 自动发现整个集群。但反过来也有个容易被忽略的点：如果这个 HTTP 接口不通，哪怕 gRPC 端口全开着，客户端也可能因为拿不到节点列表而连接失败。

另外，这条 gRPC 连接不是建完就结束的。客户端会定期发送心跳，服务端也会主动检测连接是否健康。如果网络断开、负载均衡器把空闲连接回收，或者服务端节点重启，客户端会重新走一遍“找节点、建连接”的流程。所以你在监控里看到连接数摆动是正常的，真正要警惕的是连接数长时间往下掉、且重连日志不断刷。

2.3 服务注册到配置推送：unary 和 server streaming 的分工

建好了长连接，接下来就是数据面请求怎么走。Nacos 2.x 的 gRPC 接口大体上分两类：一类是 unary 模式，就是“请求一次、响应一次”，适合服务注册、实例注销、心跳上报这种一问一答的操作；另一类是 server streaming 模式，服务端在一条连接上持续往客户端发数据，适合配置变更通知、服务端主动推送服务列表变化。

把它类比成打电话和发订阅消息会更好理解。unary 是你拨一次号、说一句话、对方回一句，然后挂断；server streaming 是你跟对方订了一个“报纸”，以后每期出了，对方直接往你家里送，不用你每次去邮局问。

在 1.x 里，服务发现变更靠 UDP 推、配置变更靠长轮询拉，本质上都是“半推半拉”。在 2.x 里，服务端一旦感知到服务实例变化，会立即通过已建立的 gRPC 流把变更通知推给订阅的客户端，客户端收到通知后再回源拉取完整数据或者直接用推送里的增量信息。这个“推拉结合”比 1.x 高效得多，这也是很多人升级后觉得“配置变更变快、服务上下线感知更快”的根本原因。

3. 兼容层的真实边界：HTTP API 还在，但不是所有流量都走它

3.1 服务端为何保留 HTTP API：老客户端要活着

开始迁移前，我最担心的问题就是：2.x 是不是把 HTTP 接口全砍了？如果砍了，那些还没升级到新 SDK 的老服务怎么办？

实际答案比较温和。Nacos 2.x 服务端仍然保留了 HTTP 开放接口，原因很直接：Nacos 1.x 的客户端不在少数，如果强制一刀切，很多存量系统根本没法平滑升级。2.x 的策略是优先推荐 gRPC，但对于老客户端，服务端仍然可以走 HTTP 接口完成注册和配置查询。

所以你会看到一个很有意思的现象：同一个 Nacos 2.x 集群里，新客户端走 9848 的 gRPC，老客户端走 8848 的 HTTP，两边都能正常往里注册服务。服务端在这一层做了协议适配，把从 HTTP 进来的请求和从 gRPC 进来的请求，统一转换成内部的数据模型，再交给后端的服务管理模块。

但这不等于说可以无限期混跑。HTTP 接口虽然在，它的性能表现、推送实时性、连接复用能力都远不如 gRPC。如果你有大规模服务，却长期让客户端停留在 1.x，那相当于把协议演进的红利全部放弃了。

3.2 SDK 版本匹配：最容易翻车的几组组合

第二个坑是 SDK 版本匹配。Nacos 服务端虽然是向后兼容的，但客户端 SDK 版本和服务端版本之间，仍然存在一些需要小心的组合。

最让我头疼的是 Spring Cloud Alibaba 的间接依赖。很多项目自己没直接引入 nacos-client，而是通过 spring-cloud-starter-alibaba-nacos-discovery 带进来的。这时候你升级 Nacos 服务端到 2.x，但 Spring Cloud Alibaba 的 BOM 里锁的 nacos-client 版本如果还是老的 1.4.x，那服务端再怎么支持 gRPC，客户端也不会主动去连 9848。

解决方式很简单：要么整体升级 Spring Cloud Alibaba 到对应 Nacos 2.x 的版本，要么在 pom 里显式覆盖 nacos-client 的版本。我建议前者，因为 Spring Cloud Alibaba 内部可能还有其他组件依赖 nacos-client 的版本范围，你强行覆盖可能有潜在冲突。

判断当前客户端到底走的哪条协议，有个很笨但有效的办法：看服务端 9848 端口有没有连接。执行 netstat -an | grep 9848 | grep ESTABLISHED，如果有大量 ESTABLISHED 连接，说明客户端已经走了 gRPC；如果只有 8848 有连接、9848 一个都没有，那就要怀疑客户端版本是不是太旧了。

3.3 控制台和开放平台接口仍以 HTTP 为主，别混淆

还有一个容易混淆的点：Nacos 控制台的所有管理操作，包括命名空间管理、用户权限管理、配置编辑、服务列表查询，走的仍然是 HTTP。服务端暴露给外部系统调用的开放 API，比如通过 HTTP 直接发布配置、直接注册服务，也仍然是 HTTP。

这本身是合理的。管理面操作频率低、偶发且需要手工排查，HTTP 足够用；数据面操作频率高、并发大，才需要 gRPC。所以你会看到 Nacos 2.x 的文档里同时存在“gRPC 协议”和“HTTP Open API”两套说明，它们不是对立的，而是各管一段。

如果你要在项目里通过脚本批量发布配置，仍然可以直接 POST /nacos/v1/cs/configs，不需要特地去拼 gRPC 请求。反过来，如果你要在 SDK 里监听配置变化，那就应该用 nacos-client 的 addListener 接口，底层会走 gRPC stream，而不是自己拿 HTTP 去长轮询。

4. 生产环境落地 Nacos 2.x 通信改造时，最容易忽视的三个配置面

4.1 防火墙和安全组不是只开 8848 就能跑

这是我把 Nacos 从 1.x 迁到 2.x 时，第一次踩到的坑。测试环境一切正常，一上生产环境，客户端日志开始狂刷“Client not connected, current status: STARTING”，控制台却能正常打开。

问题出在安全组上。开发环境可能所有端口都放通，所以 9848/9849 没暴露问题；生产环境只放行了 8848 的入方向规则，gRPC 端口全部被防火墙挡在外面。客户端拿得到节点列表，也发得出注册请求，但请求在 9848 端口被悄然丢弃，表现就是“半死不活”。

所以在你打算部署 Nacos 2.x 之前，第一件事就是确认三个端口的放行策略：

• 如果客户端通过公网或跨网络访问 Nacos，需要放行 8848 和 9848；
• 如果 Nacos 是多节点集群，节点之间还需要放行 9849；
• jraft 用的 7848 也不要漏掉，否则集群选主可能异常。

更稳妥的做法是在 Nacos 节点上直接验证 gRPC 端口是否真的在监听。ss -lntp | grep 9848 只能确认服务端在监听，不能确认防火墙是否放通。要从客户端所在机器执行 telnet 服务端IP 9848，能通才算网络层正常。

4.2 SLB/LVS/Ingress 对 gRPC 长连接的支持方式

如果你不是让客户端直连 Nacos，而是前面架了一层负载均衡，那问题就来了：gRPC 长连接对负载均衡器的要求，比普通 HTTP 高很多。

最常见的坑是七层负载均衡器默认不认识 gRPC。比如 Nginx 老版本默认走 HTTP/1.1，它对 gRPC 的处理方式是把每个 gRPC 请求当成普通 HTTP 请求转发，但 gRPC 要求 HTTP/2 协议，Nginx 需要显式配置 grpc_pass，并在 server 块里开启 HTTP/2。如果不这么做，客户端握手阶段就报错，日志里会出现类似 “Invalid HTTP header” 的提示。

另一个坑是空闲连接回收。gRPC 长连接可能几分钟都没有一个请求，如果 SLB 配了较短的 idle timeout，一旦空闲超过阈值，负载均衡器会主动把连接断掉。客户端虽然会重连，但重连期间正好赶上服务端推送，就会表现为偶发的配置延迟或服务发现延迟。

所以生产环境用负载均衡器接 Nacos gRPC，我建议优先选择四层 TCP 转发，尽量不要做七层 HTTP 转发。四层转发保的是裸 TCP 流，HTTP/2 帧原样穿过，基本不干预连接生命周期。如果必须用七层，那就把 proxy_read_timeout、proxy_send_timeout 拉大，同时打开 HTTP/2 和 grpc_pass。

4.3 Docker/K8s 端口映射与健康检查

用 Docker 部署 Nacos 时，端口映射也要同步修改。如果你用 docker run 只映射了 8848，容器里的 9848 和 9849 不会被自动映射出来，客户端照样连不上。

以 docker-compose 为例，最小可行的端口映射至少要是这样：

yaml复制ports:
  - "8848:8848"
  - "9848:9848"
  - "9849:9849"

Kubernetes 里同理。Service 如果用 ClusterIP，必须在 ports 里显式声明 9848 和 9849；如果用 Ingress，需要配置后端协议为 GRPC，而不是简单地把 HTTP 流量转过去。很多人在 K8s 里部署 Nacos 后报“服务能注册但控制台看到的实例 IP 不对”，往往就是 Service 类型和端口映射配置不当造成的。

健康检查也要注意。Nacos 2.x 的 readiness 接口主端口是 /nacos/v1/console/health/readiness，它验证的是服务端整体就绪状态，不会直接验证 gRPC 端口。如果你的探针只检查主端口，而 gRPC 端口因为映射不到位处于半开状态，K8s 不会认为 Pod 不健康，但客户端就是连不上。

所以在 K8s 里部署完 Nacos 后，我习惯额外加一个 TCP 探针，直接探测 9848 端口是否可连接。这比只依赖 HTTP readiness 更贴近客户端视角。

5. 迁移后我踩过的坑：从“服务列表能看”到“注册不上”的排查链路

5.1 症状一：控制台能看到服务，但新服务一直注册不成功

迁移完成后的第一天，我就收到业务方反馈：某个新服务在 Nacos 控制台里看不到，但服务进程一直显示启动成功、没有明显报错。

这个症状很迷惑人，因为它不是“完全连不上”，而是“部分功能失效”。拉起日志一看，客户端打印了类似 [Nacos grpc] Client not connected, current status: STARTING 的日志，一直在重试。

排查链路是这样的：

1. 先查客户端用的是旧 HTTP 还是新 gRPC。如果客户端版本是 1.4.x，注册会走 8848，不会碰 9848。但我们的服务用的是 2.2.x，必然走 gRPC。
2. 再查 gRPC 端口连通性。在客户端所在机器 telnet 服务端IP 9848，发现直接卡住，说明端口不通。
3. 查服务端监听情况，9848 明明在监听。那问题就落在安全组上。登录云控制台一看，果然入方向只放行了 8848。
4. 补充 9848/9849 放行规则后，客户端不到十秒就完成注册，控制台也立刻能看到新服务。

这个坑的教训很直接：Nacos 2.x 的连通性是三端口问题，不是单端口问题。排查顺序应该是“先看客户端协议版本，再按协议版本定位对应端口，最后验证网络链路”。

5.2 症状二：连接反复重连，Nacos 日志大量刷“gRPC connection closed”

第二个坑是在升级到 Nacos 2.5.4 后出现的。服务本身能注册，但服务端日志每隔一段时间就会刷一条连接关闭记录，客户端日志也在反复重连。看起来像网络不稳定，但 ping 和服务端 8848 的 HTTP 请求都正常。

后来定位到根因是负载均衡器的空闲连接回收。因为我们给 Nacos 前面加了一个云厂商的负载均衡实例，默认空闲超时时间是 4 分钟。gRPC 长连接在没有业务请求的空闲窗口里，超过 4 分钟就会被负载均衡器强制断开。客户端发现连接断开后立刻重连，于是出现周期性重连。

解决方式有两步：

• 把负载均衡器的空闲超时时间调大，比如调到 30 分钟以上，或者开启 TCP keep-alive；
• 如果负载均衡器不支持调整，就考虑直接改为四层 TCP 直连 Nacos 节点，绕过七层代理。

这里还有个小细节：gRPC 自带 keep-alive，默认会定期 ping 服务端，但这些 ping 是 HTTP/2 层的帧，七层负载均衡器如果不转发 HTTP/2 的 PING 帧，照样会判定连接空闲。所以不要天真地以为“客户端有心跳就不会被断开”，要看心跳能不能穿过你前面那层代理。

5.3 症状三：开了 gRPC 仍然出现 HTTP 404/400

有段时间我们把服务端升到 2.x，但客户端升级只做了一半，导致出现大量 HTTP 404/400。具体现象是：有些接口能通，有些接口报 404，日志里既有 gRPC 调用参数，又有 HTTP 响应的状态码，看起来非常分裂。

查到最后发现，是客户端里同时混了两套逻辑。一部分老代码直接用 HTTP Open API 注册服务，服务端升级后 Open API 的路径规范有调整，旧路径返回 404；另一部分新代码走 gRPC，但其中某个请求被服务端识别为请求体格式不对，返回 400。

这个问题的本质，不是 gRPC 和 HTTP 哪个更好，而是你在同一个服务里混用了两个版本的调用方式。我后来把所有注册和发现逻辑统一收敛到 nacos-client 的 API，不再自己拼 HTTP 请求。除非你是做运维脚本，需要手动调用 Open API，否则业务代码里不要混合使用两套协议，不然排查起来非常痛苦。

5.4 附带一提：UDP 推送时代的遗留问题

如果你是 1.x 老用户，可能还记得 Nacos 1.x 服务发现变更走 UDP 推送，经常出现“服务下线了但调用方还拿得到旧地址”的问题。很多团队在 1.x 时代绕开 UDP，靠调短客户端拉取周期来缓解。

到了 2.x，只要客户端升级了，服务发现变更推送就走 gRPC 流，不再依赖 UDP。但如果你有部分老客户端还留在 1.x，那部分流量仍然走 UDP。这就导致一个集群里，同一时刻不同客户端的上下线感知速度不一样：gRPC 客户端秒级感知，老 UDP 客户端可能要等好几个心跳周期。

所以我强烈建议：如果上了 2.x，就把能升级的客户端都升级掉，不要长期保留 1.x 客户端。混跑是过渡态，不是终态。终态越干净，后续排查问题越省心。

6. 我的落地建议：怎么分阶段切，切了以后盯哪些指标

6.1 不要“一把梭”全部切 gRPC

如果现在让你把整个公司几千个服务实例一夜之间全部切成 gRPC，我是不推荐的。Nacos 2.x 的兼容性虽然做得不错，但大规模变更仍然存在风险，比如老 SDK 的某些隐藏行为、网络策略遗漏、负载均衡器不兼容等。

我更推荐分阶段切换：

1. 先升级服务端到 2.x，客户端暂时不动，让老客户端继续走 HTTP，观察服务端日志和监控指标是否正常；
2. 选择几个非核心服务，把客户端 SDK 升级到 2.2+，验证注册、发现、配置推送是否符合预期；
3. 逐步扩大范围，同时观察 9848 端口的连接数和服务端推送耗时；
4. 等核心服务验证通过后，再整体切完。

这个过程的每一步都保留回退空间。Nacos 1.x 客户端连接 2.x 服务端是兼容的，所以即使某个服务升级后出现问题，可以马上把 nacos-client 版本退回 1.4.x，服务端不用动，影响面可控。

6.2 需要盯的监控项和日志

切换完成后，监控要跟着走。服务端在 /nacos/v1/ns/operator/metrics 会暴露一组监控指标，我会重点看几类：

• gRPC 连接数：连接数突然大幅下降，说明有客户端断连或者网络策略变更；
• 请求耗时：如果 gRPC 请求的 P99 明显上升，可能不是 Nacos 本身的问题，而是客户端所在主机和 Nacos 之间的网络链路质量下降；
• 配置推送耗时：这个指标直接影响业务感知，比如配置更新后多久到达客户端。

客户端日志方面，把 Nacos 的日志级别调到能看见连接状态变化的程度。日志里出现 gRPC connect success 就说明建连成功；频繁出现 Client not connected 或者 gRPC connection closed，就要结合网络链路排查。

6.3 回滚预案和版本策略

最后说版本策略。我用一个原则：客户端版本尽量跟着服务端版本走，不要跨大版本。

如果你服务端是 2.5.x，那客户端最好也用 2.5.x 或者至少 2.2.x。老到一定程度，虽然兼容层还在，但新特性可能用不上，排查问题时的日志格式也可能对不上。

如果你用的是 Spring Cloud Alibaba，建议在依赖管理里显式声明 nacos-client 的版本，而不是完全依赖 starter 的默认版本。这样当 Nacos 服务端升级时，你只需要改一个 BOM 里对应的版本，其他地方不会被动牵连。

回滚预案也要提前准备好。我每次升级都会先在测试环境跑一遍“服务端升级 + 旧客户端连接”的场景，确认兼容性没问题再上生产。这样一旦生产环境有问题，第一步就是检查是不是连接了旧客户端，而不是慌慌张张回滚整个集群。

从我个人的实际经验来说，Nacos 内部通信协议从 HTTP 演进到 gRPC，不是一次简单的版本升级，而是一次架构思维的转变。它把“客户端频繁请求、服务端被动响应”变成了“建立长连接、双向主动通信”，这带来的收益在规模越大时越明显。但收益的背后是需要你理解端口规则、连接生命周期和兼容边界，否则这些隐藏在文档深处的细节，很容易变成生产事故的导火索。希望这篇整理能帮你少走几个我走过的弯路。