在1.4.x版本,Distro协议可以把心跳和注册的流量压力分散到集群的各个节点。但是在2.x版本,由于建立的通信通道是长连接,Distro协议不再分散流量到集群内,而是直接对请求进行处理。故障场景:如果要对集群节点进行灰度升级的话,客户端会从下线的节点切换到别的节点,切换后建立的又是长链接,由于服务端节点是灰度进行的(逐台进行),会不会最后导致压力全部连接到集群中的一台或者两台,造成数据倾斜的问题?异常表现:个别节点内存和CPU占用极高,其他节点负载很低。问题:客户端或者服务端有措施可以规避或者预防这种情况发生吗? nacos-opensource | Nacos
Nacos 配置中心安全问题汇总及解决方案 Know more

在1.4.x版本,Distro协议可以把心跳和注册的流量压力分散到集群的各个节点。但是在2.x版本,由于建立的通信通道是长连接,Distro协议不再分散流量到集群内,而是直接对请求进行处理。故障场景:如果要对集群节点进行灰度升级的话,客户端会从下线的节点切换到别的节点,切换后建立的又是长链接,由于服务端节点是灰度进行的(逐台进行),会不会最后导致压力全部连接到集群中的一台或者两台,造成数据倾斜的问题?异常表现:个别节点内存和CPU占用极高,其他节点负载很低。问题:客户端或者服务端有措施可以规避或者预防这种情况发生吗? nacos-opensource


在Nacos 2.x版本中,由于长连接的引入,Distro协议不再像1.4.x版本那样能有效分散心跳和注册的流量压力到集群各节点,这确实可能导致在灰度升级过程中,随着部分节点下线,新建立的长连接集中到剩余节点上,从而引发数据倾斜、内存与CPU占用极高的问题。针对此故障场景,可以采取以下措施进行规避或预防:

  1. 使用VIP/SLB进行负载均衡

    • 部署虚拟IP(VIP)或软件负载均衡器(如Nginx、HAProxy)在Nacos集群前端,确保客户端请求能够均匀地分发到各个节点。配置最小连接数算法以快速实现负载均衡,减少因节点下线导致的流量集中问题。
  2. 主动触发负载均衡

    • 在进行灰度升级前或过程中,对连接数量较多的节点,可以主动调用API curl -X GET '127.0.0.1:8848/nacos/v2/core/loader/reloadCurrent?count=xxx' 来迁移指定数量的连接到其他节点,减轻高负载节点的压力。这里的count参数表示需要迁移的连接数,需根据实际情况调整。
  3. 合理规划灰度升级策略

    • 实施滚动升级策略时,应控制好每次升级的节点数量,避免同时下线过多节点导致剩余节点瞬时压力过大。可以采用分批次、小步快跑的方式逐步完成升级,每升级一批节点后观察集群状态和负载情况,确保平稳过渡。
  4. 监控与预警

    • 强化集群的监控体系,对每个节点的CPU、内存使用率以及连接数等关键指标实施实时监控,并设定阈值预警。一旦发现某个节点负载过高,立即采取措施干预,比如临时增加节点或手动迁移部分连接。
  5. 资源优化与扩容

    • 根据业务规模和预期增长,提前评估并准备足够的硬件资源。在预计会有大规模服务上线或升级操作前,可以预先扩容节点,增加集群整体的处理能力,以吸收可能的流量峰值。

综上所述,通过上述策略的综合应用,可以在很大程度上缓解或避免Nacos 2.x版本在灰度升级过程中因长连接导致的数据倾斜和负载不均问题。

答疑服务说明:

本内容经由技术专家审阅的用户问答的镜像生成,我们提供了专家智能答疑服务,在页面的右下的浮窗”专家答疑“。您也可以访问 : 全局专家答疑 。 咨询其他产品的的问题

反馈

如问答有错漏,欢迎点:差评给我们反馈。