[置顶] 大型直播平台应用架构浅谈
进入直播领域有段时间了。
跟大多数同学一样，刚接触直播这个领域都非常好奇这个领域的宏观架构大概是什么样子的。
这里根据自己的这段时间学习，粗浅总结下分享给感兴趣的小伙伴扫扫盲。
目前直播平台有很多，抖/快、B站、斗/虎等。
直播这种高效的交互方式是各行业需要具备的能力，随着网络技术的发展也是必然趋势。
先抛开每家直播的内容不同之外，一个完整的直播平台至少需要包含如下几个核心功能。
观看直播、发送弹幕、打赏送礼、主播互动。
我们以一个普通的C端用户的视角，来看下这几个核心功能背后的大概应用架构。
观看直播
当我们进入直播间首先就是观看直播内容。
【拉流】
直播内容是通过 流媒体播放器 播放出来，而流媒体播放器通过 流地址 来拉取 流数据，再处理相关 解码 工作，最后呈现出画面和声音。
为了保证全国甚至海外用户都能够流畅的观看直播内容，就需要比较强大的物理网络覆盖。
流媒体数据通过上游CDN源站推（或推拉结合）到所有边缘节点。
不同地域的用户通过 全局CDN-DNS 调度后，就近访问CDN节点。
为了尽可能覆盖所有地区，不可能每家公司都去建设庞大的网络基建。
这时候就需要借助强大的公有云平台（BAT、华为、金山、字节等）。
公有云厂商砸了巨额资金建设物理链路，作为应用型企业只需要使用云产品能力即可，一切即服务。
当我们愉快的看着直播时，会好奇这些直播内容源头在哪里，这些画面是如何被采集的，数据又如何传输的。
【推流】
通常开播都有一个开播工具，开播工具是专门用来采集流媒体（音视频设备）信息及媒体流合成的，也可以用 OBS 等强大的推流工具。
当开播工具采集到媒体信息之后会进行本地压缩，然后通过 RTMP（Real Time Message Protocol） 协议将数据推送到RTMP服务器。
RTMP服务器收到流媒体数据之后，会将流信息解码并且进行 HLS（HTTP Live Streaming） 文件切片。
将RTMP服务器部署在公有云主机上，是为了借助公有云内部服务（LAAS、PAAS）的亲和性，可以最大化便捷的覆盖到CDN边缘节点。
你可能好奇，为什么推流用RTMP协议而拉流用HLS协议。
播端使用RTMP，是因为RTMP基于TCP的实时协议，可以保证推流的可靠性和实时性。
看端使用HLS是因为HLS是基于静态小文件，这就比较方便在大规模百万 PCU（Peak concurrent users ） 时，利用静态CDN容易分发的优势来覆盖。
使用HLS同时也便于在不同码率之间进行动态切换，以此来达到根据用户的网络情况选择最优的观看体验。
比如，用户处于弱网下，我们就切到低码率下观看。
用户网络良好时，我们就切到高码率下观看，同时也可以使用一些高级的观看体验和交互。
当然，HLS还有非常多的优势，在压缩、加解密等方面都非常成熟。
在2C大规模直播场景下，flv是过去时，HLS才是未来。
【P2P】
为了尽可能节省CDN带来的巨大成本，会使用 P2P（Peer to Peer） 技术来减少公有云带宽使用。
同样，为了尽可能将 STUN 服务器 、信令服务器 离用户近一些，这两个服务器都是部署在公有云边缘主机上。
进一步压榨成本，还可以使用 PCDN（P2PCDN） 服务。
由于公有云强大的终端网络覆盖（路由器、终端设备等）可以将CDN分发内容进一步边缘化。
利用数以万计的边缘计算能力将内容和计算一直延伸到用户末端。
其实P2P技术已经非常成熟且发展历史要比WEB互联网久远。
发送弹幕
观看直播时非常重要的一个诉求就是与主播互动，而弹幕是信息承载量最大的互动方式。
弹幕 现在已经是视频领域必不可少的媒体元素。
弹幕最早其实是在点播领域里，日本的 Niconico 算是弹幕互动的鼻祖。
A站 （Acfun）基本是国内弹幕视频网站的文化发源地 。
但是目前国内把弹幕玩出新次元的当属B站（bilibili）了。
弹幕从发送到接受，依赖 长连接 中间件。
考虑到平台可用性，长连接服务整体需要支持容灾，整个架构需要支持多机房混合部署。
在弹幕消息投递端需要做机房线路探活，根据探活后的相关数据择优选择机房。
使用公有云还有一个好处，可以享受一定额度 “对等连接” 增值服务。
整体架构越来越趋向混合云，就是为了尽可能平衡私有云的核心数据闭环，同时借助公有云强大的网络覆盖。
公有云高性能主机一般在低频下能扛个百万连接，瓶颈基本在内存和带宽。
机器成本其实还好，因为机器理论上可以无限扩展，但是带宽是有物理上限的，所以比较贵。
【舆情管控】
任何有一定体量的互联网公司，根据所处的行业和内容不同，需要对用户的参与行为进行舆情管控。
弹幕区就是需要管控的一个主要阵地，也是各安全中心所负责的核心战场之一。
弹幕的特点也恰恰是很难管控的，通常思路根据AI算法（如NLP）对弹幕内容进行前置敏感词过滤、情感分析负向过滤等。
其实，AI算法能处理的都是相对简单和容易识别的语意。
中国文字和文化博大精深，再加上复杂的词藻、词梗组合起来，就算再强大的算法都无法绝对识别。
需要人工辅助审核，人工还需要有一定的“文化”底蕴和相当广的“知识面”。
所以必然是一个非常庞大的审核队伍。
一般应用企业，做弹幕功能技术含量并不高，而且现在云厂商、开源sdk，稍微组合下架构基本就搭能起来。
反而是，安全、舆情管控才是最关键和重点投入的地方。
现在做第三方舆情发现和管控的公司也慢慢多了，社会类舆情管控公司还是比较多的，细分垂直类是比较少。
送礼打赏
在观看一段主播卖力的表演之后，就需要通过打赏来表达诚意了。
一个看似简单的送礼，其实需要涉及非常多的系统，这些系统位于不同的职责层面上。
但是不论是在直播领域还是电商、教育，基本都是类似的，只是售卖不同的商品而已。
送礼链路上，订单、账户、清结算其实是比较成熟的交易、财务模型。
这两块基本上按照模式来套，目的就是完成公司的确认收入和资金结算。
【整体链路】
我们将整个链路分两层，第一层是售卖业务层，该层由一系列售卖单元组成，比如商城、促销中心等。
在直播领域，送礼系统就是位于这一层，送礼物可以认为是一种虚拟商品的交易。
送礼场景可以非常多样化，但都是在变相的促进交易的达成。
一旦当商品售卖成功之后，根据业务性质的不同，确认收入的金额和时间点也不同。
在直播送礼中，送出去的礼物基本就是近实时确认收入，此时就需要交易订单（或叫业务订单）来承载这部分交易职责。
在售卖业务层下层是交易结算层，是收入的分账、结算、打款部分。
该部分的核心是支撑业务售卖的交易，清结算各个角色的收入。是交易结算系统最复杂的地方，也是及容易出现资损的地方。
不论我们售卖什么，要想在交易系统里完整的跑起来，首先就需要将虚拟的售卖概念进行商品化。
有了商品之后就可以通过售卖层上架去销售。
送礼本身业务比较简单，将个人账户的虚拟资产进行扣除，加到主播账户中去，就完成了业务上的基本流程。
这一步完成之后，紧接着就需要对这笔交易订单进行分账处理。需要分别计算平台、外部商家/机构等各个角色参与者分别得多少钱。
送礼成功之后至少是需要平台、主播（或工会）进行一定分成。
该部分是清结算系统中的清算部分职责，该部分通过计费、分摊分别计算好各个角色结算明细。
结算系统再通过定期捞取合同签订的结算周期（T+N/月结等）给商家结算并且打款，该部分多数是有账期的。
简言之，送礼打赏偏交易结算领域，整个系统的核心在于账务、交易、财务等业务知识。
同时在系统设计上，数据一致性、对账流程和场景是整个系统架构设计的核心。
主播互动
在直播间里，送礼不管对主播还是平台来说，都是最终目的。但是这个最终目的不可能一步达到，是需要不断的通过其他场景来转化。
直播用户的绝大部分需求是荷尔蒙需求，如何通过各种互动工具、互动形式，让用户与主播彼此多互动，才能促进送礼。
从用户视角来看互动形式主要分为三类，弹幕、手势、送礼。
如抖/快双击屏幕点赞，虎牙的长按唤起快捷面板，B站的发送特殊弹幕触发“热力风暴”特效等。
同时基本每家都有的特殊礼物互动，通过赠送特殊礼物来达到房间主题变化、主播装扮变化等。
所有的互动形式我们都需要统一的进行抽象管理，可以用一句话概括： “在指定的房间指定的时间段，启用一个或多个互动活动/玩法”。
至于某个具体的互动玩法，该玩法需要哪些素材，需要哪些触发媒介，除了通道部分可以走订阅方式，其他都需要定制开发。
比如，弹幕互动中的蓄力类的，除了通用的弹幕通道之后，哪些词，在多少时间窗口内命中多少次，然后触发什么业务逻辑。
或连击送礼蓄力类，除了送礼通道是通用部分之外，哪些礼物，在多少时间窗口内送出多少个，金额满足多少都属于业务逻辑需要捕获和处理的地方。
整个互动是需要打通看端和播端。
看端特效和播端特效是有明显区别的，看端多数是在直播间里可以交互的特效元素，而播端特效最终是在流里体现的。
比如，一个送礼互动特效，用户“连续”赠送礼物到达一定的阈值就触发播端的互动逻辑，最终将消息输入到流里，同时看需求是否添加 SEI（Supplemental Enhancement Information） 信息。
房间主题
如果我们将直播间比喻成现实中的房间，我们希望是千人千面的，并且具有一定的定制性。
同时，我们希望房间可以根据日历自动感知到节日的 娱乐性 、 严肃性 。
如果将直播间比喻成线上的社区单元，那此地也不是法外之地，需要受到不同程度的舆情、社敏性、法律安全监管。
直播间按照业务形态划分，有非常多的维度去分，比如商业化房间（带货/电商/分销）、游戏房间、K歌房、放映厅等。
最终，不同的房间需要开放、管制一些能力，互动娱乐，送礼，主播行为等。
日历和主题管理是整个房间生成的基础基因。
需要对房间整个架构进行工程化设计，要面向接口、面向开放标准。
只有这样才能具备定制性和扩展性。
整个房间大概有几个核心区域， ___送礼区、播放器区、弹幕区、互动区。
这几个区域的实现需要分成两层，第一层实现最核心的内核基础功能。
这部分功能可以直接排除主题相关性。
第二层是其他带有装饰的功能，这部分实现需要具备主题感知能力。
在此基础之上，我们假设实现一个弹幕区的特殊弹幕效果。
该实现插件通过工程化接口和标准，拿到日历&主题便可以感知到节日的属性。在实现上可以分离出基础功能和效果功能。
这样设计还便于将效果类功能做全年的特殊节日的自动化测试和业务巡检。
房间推荐算法需要加入日历推荐因子，这部分是比较好理解的。比较有意思的是房间构造中心才是房间成品的出口。
活动保障
最后分享下技术保障方面的内容。
这部分就精简总结下，不叙述过程。
简言之，保障主要关注两个重点。
第一个重点是我们大多数比较熟悉的应用系统常规的抗高并发，这里包括一系列的中间件、DB、缓存、微服务套件等。
第二个重点是跟PCU相关的线性资源CDN带宽、P2P带宽、长连带宽、打点、实时报表计算等。
按照看、播两端分别来看。
播端，需要重点保障推流的可用性，所以基本上在推流侧至少有两路流互相backup。
看端，QPS、TPS相关接口基本是斜率或突增流量相关。
（注：某接口峰值可以扛住10wQPS，到达这个峰值是每秒钟加1w缓慢增加，还是1s到达10w是不一样的。）
斜率本质考验的是后端相关资源的扩容速度。
在大并发场景下，有时候我们需要提前扩容就是为了防止突增流量。
这也是按照斜率来评估扩容资源的难点。
另外一方面是跟PCU线性相关的。
PCU直接带来的是相关公有云带宽、连接池等比例增加，这部分需要做好资源预购。
当在线的人数非常高时，数据上报、实时数据处理也都是线性增加的。
这部分存储资源是需要提前预备好，计算资源可以适当弹性调度。
所有上述场景在合理的容量范围内系统都可以承载，但是一旦有非预期的流量进来我们也要有自我保护的机制和拉闸能力。
这部分相关的，限流、降级能力也是必不可少的。