文章目录
Nacos通信通道 (长链接)
现状背景
Nacos 1.X 版本 Config/Naming 模块各自的推送通道 都是按照自己的设计模型来实现的。
产品 | 推送模型 | 数据一致性 | 痛点 | 说明 |
---|---|---|---|---|
Nacos Config | 异步 Servlet | 基于MD5比对一致性 | http短连接,30秒定期创建销毁连接,GC压力大 | md5值计算也有一定开销,在可接受范围内 |
Nacos Naming | HTTP/UDP | UDP 推送 + 补偿查询 | 丢包,云架构下无法反向推送 |
配置和服务器模块的数据推送通道不统一 ,http 短连接性能压力巨大,未来 Nacos 需要构建能够同时支持配置以及服务的长链接通道,以标准的通信模型重构推送通道。
场景分析
配置
配置对连接的场景诉求分析
- SDK和Server之间
- 客户端SDK需要感知服务节点列表,并按照某种策略 选择其中一个节点进行连接;底层连接断开时,需要进行切换Server进行重连。
- 客户端基于当前可用的长链接进行配置的查询,发布,删除监听,取消监听等配置领域的RPC语意接口通信。
- 感知配置变更消息,需要将配置变更消息通知推送当前监听的客户端;网络不稳定时,客户端接收失败,需要支持重推,并告警。
- 感知客户端连接断开事件 ,将连接注销,并且清空连接对应的上下文,比如监听信息上下文清理。
服务
- SDK 和 Server 之间
- 客户端 SDK 需要感知服务节点列表,并按照某种策略选择其中一个节点进行连接;底层连接断开时,需要切换 Server 进行重连。
- 客户端基于当前可用的长链接进行配置的查询,注册,注销,订阅,取消订阅等服务发现领域的RPC 语意接口通信。
- 感知服务变更 ,有服务数据发生变更 ,服务端需要推送新数据到客户端;需要有推送 ack (SDK返回给服务端),方便服务端进行 metrics 和重推判定等。
- 感知客户端连接断开事件,将连接注销,并且清空连接对应的上下文,比如该客户端连接注册的服务和订阅的服务。
- Server 之间通信
- 服务端之间需要通过长连接感知对端存活状态,需要通过长连接汇报服务状态(同步 RPC 能力)
- 服务端之间进行 AP Distro 数据同步,需要异步 RPC 带 ack 能力。
长链接核心诉求
功能性诉求
客户端:
- 连接生命周期实时感知能力,包括连接建立,连接断开事件
- 客户端调用服务端支持同步阻塞,异步future,异步 callback 三种模式
- 底层连接自动切换能力
- 响应服务端连接重置消息进行连接切换
- 选址/服务发现
服务端: - 连接生命周期实时感知能力,包括连接建立,连接断开事件
- 服务端往客户端主动进行数据推送,需要客户端进行 Ack 返回以支持可靠推送,并且需要进行失败重试
- 服务端主动推送负载调节能力
负载均衡
- 常见的负载均衡策略:随机,hash,轮询,权重,最小连接数,最快响应速度等
- 短连接和长链接负载均衡的异同;
- 在短连接中 ,因为连接快速建立销毁,"随机,hash,轮询,权重"四种方式 大致能够保持整体是均衡的,服务端重启也不会影响整体均衡,其中"最小连接数,最快响应速度"是有状态的算法,因为数据延时容易造成堆积效应.
- 长连接 因为建立连接后,如果没有异常情况出现,连接会一直保持 ,断连 后需要重新选择 一个新的服务节点,当出现服务节点发布重启后,最终连接会出现不均衡的情况出现 ,"随机,轮询,权重"的策略在客户端重连切换时可以使用,"最小连接数,最快响应速度"和短连接一样也会出现数据延时造成堆积效应。长连接和短连接的一个主要差别 在于在整体连接稳定时 ,服务端需要一个rebalance的机制 ,将集群视角的连接数重新洗牌分配,趋向另外一种稳态
- 客户端随机+服务端柔性调整:
-
核心的策略是客户端+服务端双向调节策略,客户端随机选择+服务端运行时柔性调整。
-
客户端随机:
- 客户端在启动时获取服务列表,按照随机规则进行节点选择,逻辑比较简单,整体能保持随机。
-
服务器柔性调整:
-
(当前实现版本)人工管控方案:集群视角的系统负载控制台,提供连接数,负载等视图(扩展新增连接数,负载,CPU 等信息,集群间 report 同步),实现人工调节每个 Server 节点的连接数,人工触发reblance,人工削峰填谷
- 提供集群视角的负载控制台:展示 总节点数量,总长链接数量,平均数量,系统负载信息
- 每个节点的地址,长链接数量,与平均数量的差值,正负值
- 对高于平均值的节点进行数量调控,设置数量上限(临时和持久化),并可指定服务节点进行切换
-
(未来终态版本)自动化管控方案:基于每个 server 间连接数及负载自动计算节点合理连接数,自动触发reblance,自动削峰填谷。实现周期较长,比较依赖算法准确性。
-
-
连接生命周期
心跳保活机制:
类型 | TCP | netty | mina | grpc | rsocket | tb remote | |
---|---|---|---|---|---|---|---|
心跳保活机制 | keepalive机制:通道无读写事件时,发送心跳包检测,可设置超时时间,间隔次数 | 1.设置TCP参数 2.自定义心跳IdeHandler,监听通道读写事件 | 1.自定义心跳,KeepAliveFilter | 1.自定义心跳,ping-pong包探测 | 1.自定义keep alive机制 | 基于mina,KeepAliveFilter | |
事件通知 | 正常关闭 | 有事件通知 | 有事件通知 | 有事件通知 | 有事件通知 | 有事件通知 | 有事件通知 |
断网异常 | keep alive机制,有事件通知 | tpc及自定义心跳,有事件通知 | 自定义心跳,有事件通知 | 自定义心跳,ping-pong包探测,无事件通知 | 1.自定义心跳,有事件通知 | 自定义心跳,有事件通知 | z自定义心跳,有事件通知。 |