说一说websocket通道的水平扩展性

2023-02-07  本文已影响0人  天草二十六_简村人

一、背景

随着建立通道的房间和人数增加到一定规模,给我们的架构之扩展性提出了考验,本文主要是讲述通道服务的水平扩展性,垂直扩展不在本文的范围内。

前文也有讲述,我们的现状是缺乏通道的接入层,连接是随机路由到后端节点。换句话说,同一个房间的用户,会分散到多个后端节点。这样的话,A用户想要发送消息给同房间的B用户,目前是使用Mq广播消息,让所有的后端节点都消费该消费。

缺点是:很多消息广播出去,导致消息的重复处理,每个节点都要消费同等数量的消息。最重要的是,这不利于服务的水平扩展。

二、目标

三、方案一--kong plugin改写upstream

自定义kong插件,调用方额外传入header字段,计算hash值,选择对应的upsteam。

image.png

既然是upstream,就意味着后端的pod节点可以是多个,对比方案二的高可用相对更好。

主要内容是开发自定义的kong插件,读取websocket header头部字段,求模计算,选择对应的upstream。

好处是:可以记录下各个upstream已连接上的课堂列表,当有新的课堂来临,可以选择路由到连接空闲的upstream。

四、方案二--kong upsteam 的 hash on header

要求调用方的头部,新增上传计算路由的字段。比如学校ID,用户ID,课堂ID等等。

image.png

不用额外的开发工作,相对比方案一,它的路由机制没有那么灵活,只保证同一个课堂下的连接请求到同一个节点。而无法对节点的负载进行适当的均摊,比如节点1已连接了2个课堂,节点2还未有1个课堂,来临的第3个课堂还有可能连接到第1个节点。

五、方案三--命名服务之zookeeper

单元化的需要,我们根据不同的学校ID可配置不同的通道地址。本次需求可以进一步细化到课堂ID,在每次进入课堂前,调用命名服务,取得配置好的通道地址。

image.png

客户端增加一次获取通道地址的请求,可以在创建课堂的时候,就确定其应该连接的通道地址。

但是业务服务要获取通道地址,改动的代码就比较多了。最主要的是业务服务不可能每次都获取,要求把<课堂ID,通道地址>存储到Jvm内存。

pod在创建的时候,注册到zk,随着节点销毁而从zk下线。这使得通道集群保持最新。

六、方案四--命名服务之gossip

上面额外引入了zookeeper这一中间件,你可以使用分布式协议gossip,使得通道集群的信息在各个节点之间共享。

image.png

主要步骤如下:

改动点:

image.png

上面获取通道地址是通过http协议,你也可以使用ws协议。流程如下:


image.png

这里,把kong网关变成了"SLB总入口",它会可能二次建立连接,好处是通道服务不用额外提供http接口了。

七、问题场景

1、场景一--ws连接数不够

2、场景二--N个课堂的使用隔离性

3、场景三--保证通道列表的变更实时刷新

4、场景四--保证路由关系的变更实时刷新

八、总结

数据存储

消息发送的两种方式

image.png
上一篇 下一篇

猜你喜欢

热点阅读