比心聊天室的架构演进

一、比心语音房技术基本介绍

作为一家泛娱乐公司，语音业务是比心最重要的业务之一，而其中最核心的场景就是基于语音房技术实现的聊天室产品。相比于一般的业务系统，语音房业务系统的技术难度会更高一些，其难点主要体现在以下三个方面：

1. 技术栈复杂，除基于http接口实现的webserver技术外，语音房核心技术还包括基于长连接的IM技术，和基于音视频通信的RTC技术。

2. 强实时要求，需要支持房间内用户多对多互动的场景，一般房间内所有用户对事件变更和信息刷新的感知，需要在一秒内完成。

3. 单房间高并发，聊天室承载了大量的活动，单房间人数从几个人到几万人不等，且在活动期间突然涌入的用户量极大，技术上需要在流量波动的情况下保证业务系统的正常运转。

18年我刚加入公司时，比心语音房业务架构如下：

APP客户端除了实现语音房业务逻辑外，还集成了云信SDK以实现聊天室消息发送功能，集成了ZEGO SDK和TRTC SDK，实现聊天室多人实时连麦功能。聊天室收发消息都是通过云信SDK直接与云信服务器通信完成消息广播，连麦推拉流功能则是通过云商SDK和云商服务之间的音视频流传输来完成。

服务端整体部署在阿里云上，负载均衡采用阿里云SLB服务，业务网关和服务部署在ECS层，底层数据存储使用阿里云rds和redis服务。服务端发送的房间消息会通过调用云信http接口实现，客户端房的消息、推流地址会通过云商回调的方式来回传给业务服务备份记录。

虽然初版的语音房系统足以支持业务早期的需要，但当业务流量上涨，尤其是对单房间进行站外推广，或举行大型比赛时，这套架构很快就会遇到容量瓶颈，用户很容易就能感知到包括服务卡顿、功能异常、声音断断续续、消息公屏不刷消息、手机过热等等一系列问题。

为了解决系统容量，尤其是单房间用户量的限制，我们启动了万人聊天室项目，对系统架构进行了大规模的改造升级。

二、万人在线聊天室的系统建设

比心平台会定期举办“我是歌王”歌手大赛，在万人聊天室建设之前，每次活动都会出各种各样的问题，以下截图是19年S1赛季决赛当时的情况，可以看到决赛房间在线只有几百人的情况下就被挤爆了，无论是观众还是工作人员都无法正常使用。

提高系统容量，要从问题分析入手，问题的分类大致可以分为两类，内部问题和外部问题。内部问题主要是由内部系统本身存在的瓶颈引起，如线程池阻塞、慢SQL、缓存设计问题、异常处理等等；外部问题是指依赖于云商服务引起的问题，主要是消息丢弃和RTC稳定性。

而万人聊天室系统建设，其本质是对语音房系统的全链路资源做高并发场景下的高可用改造，核心思路是：

1. 对架构中的每个资源做水平扩展评估

2. 对于预期应该可水平扩展的资源，需要改造后具备快速水平扩展能力

3. 对于预期无法水平扩展的资源，需要做好三点：第一，根据业务目标提前规划好资源容量；第二，改进资源的使用方式，提升依赖资源的服务性能；第三，控制好资源使用流量上限

按照这个思路，我们对语音房系统各环节进行评估和主要治理方案如下：

下面我们着重介绍几个核心改造事项。

缓存集群化改造

我们使用的redis服务是阿里云redis单机服务，性能存在瓶颈，实际使用经验是CPU 100%时，请求的QPS大约是10W，同时带宽只有最大几十兆，对稍大一些的缓存数据是无法支撑太高的访问量的。