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

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

前言

场景线上化在各行各业已经成为一个趋势，贝壳也在尝试将多种场景搬到线上。比如线上对经纪人培训、线上看房、线上带看、线上签约等。突如其来的疫情加快了贝壳对场景线上化的诉求，而直播恰好可以满足这些场景，基于直播我们快速迭代出了多种线上化的直播场景，包括：通关培训，训练场，在线课堂，新房直播，二手直播，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、二手泛直播、海外泛直播、庆典活动、二手带看工作台、新房带看工作台、装修等。效果如下：

后记

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