直播平台在贝壳找房中的实践与运用

用户头像
陈威威
关注
发布于: 2020 年 08 月 06 日
直播平台在贝壳找房中的实践与运用

作者:陈威威、宋红日、孙旭东

前言

场景线上化在各行各业已经成为一个趋势,贝壳也在尝试将多种场景搬到线上。比如线上对经纪人培训、线上看房、线上带看、线上签约等。突如其来的疫情加快了贝壳对场景线上化的诉求,而直播恰好可以满足这些场景,基于直播我们快速迭代出了多种线上化的直播场景,包括:通关培训,训练场,在线课堂,新房直播,二手直播,423周年庆直播,二手在线谈判,交易线上核签室等,以及马上开始的海外直播,装修直播,带看工作台,各种会议/庆典类的直播。



贝壳直播由直播前台、直播中台、客户端等几部分组成,由于直播属于紧急项目,时间短、任务重、人力少,最初的客户端按照功能实现的方式进行开发,确保项目的如期上线。上线后直播效果挺好,收到不少好评,后续有更多的业务方也想接入直播,造成直播场景多样化。随着直播场景和需求的多样化,纯粹面向单一项目的开发已经无法满足当下对直播的诉求,建设客户端的直播平台以支撑多样化直播场景迫在眉睫。接下来将分享我们支持诸多业务方的直播平台的建设历程。



1 行业难点

  1. 直播相关的功能较多,实时音视频、CDN旁路观看、IM、共享文档、共享视频、礼物、弹幕、分享等

  2. 良好的架构设计,拆分复杂的多场景业务

  3. 合理的协同开发,需要解决多人同时协同开发一个页面或者一个功能

  4. 新老版本的功能兼容,比如怎么解决新增消息类型在老版本的兼容问题

  5. 机型和系统兼容问题,无论 iOS 还是 Android,机型和系统版本都越来越多,需要做好不同硬件配置、不同系统版本的相互兼容

  6. 性能及资源占用优化,移动应用的计算资源受到相应系统的严格制约,在进行音视频采集,渲染,编码等复杂计算的同时,还要确保应用有足够的资源流畅运行,这要求开发人员有丰富的调优能力

2 业务痛点



  1. 中台和前台的部分边界不够明确,有些逻辑具体属于前台还是中台,没有标准的划分标准,造成开发过程中需要花费大量时间讨论解决这类问题。而且各端规范不够一致,不易理解,接入成本高

  2. 直播SDK技术分层不合理,很多业务逻辑和直播核心功能相互耦合,相互依赖和引用,造成内聚程度低、复用性差、扩展性低。一个功能需要对接多个业务后端,效率比较低下

  3. 动态配置化程度低,很多运营热区位,易变的功能区,缺乏动态配置下发的能里,而且接口对版本兼容也不够,很小的功能点的修改可能需要发版解决

  4. 快速进入开发成本高,由于直播和业务基本耦合在一起,需要花费大量时间梳理流程和功能,新人不能快速进入开发节奏

时序图如下:



3 痛点及难点的解决方案

1.明确各端边界和职责

由于直播和直播衍生出的业务涉及到的系统比较繁多,而且有些系统之间的功能严重相互重叠,我们第一步需要明确各系统的职责,以及相互调用的流程。熔断客户端为了一个功能同时与多个业务后端交互。如上图中,熔断客户端直接与商业化系统、拓客平台的直接交互。改造成客户端只与一个业务前台交互,所有的业务功能,移动端只需与前台交互即可完成。由前台去对接各个平台及系统,最大限度的简化移动端陷入复杂的多端交互中。边界明确后的架构图如下:

2.直播流程聚合和功能收敛

由于直播功能众多,并且流程复杂,设计到的后端和系统繁多,导致直白的业务接入成本高。这种情况下,需要做的是在各端职责明确的前提下,将直播相关的核心流程和功能封装统一管理。同时以接口或者抽象的形式把关键节点暴露给业务,保证功能节点的单一性而又不伤害业务的扩展性。简而言之,高度内聚核心流程和功能,降低业务逻辑的耦合和下沉。



3.直播平台技术分层

因为直播的核心流程是固定的,不会随着不同业务而改变,所以直播的核心流程应该是在直播平台管理,而且平台需要中断业务与直播中台的直接交互。业务只需向直播平台索取需要的服务,剩下的就像普通业务开发一样。

同时为了兼容不同业务使用直播流程中的部分功能,需要对技术做纵向分层,主要分成基础库(Basic)、直播框架(Framework)、控制层(Controller)、组件层(Compose),每一层都具备单一的功能职责。分层后的架构如下:

基础库(Basic):统一收口框架层(Framework)、控制层(Controller)、业务层(Business)的初始化以及必要参数的承接,使得初始化的入口只有一处,确保业务接入的唯一性、准确性,基础库没有多余的逻辑,仅仅用来做一些网络、业务标识等一些必要的初始化及信息暂存

直播框架(Framework):封装了直播的核心流程包括实时音视频、CDN旁路观看、IM、共享资料等。业务直接依赖框架层(Framework),可以满足对直播的核心功能的使用。

控制层(Controller):将直播中台和直播框架(Framework)串联起来,直播中台通过接口和配置文件来控制直播的流程以及功能,显著提升了直播在多场景下的灵活运用,结合框架层(Framework),业务即可直接跑通直播的核心流程。

组件层(Compose):封装一些业务通用的组件,比如点赞、分享、连麦、弹幕消息等,组件层是一个独立的层,不依赖任何层。完全不耦合任何业务或者依赖,显著提升了直播业务的开发效率。



4.动态化配置

通过技术分层的设计,彻底将功能从纵向解耦,而且每层功能结构清晰。为了可以灵活实现不同直播类型的随时切换,我们需要将很多功能及流程动态化,与后端约梳理易变的功能区以及约定对应的解决方案。

根据进入直播间的接口返回的数据决定是TRTC进房,还是CDN旁路观看;根据权限接口的数据决定是否具备某些功能,如点赞、连麦、推流、开启直播等;根据接口数据动态控制运营热区,如抽奖、领券、专属服务等;根据配置决定功能区具备哪些功能,如消息发送、点赞、分享、礼物、楼盘、资料共享、连等;根据配置决定直播类型,如庆典活动、会议类型直播、泛直播等



5.统一管理不同类型业务直播的数据和日志

任何框架都必须具备的能力之一就是监控和数据上报的能力,直播平台亦是如此。平台需要具备上报数据的逻辑,但是无需具备具体上报的功能,简而言之就是平台按照特定的逻辑将数据、日志收集存储下来。触发具体上报条件时,借助各端的上报功能进行具体的上报,这么做的优势是无需适配不同业务端的上报异常,而且无需维护具体数据上报的版本库。加入监控后的架构如下:

6.“零”成本接入和使用直播平台

解决完上面三个问题后,需要解决的就是如何降低不同业务接入直播平台的成本,降低学习成本。我们的目标是想Google提供给开发者的引用方式一样,只需引入对应的版本库、做必要的初始化,后续流程和功能自动完成,业务在此基础上关注点聚焦在业务上,无需关心直播相关的内容。使得直播的开发变的像普通业务开发一样单一,甚至更简单。

接入方式:

implementation(rootProject.ext.depsLibs.common_live) {
changing = true; transitive = true
}
implementation(rootProject.ext.depsLibs.ke_live_compose) {
changing = true; transitive = true
}
implementation(rootProject.ext.depsLibs.ke_live_controller) {
changing = true; transitive = true
}
implementation(rootProject.ext.depsLibs.ke_live_framework) {
changing = true; transitive = true
}
implementation(rootProject.ext.depsLibs.ke_lib_basic) {
changing = true; transitive = true
}

初始化:

//设置点播相关事件回调
mLiveController.setLivePlayListener(mLivePlayListener);
final String groupId = getRoomId() + "";
//注册直播各个节点事件回调
VideoManager.getInstance().registerCloudListener(groupId, mCloudListenerImpl);
//注册IM相关事件及广播
MessageManager.getInstance().registerMessageListener(groupId, mMessageListener);

资源回收:

mLiveController.onRelase();
VideoManager.getInstance().unRegisterCloudListener(mCloudListenerImpl);
MessageManager.getInstance().unRegisterMessageListener(mMessageListener);

4.终极形态

几大痛点难点解决完后,直播相关的流程、功能、架构已经清晰可见,我们将不同直播的场景按照类型划分出庆典活动类型、泛直播类型、会议类型、通关类型等,结合不同的业务接入方,汇集成终极直播平台架构如下:

5.业务接入及使用场景

通过技术分层,把直播相关的流程和功能做了高度封装,功能高度内聚,并且彻底解除业务与直播的耦合、业务与中台的耦合、业务与各个前台的耦合。使得直播功能的开发与普通业务开发几乎相同,只需关注业务层面的开发,无需关注直播相关的流程和功能。由于封装了大量通用型组件,业务开发甚至更高效。



目前贝壳家族业务接入直播平台的业务有:通关培训、训练场、在线谈判、在线核签、新房泛直播、新房1vN、二手泛直播、海外泛直播、庆典活动、二手带看工作台、新房带看工作台、装修等。效果如下:



后记

希望以上的分享能对陷入业务开发的同仁们有所触动,积极思考如何提升设计能力、从哪些维度考虑架构问题、怎么做技术的分层、以及提升整体的复用性、扩展性等。最后欢迎各位感兴趣的同学加入贝壳,一起搞些了不起的事情。

用户头像

陈威威

关注

还未添加个人签名 2019.05.14 加入

还未添加个人简介

评论

发布
暂无评论
直播平台在贝壳找房中的实践与运用