第 38 期 - B 站互动中心平台演进中的架构优化与挑战应对
摘要
文章介绍了 B 站直播互动业务现状、面临的问题,阐述了互动中心架构的演进过程,包括 1.0 和 2.0 时期的功能优化,还提到了视频 PK 业务接入互动中心的架构调整、平台化挑战及应对措施等内容。
一、B 站直播互动业务现状
(一)实时音视频交互的重要性
在 B 站直播业务中,实时音视频交互是主播与主播、主播与用户间的主要交流模式,为此 B 站提供多种实时互动产品,如语音聊天室、连麦连线、视频 PK 等。
(二)互动业务典型架构
- RTC 技术
- 在直播场景中,
RTC
技术负责实时音视频流的接入和处理,满足超低延时音视频互动能力,例如观众可通过它与主播即时交流。 - 代码示例(推测为相关业务代码逻辑描述,可能涉及多种语言如
php
、go
等,但未给出具体代码,仅作示意):
# 假设这是处理 RTC 接入的相关逻辑 def rtc_connect(): # 连接 RTC 服务的相关操作 pass
- 在直播场景中,
- 推拉流技术
- 推流是主播上传音视频数据,拉流是观众获取数据。推流满足主播侧需求,拉流满足观众侧弱互动性、高并发、低成本的观看能力。
- 代码示例(同样为示意性的业务逻辑描述):
def push_stream(): # 推流操作 pass def pull_stream(): # 拉流操作 pass
二、互动业务面临的问题
- 重复建设
- 不同业务分别迭代,未抽象共性功能,导致数据孤岛与重复开发。
- 技术陈旧
- 随着时间推移,技术环境和标准变化,项目使用的技术可能过时或不再被广泛支持。
- 缺乏文档和知识转移
- 长期迭代中,文档记录和知识转移不充分,导致代码和架构理解困难。
- 低效的开发流程
- 存在缺乏自动化测试、部署流程繁琐、代码质量不佳等问题。
- 高并发和可扩展性问题
- 未进行大规模负载测试和优化,随着用户增长可能出现性能瓶颈、系统崩溃或响应延迟。
- 技术债务和代码质量
- 长期迭代产生大量技术债务和低质量代码,影响可维护性和可扩展性。
三、互动中心架构演进
(一)1.0 时期
- 共性功能
- 麦位管理
- 在多人互动场景中,每个用户有在房间中的显示位置,不同场景下麦位有不同含义且对数据实时性要求高。
- 解决数据同步的矛盾采用多种渠道组合,如基于长链接消息的全量状态同步、主动 push(房间广播)、基于 push 的推拉结合方案、增加网关层内存缓存、基于视频流里
SEI
等,并且客户端要对不同渠道来源的数据排序。
- 计分系统
- 互动业务有丰富计分规则,最初依赖单一消息队列实现计分存在高延迟和可靠性问题。
- 新系统中,营收事件有同步和异步两条调用链路,计分事件流水落表存储,有实时链路保障分数计算结果快速落缓存并有计算脚本对账。
- 角色管理
- 不同场景中互动参与者有不同身份,如发起者、参与者、管理员和观众,不同身份有不同权限。
- 采用基于
RBAC
模型的权限管理方案,用户所属角色可根据互动场次数据获取并有落库存储和读写能力,用户可能关联多个角色。
- 麦位管理
- 局限性与问题
- 例如双人连线场景邀请新用户加入自动切换到多人连线现有技术无法支持,因为互动联结层面缺乏通用性,业务功能重复开发、缺乏扩展性,难以适应业务需求快速变化。
(二)2.0 时期
- 通用联结管理
- 术语定义
- 频道:与
RTC
通讯通道对应,串联客户端、RTC
服务、业务服务端通信上下文,互动中心管理频道成员流水数据。 - 场次:逻辑上的一场互动概念,与频道有对应关系但不强耦合。
- 联结:场次中的具体用户,用于管理用户加入互动后的状态数据和状态流转,状态流转由状态机管理。
- 频道:与
- 组件化封装
- 从服务端能力中提取出场次管理、联结管理、频道管理等概念,还有统一数据模型屏蔽不同业务差异性。
- 术语定义
- 动态模板渲染
- 不同玩法基于通用
rtc
互动能力但UI
布局不同,开发可配置、自适应的UI
布局系统,通过json
配置文件根据业务场景动态计算并下发配置给客户端,还应用智能算法根据用户偏好和行为自动优化UI
布局。
- 不同玩法基于通用
- 流状态控制
- 目前基于客户端合流方案存在性能和带宽消耗问题以及业务场景适配问题,主播端使用
WebRTC
等技术推流,推流参数可动态调整。
- 目前基于客户端合流方案存在性能和带宽消耗问题以及业务场景适配问题,主播端使用
四、视频 PK 业务接入互动中心
- PK 业务现状
- 链路复杂,4 种
PK
玩法能力在不同服务和架构中多次实现,还涉及逻辑重构,互动建联逻辑变更,数据孤岛问题严重,而PK
业务技术稳定性影响业务稳定性。
- 链路复杂,4 种
- 架构分层
- 运营玩法层:建立在
PK
玩法之上的运营活动,包括大乱斗、吃鸡赛等,目前存在与PK
业务绑定导致重复开发和不支持多人场景等问题。 - PK 层:管理
PK
核心玩法,包括各个阶段流转和匹配逻辑,将与新的玩法层、互动层对接使自身更精简。 - 互动层:建立
RTC
层面联结,处理直播PK
实时通信问题,底层RTC
联结部分统一以多人连线能力为基础有多种实现方式。
- 运营玩法层:建立在
- 统一数据和状态机
- 统一数据:频道数据、场次和连线记录等分散在多个库难以保障一致性,有业务异常和客诉风险。
- 统一状态机:多种业务共用状态机,抽象业务逻辑为可重用组件,节省开发和维护成本,确保系统稳定性和可靠性。
五、互动中心平台化挑战
- 性能问题
- 建立质量监控指标,如加入/离开连线相关指标(成功率、超时数量等)、
RTC
推流成功率、邀请/申请触达率等,从多个维度评估系统容量,包括实时互动场次、人数等。
- 建立质量监控指标,如加入/离开连线相关指标(成功率、超时数量等)、
- 复杂系统治理
- 链路追踪:如
PK
送礼加分链路涉及多业务多时序多维度流程,通过打通多业务模块之间的trace
提升解决问题效率。 - 数据上报和串联:通过建立场景 - 模块 - 关键节点概念进行数据上报和串联,模块和关键节点有成功与否属性。
- 数据检索:建设问诊台,聚合多端事件和业务数据,提供全链路追踪、观测、排障等能力。
- 链路追踪:如
六、总结
- 开发好平台关键在于解决当下问题和需求,但平台化与业务多样性存在矛盾。预先设计架构和演进式架构各有弊端,要为可预见未来设计,预留扩展点,保障系统低耦合高内聚。
Made by 捣鼓键盘的小麦 / © 2025 Front Talk 版权所有