开放平台 - 互动玩法演进之路

开发 前端
B站的互动玩法目前仍在发展完善阶段,我们经历了从0到1的探索阶段,并结合开放平台的体系完成了全链路的建设与搭建。然而,在1到100的发展过程中,相比市场中的竞品,我们仍需不断演进与探索。

1. 背景

随着直播业务和用户规模日益壮大,如何丰富直播间内容、增强直播间内用户互动效果,提升营收数据变得更加关键。为此,直播互动玩法应运而生。通过弹幕、礼物、点赞、大航海等方式,用户可以参与主播的直播内容。B站还通过开放平台,为第三方厂商和开发者提供了强大的技术支持,让直播互动玩法更加便捷、稳定和高效,为用户和主播创造了更多的乐趣和价值。

图:星体工作室 互动玩法案例图:星体工作室 互动玩法案例

2. 平台建设

在着手开发之前,我们需要确立清晰的业务划分边界,特别是涉及多方参与的开放平台互动玩法业务。这有助于避免日积月累的问题,确保未来的发展不受制于历史债务。

我们的业务划分主要集中在几个核心场景和能力模块上:

  • 开发者管理平台:与开发者互动,包括入驻流程、应用审核、礼物与面板审核。作为开发者数据的展示出口,为他们提供数据回收的支持。
  • 应用商店平台:与主播互动,包括平台与直播姬的应用展示与获取。提供定制化应用推荐算法的出口,以提升应用的曝光和吸引力。
  • 应用交互平台:与直播间用户互动,利用事件平台进行控制,包括开关礼物与面板。互动玩法期间数据流转等行为。监测与标记应用的实时状态,确保流畅的用户体验。
  • 结算平台:与营收互动,包括应用期间营收数据的统计、落库和对账。为确保透明度和准确性,提供完善的结算支持。

因此我们设计的如下的业务模块分层:

图:平台架构图:平台架构

3. 项目生命周期

图:互动玩法生命周期图:互动玩法生命周期

社区优先的原则确保了我们平台的演进和提升是以开发者和用户的需求为中心的良好策略,明确了业务边界之后,围绕互玩的整个生命周期,我们将重心放在四个核心提升目标上:

  • 开发者入驻效率与权益保障:通过简化入驻流程,提供清晰的文档和支持,确保开发者能够快速且顺利地接入平台。提供快速且准确的审核机制,加速应用上线,促进生态系统的快速发展。提供明确的营收手段与完善的对账系统,保证开发者收益。
  • 主播使用体验:提供直观且易用的工具和功能,以增强主播的覆盖率和互动性,提升直播质量。
  • 直播间用户体验:优化直播间界面,降低用户参与门槛。提供有趣、多样化的互动玩法,激发用户的参与热情,提高用户粘性。
  • 平台管控能力:强化对内容的管理和监督,确保内容的合法性与安全性。提供丰富的工具,快速响应违规行为,维护平台生态安全与健康。

3.1 入驻与开发

在整个互玩生命周期过程中,开发者接入平台与开发作为起点,门槛会直接影响开发者数量与互玩的供给速度,有一些问题是我们需要思考并解决的:

  • 开发者如何快速搭建模型?
  • 开发者如何低成本进行数据交互调试?
  • 个人开发者在缺少专业的礼物UI设计师的情况下如何进行礼物设计?

3.1.1 SDK&Demo

我们明白对事物的认识往往从“是什么”开始,然后才能理解“为什么是这样”。作为首次接入开放平台的开发者,理解众多API和调用文档并梳理出清晰的交互流程确实需要时间。同时由于开发者的历史开发背景各异,对官方接入文档的理解也会有所不同。

为了降低开发者的开发成本并减轻研发的解答压力,我们在完善官方技术文档的同时,提供了不同语言的示例,以帮助开发者建立概念模型:

  • Unity&C#客户端SDK
  • Python&Golang Demo

图:互动玩法接入SDK&Demo图:互动玩法接入SDK&Demo

3.1.2 启动调试能力

测试阶段是完整的应用开发流程中不可或缺的一个重要环节,未经充分测试的应用可能存在潜在的不可预估的风险,为了辅助开发者在应用上架之前能够进行充分且完善的测试,我们解决了以下两点问题:

Q:开发者在应用开发完成之后如何在真实环境下测试应用功能?

A:在应用通过审核之前,开发者可以选择将其直播间设置为白名单直播间,这就意味着开发者可以在真实的线上环境中对其开发的应用进行完整的测试与功能回归。

Q:送礼、发送醒目留言以及大航海是互动玩法交互的重要组成部分,在线上环境应该如何进行这几种交互操作的调试?

A:这几种直播间用户参与的高成本行为,让开发者在线上环境使用正常流程进行大量的测试显然是不合理的。为了解决这个问题,我们提供了开发者调试工具。通过这个此工具,开发者可以通过后台操作主动触发由开放平台发出的长连接消息内容(包括弹幕、送礼、大航海和醒目留言),从操作到出口消息的过程则由平台侧保证数据的正确性。

图:开发者调试工具图:开发者调试工具

3.1.3 官方素材库

在互动玩法系统初期,开发者需要手动设计并上传礼物素材,不仅增加了开发者的研发成本,也加大了运营审核的难度和成本,从而导致素材管理混乱。为了解决这一问题,我们为开发者提供了一个更便捷的解决方案:官方素材库。

现在,开发者只需从官方素材库中选择适合的内容,提交创建礼物即可。这一方案在业务规范性方面有很大的提升,同时降低了设计成本和审核成本。为整个互动玩法系统创造了更为有序和统一的环境,促进了生态的可持续发展。

同时为了确保官方素材库中的礼物符合用户需求,我们会定期进行用户调研。并且也会定期更新官方素材库,添加新的礼物元素和主题,以满足用户不断变化的需求和兴趣。

图:官方礼物素材库图:官方礼物素材库

3.2 提交与审核

3.2.1 包管理工具

当进行互动玩法项目的提审并需要上传包体时,如何有效地避免被当作一个网盘服务?这个时候我们可以反向利用单点故障理论进行思考。

单点故障理论:系统中存在一个或一些关键的组件、环节或节点,如果其中的任何一个被破坏、故障或失效,可能导致整个系统的崩溃或失效。

我们可以通过分析利用平台作为网盘的使用路径来找到其专属单点故障:

  1. 获取上传链接
  2. 上传文件
  3. 进行持久化存储
  4. 下载文件

在不影响正常业务逻辑的情况下,我们针对第3步进行处理,持久化存储追加前提条件,提升存储门槛,以业务的视角控制有效文件的判定,定时扫描删除无效包体。

同时这个问题普遍出现在开放平台的各个业务场景,因此我们搭建了一个包管理系统,统一收口这一业务场景。

图:包生命周期管理图:包生命周期管理

3.2.2 运营审核工具

我们可以通过分析利用平台作为网盘的使用路径方面进行审核:

  • 互动玩法内容是否合规,是否存在敏感内容?
  • 互动玩法调用模式是否符合开放平台规范?

作为运营,只能够在审核的使用过程中,对于互动玩法内容作出合规性校验,因此我们为运营提供基础的合规性校验工具对于包体进行校验,为运营提供审核依据。

该工具需同时满足两个条件:

  • 监听服务对于开放平台的请求
  • 统计接口的调用频率

在技术调研初期,想通过抓包工具对数据进行分析,监听https请求的443端口流量,并且从流量中过滤出来host为"live-open.biliapi.com"的相关请求,即对开放平台相关请求。

图:监听端口流量图:监听端口流量

经过测试,由于通过抓包工具是在七层协议中传输层截取的数据,基于https协议的请求数据都被加密,无法获取具体的请求内容,不满足条件2,因此该方案被否决。

图:抓包结果图:抓包结果

为了获取接口调用的详细情况,有两个数据来源,调用方和被调用方。在无法强制在调用方代码中插入统计逻辑的情况下,目光便聚焦在被调用方,但线上服务器用作测试统计,显然是不合理的。

线上真实环境不能用,便考虑使用仿真沙盒环境, 此时代理转发的方案呼之欲出,大概思路如下:

  1. 用户更改本地host配置,把开放平台的域名指向localhost
  2. 本地启动一个代理服务,监听443端口
  3. 本地代理负责转发"live-open.biliapi.com"的相关请求与记录接口调用结果
  4. 本地服务关闭时输出调用结果。

图:沙盒代理流程图:沙盒代理流程

图:检测结果图:检测结果

3.3 使用与结算

3.3.1 身份码体系

互动玩法的使用与直播房间强绑定,因此在互动玩法开启时,玩法客户端需要一个途径与当前直播间进行关联操作,基于此问题,我们考虑过以下两种途径:

提供方式

优势

劣势

开启互动玩法后主播输入房间号

使用门槛低,可在OBS使用

安全性低,主播可以在他人直播间开启互动玩法

读取主播的登陆态传递房间号

安全性中,主播之间不可互相开启

使用门槛高,只能在直播姬使用

开发者可以开启任意房间的互动玩法


在以上两种途径的劣势都不可接受的情况下,我们需要一种新的房间号标识的传输方式,并且同时要满足以下几个要求:

  • 不依赖直播姬的登陆态,主播在使用其他直播工具时依然可以开启互动玩法
  • 主播之间不可知,主播不可以通过一个公开标识启动其他主播的应用
  • 开发者不可知,玩法开发者无法获取任意主播的应用

因此我们推出了一套独立标识(即身份码系统),主播可以生成唯一标识与房间号绑定,并且在公域对他人不可见,确保主播之间以及主播与开发者之间的信息是隔离的,与开放平台的交互通过身份码进行,由开放平台进行数据转换,并且同时为了避免身份码泄漏造成安全问题,提供定时刷新以及手动强制刷新能力,保证数据的合规安全。

3.3.2 互动结算

与开发者分成由互动玩法产生的营收流水是构建良好合作模式的关键。然而,如果仅以互动启动时间作为计算依据,可能会导致不合理的结果,因为在启动期间产生的舰长、醒目留言等营收行为都会被计算在内。

为了解决这个问题,我们提出了一个与互动玩法紧密相关的流水计算依据:互动礼物。每一个互动玩法都有自己特定的礼物,我们只统计由互动礼物产生的营收。这样可以准确反映互动玩法的实际贡献,避免了其他不相关因素的干扰。

通过将互动礼物作为流水计算的依据,我们希望能够建立一个更公正、透明且与互动玩法紧密相关的分成机制,从而激励更多的开发者参与。这不仅可以提高开发者的积极性,也有助于形成一个健康、正向循环的互动生态。

由于不同的互动玩法的分成比例不同且可以实时调整,这给我们的管理和感知带来了挑战。为了有效应对这些变化,我们需要建立一套与公司内部结算体系紧密相关的结算系统。

图:结算架构图:结算架构

同时为了保障公司和开发者的权益,我们需要进行流水对账工作,主要包括以下两个维度:

  • 实时对账:在互动玩法运行过程中,建立实时对账系统,实时追踪和核对每一笔交易的流水,以便及时发现和解决可能出现的问题。
  • 日流水对账:日流水对账是对实时对账的补充,也是在出具日账单前的最后核查工作。通过日流水对账,我们可以确保对账的准确性和完整性。

图:结算对账流程图:结算对账流程

3.4 监控与反馈

在开放平台的互动玩法系统的迭代维护过程中,确保系统的安全性和鲁棒性是至关重要的。面对各种不确定性、噪声以及变化,保障系统在这些情况下能够保持稳定的基本能力是一个重大因素。考虑到互动玩法系统的调用方均为外部开发者,相比公司内部业务,我们需要更加严格的管控措施。

上线并不是互动玩法生命周期的终点,我们采取了一系列措施来持续跟踪监控系统,对系统bug进行触达反馈,并对恶意调用进行限流或封禁,以确保平台高效运转或在极端情况下降低运行。

以下是我们采用的一些措施:

  • 安全中心体系:为防止突发流量的恶意请求,我们将互玩相关接口接入开放平台统一的安全管控中心。超过预设限制的调用方将被一段时间封禁,并随着触发次数的增加,封禁时间会逐渐延长,后续可以单独讨论一下安全中心的相关建设。
  • 监控大盘与数据统计:除了突发流量,开发者频繁的错误请求也是常见问题。我们在请求时进行上报统计,并将数据接入公司的监控平台,实时观察和统计。这有助于降低告警的噪音,同时提高对问题的敏感度。
  • 线上问题反馈:针对互动玩法内的bug,我们为主播提供了专门的反馈渠道。通过定期机器人同步,运营团队能够将问题及时反馈给开发者,从而实现问题的快速定位和解决。

图:监控大盘图:监控大盘

4. 未来展望

B站的互动玩法目前仍在发展完善阶段,我们经历了从0到1的探索阶段,并结合开放平台的体系完成了全链路的建设与搭建。然而,在1到100的发展过程中,相比市场中的竞品,我们仍需不断演进与探索。

我们面临的挑战有以下几个方面:

  • 数据实时分析能力不足:在互动玩法过程中,我们实时数据分析能力不足。强化数据预警分析能力可以帮助我们及时地发现潜在问题并做出相应调整。
  • 商业化体系尚待完善:我们需要提升直播间用户的消费能力,同时深入挖掘直播间广大用户的潜在商业价值。完善商业化体系将有助于增加收入来源并提高用户参与度。
  • 超前思考系统稳定性建设:随着上架的互玩和使用的主播扩大,我们需要以超前的思维布局,持续思考和落地系统的稳定性建设。这包括技术和流程的不断优化,以确保系统的稳定性和用户体验。

在面对这些挑战时,通过持续的努力和创新,我们相信可以不断优化互动玩法系统,更好地满足用户需求,使其在市场中脱颖而出。

本期作者

吴盛哔哩哔哩高级开发工程师吴盛哔哩哔哩高级开发工程师

张梦瑶 哔哩哔哩高级开发工程师张梦瑶 哔哩哔哩高级开发工程师

贺一科 哔哩哔哩高级开发工程师贺一科 哔哩哔哩高级开发工程师

魏骏文 哔哩哔哩资深开发工程师魏骏文 哔哩哔哩资深开发工程师

责任编辑:武晓燕 来源: 哔哩哔哩技术
相关推荐

2015-12-30 14:29:53

NFV开放平台

2021-08-18 17:16:10

Git分片读写分离

2019-02-18 15:23:21

马蜂窝MESLambda

2023-07-02 11:14:21

工具TypeScript框架

2023-03-16 07:20:15

大数据平台云数据

2019-04-23 09:13:54

苏宁采购架构

2017-06-29 13:29:34

大数据PAI机器学习

2017-10-23 09:10:52

2013-04-27 14:27:39

大数据全球技术峰会大数据开放数据平台

2024-07-17 11:40:58

2024-10-28 22:37:36

下载中心设计系统

2023-01-03 17:43:39

网易邮箱数仓

2009-08-05 16:14:32

CDMA网络的演进无线网络发展

2018-03-27 10:06:26

对象存储演进

2015-11-23 16:22:11

互联网

2023-02-01 10:11:06

转转容器日志

2014-01-15 09:09:56

2012-11-19 11:36:16

PTNLTE网络承载

2024-08-14 08:11:41

2016-03-15 16:24:47

集群调度框架演进
点赞
收藏

51CTO技术栈公众号