秀场直播的四种实现方式，让我们从方案架构进行分析
秀场互动直播是 RTC 技术应用的常见场景，虽然主播 PK 的业务逻辑不算复杂，但由于在标准直播模式和主播 PK 模式的切换过程中容易产生卡顿、黑屏等现象，为了在优雅实现业务逻辑的同时，最大程度缓解类似的音视频体验问题，工程师们八仙过海各显神通，提出了很多种秀场直播的实现架构，下面我们介绍其中最典型的四种架构。
基础方案
这是一种最常见的实现方式，标准直播使用推流 SDK，切换成 PK 模式的话，走的是连麦及合流转码服务。其他方案的优缺点主要都基于与这一方案进行比较。
可能风险
兼容性：客户端会集成两个 SDK，现实中，采用该方案的客户多会有两个供应商，一个提供连麦，一个负责直播，这会存在产生产品间兼容性问题的隐患。
卡顿黑屏：由于推流 SDK 和 RTC SDK 是分开的两个 SDK，由于涉及到资源的申请和释放，因此，在模式切换时，是比较容易产生卡顿、黑屏等现象的，优化难度较大。
双流方案
所谓双流，指的是观众端会拉两个主播的流，而非其他方案的一个流。除了双流以外，该方案还没有使用连麦服务中的合流转码功能。
方案优点
连麦费用较低：使用单路转推功能，替代掉合流转码功能，由于合流转码一般的单价较高，因此，连麦的消费费用会有较明显的降低。
可能风险
直播云费用较高：虽然连麦的消费会显著下降，但由于观众端直播流需要拉两路，因此直播云消费可能会显著上升，如果观众主播比较大的话，连麦+直播的总消费会较明显增大。
兼容性：跟标准直播一样，客户端集成了两个 SDK，导致模式间切换的体验优化比较困难，产品间的兼容性隐患依旧存在。
观众体验：双流方案，观众端的体验比单流方案是可能有所下滑的，一方面对观众端的带宽要求更高(*2)，另一方面，还存在一定概率的两个主播的rtmp流时间不太同步的隐患
拓展性：方案的扩展性相对也差些，比如如果未来要做主播观众连麦的玩法，终究还是会回到合流转码的方式上去。
客户端合流方案
客户端合流方案的主要特点就是主播pk画面的合流由客户端完成。
方案优点
成本低：把合流放到客户端做，那就完全节省了这部分消费，因此，这是个成本最低的方案。
切换体验：由于始终保持着客户端跟直播云的上行推流线路，在模式切换时不存在所谓进入抢流模式（两个不同的上行推流设备，同时往一个直播通道推流，后推的设备会顶掉前面的上行设备，该模式称之为直播抢流模式），所以理论上模式间切换的体验优化会稍稍好做些。
可能风险
带宽要求：这个方案缺点也比较显著，把合流放到客户端，对主播的网络和手机性能要求都明显提高，尤其是网络，现在多了一路推流，等于上行带宽2，对直播而言，主播端的推流情况对观众体验的影响是最重要的，主播带宽要求2，直播体验下降的风险必然增加很大。
七牛方案
七牛秀场直播解决方案结合了七牛云 QRTC 和 Pili。从技术上说，我们可以称该方案为纯 RTC 秀场直播方案，他抛弃了相对落后的 RTMP 推流模块，在技术上具备一定先进性。这一方案相比标准方案，唯一存在的风险是在标准直播模式下，会增加一个单路转推的费用风险，但由于该服务单价极低，因此新增费用相对可控。
方案优点
包体小：客户端只用了一个 RTC SDK，客户接入成本相对较低，且因为少个SDK，最终APP的包体会略有下降。
体验好：标准直播模式，使用的是先进的 RTC 推流，相比 RTMP推流，RTC 推流抗弱网的表现更好，经测试，RTMP 推流在丢包 10% 情况下卡顿、延时往往就比较显著了，而 RTC 往往可以到 30% 丢包甚至更大的情况下，依然能有比较流畅的声画体验，这是因为从技术上说，RTC 是比 RTMP 更先进的音视频传输技术，是当前人类在音视频传输领域进步的典型成果展示。
抗弱网：推流抗弱网对绝大多数的秀场直播而言，其实意义不是很大，因为专业的主播往往网络条件比较好，但在户外等场景，RTC 推流的意义还是非常显著的。
切换好：由于使用的是一个 RTC SDK，模式切换时，不存在SDK资源申请和释放的问题，模式切换的体验优化相对更容易些。
多兼容：该方案除了实时音视频云和直播云，七牛秀场直播方案在RTC SDK上还深度融合了商汤和字节跳动的美颜滤镜SDK，这一方面帮助客户规避了产品间兼容性问题，另一方面又可以让客户享受到完整的闭环服务，且整个方案代码已全部开源。
在秀场直播这一场景的七牛解决方案中，实时音视频云 QRTC 实现实时连麦互动，主播间连麦、主播与观众的音视频实时互动。通过直播云 Pili 的直播流分发，以及融合了行业 TOP 美颜滤镜 SDK，观众观看到经过美颜、滤镜以及妆容修饰的主播直播间画面。通过 IM 聊天、点赞、打赏等功能实现了更好的互动。同时，借助七牛对象存储 Kodo 实现直播内容的录制，以及 Dora 实现内容审核。