【微服务】Nacos为什么丢弃短连接(http)而选择拥抱长连接(gRPC)
| 阿里云国内75折 回扣 微信号：monov8 |
| 阿里云国际，腾讯云国际，低至75折。AWS 93折 免费开户实名账号 代冲值 优惠多多 微信号：monov8 飞机：@monov6 |
目录
一、现状背景
Nacos 1.x 版本 Config/Naming 模块各自的推送通道都是按照自己的设计模型来实现的。
产品 推送模型 数据一致性 痛点 说明 Nacos Config 异步 Servlet 基于 MD5 比
对⼀致性http 短连接30 秒定
期创建销毁连接GC
压力大md5 值计算也有⼀定
开销在可接受范围内Nacos Naming HTTP/UDP UDP 推送
+ 补偿查询丢包云架构下无法
反向推送配置和服务器模块的数据推送通道不统⼀http 短连接性能压力巨大未来 Nacos 需要构建能够同时支持配置以及服务的长链接通道以标准的通信模型重构推送通道。
二、场景分析
1、配置
配置对连接的场景诉求分析
SDK 和 Server 之间
- 客户端 SDK 需要感知服务节点列表并按照某种策略选择其中⼀个节点进行连接底层连接断开时需要进行切换 Server 进行重连。
- 客户端基于当前可用的长链接进行配置的查询发布删除监听取消监听等配置领域的 RPC 语意接口通信。
- 感知配置变更消息需要将配置变更消息通知推送当前监听的客户端网络不稳定时客户端接收失败需要支持重推并告警。
- 感知客户端连接断开事件将连接注销并且清空连接对应的上下文比如监听信息上下文清理。
Server 之间通信
- 单个 Server 需要获取到集群的所有 Server 间的列表并且为每⼀个 Server 创建独立的长链接连接断开时需要进行重连服务端列表发生变更时需要创建新节点的长链接销毁下线的节点长链接。
- Server 间需要进行数据同步包括配置变更信息同步当前连接数信息系统负载信息同步负载调节信息同步等。
2、服务
SDK 和 Server 之间
- 客户端 SDK 需要感知服务节点列表并按照某种策略选择其中⼀个节点进行连接底层连接断开时需要切换 Server 进行重连。
- 客户端基于当前可用的长链接进行配置的查询注册注销订阅取消订阅等服务发现领域的 RPC 语意接口通信。
- 感知服务变更有服务数据发生变更服务端需要推送新数据到客户端需要有推送 ack方便服务端进行 metrics 和重推判定等。
- 感知客户端连接断开事件将连接注销并且清空连接对应的上下文比如该客户端连接注册的服务和订阅的服务。
Server 之间通信
- 服务端之间需要通过长连接感知对端存活状态需要通过长连接汇报服务状态同步 RPC 能力。
- 服务端之间进行 AP Distro 数据同步需要异步 RPC 带 ack 能力。
三、长连接核心诉求
1、功能性诉求
1.1、客户端
- 连接生命周期实时感知能力包括连接建立连接断开事件。
- 客户端调用服务端支持同步阻塞异步 Future异步 CallBack 三种模式。
- 底层连接自动切换能力。
- 响应服务端连接重置消息进行连接切换。
- 选址/服务发现。
1.2、服务端
- 连接生命周期实时感知能力包括连接建立连接断开事件。
- 服务端往客户端主动进行数据推送需要客户端进行 Ack 返回以支持可靠推送并且需要进行失败重试。
- 服务端主动推送负载调节能力。
2、性能
性能方面需要能够满足阿里的生产环境可用性要求能够支持百万级的长链接规模及请求量和推送量并且要保证足够稳定。
3、负载均衡
- 常见的负载均衡策略随机hash轮询权重最小连接数最快响应速度等
- 短连接和长链接负载均衡的异同在短连接中因为连接快速建立销毁“随机hash轮询权重”四种方式大致能够保持整体是均衡的服务端重启也不会影响整体均衡其中“最小连接数最快响应速度”是有状态的算法因为数据延时容易造成堆积效应长连接因为建立连接后如果没有异常情况出现连接会⼀直保持断连后需要重新选择⼀个新的服务节点当出现服务节点发布重启后最终连接会出现不均衡的情况出现“随机轮询权重”的策略在客户端重连切换时可以使用“最小连接数最快响应速度”和短连接⼀样也会出现数据延时造成堆积效应。长连接和短连接的⼀个主要差别在于在整体连接稳定时服务端需要⼀个 rebalance 的机制将集群视角的连接数重新洗牌分配趋向另外⼀种稳态
- 客户端随机+服务端柔性调整
核心的策略是客户端+服务端双向调节策略客户端随机选择+服务端运行时柔性调整。
客户端随机
- 客户端在启动时获取服务列表按照随机规则进行节点选择逻辑比较简单整体能够保持随机。
服务端柔性调整
- (当前实现版本)人工管控方案集群视角的系统负载控制台提供连接数负载等视图(扩展新增连接数负载CPU 等信息集群间 report 同步)实现人工调节每个 Server 节点的连接数人工触发 reblance人工削峰填谷。
○ 提供集群视角的负载控制台展示 总节点数量总长链接数量平均数量系统负载信息。
○ 每个节点的地址长链接数量与平均数量的差值正负值。○ 对高于平均值的节点进行数量调控设置数量上限(临时和持久化)并可指定服务节点 进行切换。
- (未来终态版本)自动化管控方案基于每个 server 间连接数及负载自动计算节点合理连接数自动触发 reblance自动削峰填谷。实现周期较长比较依赖算法准确性。
4、连接生命周期
4.1、心跳保活机制
4.2、需要什么
- 低成本快速感知客户端需要在服务端不可用时尽快地切换到新的服务节点降低不可用时间并且能够感知底层连接切换事件重置上下文服务端需要在客户端断开连接时剔除客户端连接对应的上下文包括配置监听服务订阅上下文并且处理客户端连接对应的实例上下线。
- 客户端正常重启客户端主动关闭连接服务端实时感知
- 服务端正常重启 : 服务端主动关闭连接客户端实时感知
- 防抖
- 网络短暂不可用: 客户端需要能接受短暂网络抖动需要⼀定重试机制防止集群抖动超过阈值后需要自动切换 server但要防止请求风暴。
- 断网演练断网场景下以合理的频率进行重试断网结束时可以快速重连恢复。
四、长连接选型对比
在当前的备选框架中从功能的契合度上Rsocket 比较贴切我们的功能性诉求性能上比 grpc要强⼀些开源社区的活跃度上相对 grpc 要逊色很多。
所以在Nacos2.x的长连接通信模型中选取了谷歌开源的gRPC框架而弃用http短链接。
五、基于长链接的⼀致性模型
1.、配置⼀致性模型
1.1、server 间⼀致性
Server 间同步消息接收处理轻量级实现重试失败时监控告警。
断网断网太久重试任务队列爆满时无剔除策略。
2、服务⼀致性模型
2.1、sdk-server 间⼀致性
2.2、server 间⼀致性
💖微服务实战
✨【微服务】SpringCloud的OpenFeign与Ribbon配置
✨Spring Cloud Alibaba微服务第29章之Rancher
✨Spring Cloud Alibaba微服务第27章之Jenkins
✨Spring Cloud Alibaba微服务第24章之Docker部署
✨Spring Cloud Alibaba微服务第23章之Oauth2授权码模式
✨Spring Cloud Alibaba微服务第22章之Oauth2
✨Spring Cloud Alibaba微服务第21章之分布式事务
✨Spring Cloud Alibaba微服务第18章之消息服务
✨Spring Cloud Alibaba微服务第16章之服务容错
✨Spring Cloud Alibaba微服务第14章之分库分表
✨Spring Cloud Alibaba微服务第11章之MyBatis-plus
✨Spring Cloud Alibaba微服务第8章之OpenFeign
✨Spring Cloud Alibaba微服务第7章之负载均衡Ribbon
💖 Spring家族及微服务系列文章
✨【微服务】SpringCloud中OpenFeign请求处理及负载均衡流程
✨【微服务】SpringCloud中Ribbon的WeightedResponseTimeRule策略
✨【微服务】SpringCloud中Ribbon的轮询(RoundRobinRule)与重试(RetryRule)策略
✨【微服务】SpringCloud中Ribbon集成Eureka实现负载均衡
✨【微服务】SpringCloud轮询拉取注册表及服务发现源码解析
✨【微服务】SpringBoot监听器机制以及在Nacos中的应用
✨【微服务】SpringCloud中使用Ribbon实现负载均衡的原理
✨【微服务】SpringBoot启动流程注册FeignClient