Nacos 长链接

⼀、现状背景

Nacos 1.x 版本 Config/Naming 模块各自的推送通道都是按照自己的设计模型来实现的。

在这里插入图片描述

配置和服务器模块的数据推送通道不统⼀，http 短连接性能压力巨大，未来Nacos 需要构建能够同时支持配置以及服务的长链接通道，以标准的通信模型重构推送通道。

在这里插入图片描述

配置对连接的场景诉求分析

在这里插入图片描述

单个 Server 需要获取到集群的所有 Server 间的列表，并且为每⼀个 Server 创建独立的长链接；连接断开时，需要进行重连，服务端列表发生变更时，需要创建新节点的长链接，销毁下线的节点长链接。
Server 间需要进行数据同步，包括配置变更信息同步,当前连接数信息，系统负载信息同步，负载调节信息同步等。

在这里插入图片描述

 连接生命周期实时感知能力，包括连接建立，连接断开事件。
 客户端调用服务端支持同步阻塞，异步 Future，异步 CallBack 三种模式。
 底层连接自动切换能力。
 响应服务端连接重置消息进行连接切换。
 选址/服务发现。

 连接生命周期实时感知能力，包括连接建立，连接断开事件。
 服务端往客户端主动进行数据推送，需要客户端进行 Ack 返回以支持可靠推送,并且需要进行失败重试。
 服务端主动推送负载调节能力。

能够支持百万级的长链接规模及请求量和推送量，并且要保证足够稳定。

常见的负载均衡策略：随机，hash，轮询，权重，最小连接数，最快响应速度等

短连接和长链接负载均衡的异同：在短连接中，因为连接快速建立销毁，“随机，hash，轮询，权重”四种方式大致能够保持整体是均衡的，服务端重启也不会影响整体均衡，其中“最小连接数，最快响应速度”是有状态的算法，因为数据延时容易造成堆积效应；长连接因为建立连接后，如果没有异常情况出现，连接会⼀直保持，断连后需要重新选择⼀个新的服务节点，当出现服务节点发布重启后，最终连接会出现不均衡的情况出现，“随机，轮询，权重”的策略在客户端重连切换时可以使用，“最小连接数，最快响应速度”和短连接⼀样也会出现数据延时造成堆积效应。长连接和短连接的⼀个主要差别在于在整体连接稳定时，服务端需要⼀个 rebalance 的机制，将集群视角的连接数重新洗牌分配，趋向另外⼀种稳态
客户端随机+服务端柔性调整: 核心的策略是客户端+服务端双向调节策略，客户端随机选择+服务端运行时柔性调整。

在这里插入图片描述

客户端在启动时获取服务列表，按照随机规则进行节点选择，逻辑比较简单，整体能够保持随机。

(当前实现版本) 人工管控方案

集群视角的系统负载控制台，提供连接数，负载等视图(扩展新增连接数，负载，CPU 等信息，集群间 report 同步)，实现人工调节每个 Server 节点的连接数，人工触发 reblance，人工削峰填谷。
提供集群视角的负载控制台：展示总节点数量，总长链接数量，平均数量，系统负载信息。
每个节点的地址，长链接数量，与平均数量的差值，正负值。
对高于平均值的节点进行数量调控，设置数量上限(临时和持久化)，并可指定服务节点进行切换。

 (未来终态版本)自动化管控方案