疫情让线下零售降到冰点，却让直播APP火起来。直播电商、直播教育等各类直播应用赢得历史性机遇。很多人已经开始接受并认可这种新型应用的便利性和价值。个人感觉，随着5G的普及，“直播+垂直领域+精细化私域流量”将成为互联网热点，迎来真正的红利期。直播行业大约在10年前开始兴起。秀场直播和游戏直播是PC时代比较成功的应用场景。直到2016年，随着移动互联网的大规模普及，直播行业迎来了真正的元年，数百款直播APP出现在大众视野中。2018年初左右，当时流行直播答题。直播应用首次全民普及。电子商务。回顾直播行业的发展，直播应用在各个领域百花齐放，那么背后的技术架构你了解吗？两年前，我参与了一个支持100万用户同时在线，20万用户并发的直播答疑系统的架构设计。下面将以“直播答疑”的应用场景为例，带你了解当前疫情下火爆的直播应用背后的真相。技术架构。内容分为以下4个部分：产品功能介绍面临的技术挑战技术选型及依据架构设计方案01产品功能介绍直播答题由于其玩法简单，用户教育成本几乎为零，在当时火了一把。简单来说就是：全民在线PK，10秒答题，超时或答错退出游戏，答对所有问题平分奖金，俗称开心词典网络版。在了解系统设计和架构之前，我们先了解一下直播答题应用的核心功能？以下为APP端部分产品截图：1.答题以活动形式进行，直播开始时间、答题总奖金、红包雨奖金等信息每项活动将提前公布。2、活动时间到后，用户可以进入直播间，观看实时视频流。将有专业主持人播报连环话，场控人员配合主持人同步提问并公布答案。3、问题发出后，用户有10秒的时间回答问题。如果答错或超时，游戏将退出。如果用户有复活道具，答错时会自动使用，用户可以继续回答问题。4、为了留住答错的用户，活动期间会下很多红包雨，用户点击屏幕就有机会抢到。5、活动期间，用户可以发弹幕，同时会有弹幕滚动，营造热闹的直播氛围。6.其他功能：邀请新人、活动列表、提现等。其他直播类应用在产品功能上与直播答题类似，基本分为这两类：1、直播基本功能：麦克风互动直播（支持多码率、多协议、多主播同框）、美颜效果、回放画面、IM聊天、点赞、屏幕分享等功能需求，以及防盗链、涉黄涉政等非功能需求。2.个性化功能应用本身：比如答题场景的发帖、答题、发布答案，电商场景的商品展示，一键下单购买，网红直播场景的礼物打赏。02技术挑战我们在做直播答疑应用时遇到了以下技术挑战：1.音视频处理与传输：涉及音视频编码、实时美化、视频推流、CDN加速分发、终端适配与播放，流量统计等很多技术点，而我们当时的技术团队没有音视频方面的专家。2、高并发请求：参考峰会等竞品用户水平，预估100万用户同时在线，1秒内20万用户同时答题;单个用户1秒内可以触屏发起4-5个请求红包请求最高并发可达500WQPS。3、带宽压力大：按照标清视频的标准，看直播的码流至少1Mbps。如果100W用户在线，光视频流输出带宽可达976.56Gbps。一个弹幕可以达到130字节，一秒需要滚动20个弹幕。如果需要同时推送给100W用户，弹幕的出口带宽也将达到19.37Gbps。4.计算压力大：1题误判涉及答案对比，复活道具的使用，判断用户是否刷新记录，还涉及到一系列的反作弊策略（比如上一题答错了，将无法继续回答），在主持人公布的回答时刻，如何快速完成100W用户回答结果的计算？5、资金流向的正确性和安全性：单个用户如何最多不超过3个红包？财务上，如何保证答题奖金和红包奖励不出现1分差错？6.低延迟需求：直播场景如何融合视频流和业务数据流，同步声音、主播画面和标题，保证用户体验？7、对商城交易业务干扰小：直播答疑只是商城的一项运营活动，核心目的是导流。依托商城原有用户系统、操作系统、大数据系统、提现通道等，对商城现有交易系统干扰小？可以看出，答题的泛娱乐直播场景还有很多技术挑战，这取决于直播应用的用户数量和业务流程。即使是直播电商这样的低频交易转化场景，如果李佳琦在带货，她也会面临瞬时抢购的高并发挑战，所以业务高峰期的压力一定是在设计架构时考虑到，系统的各个方面都必须能够动态扩展。03技术选择及依据1.音视频处理传输方案选择音视频处理传输，因为技术团队没有这方面的能力，所以当时考察了各个云厂商的支付方案，最后采用腾讯云直播解决方案。主播端：通过演播室的专业摄像设备，搭配腾讯云提供的obs推流软件，可以进行视频录制和推流。用户端：APP端集成腾讯云的SDK，动态获取推流地址后即可观看直播。2、业务数据流方案选择业务数据是指除了音视频之外，与答题（如提问、回答、弹幕、红包等）应用场景相关的数据。腾讯云提供两种选择：1.主题是预先设置好的，腾讯云SDK直接通过音视频通道发送，进入直播。2.让话题通过腾讯云的IM通道快速传递到观众APP，然后缓存在观众处，播放器通知预期的NTP时间戳后显示话题。腾讯云的这两个方案都可以提供“声-图-问”的完美同步，但是有以下限制：用户的回答必须以HTTP请求的形式聚合到答题服务器，这部分必须由开发者自行开发。本身。腾讯云系统不支持红包、弹幕等服务，仍需在底层通信通道上进行开发。考虑到以上的局限性和业务的可变性，我们最终打算开发自己的业务数据流通道。这样的话，视频流和业务数据流会分两个通道进行传递，因为业务流的数据量相对于视频流来说是比较小的，只要业务逻辑的处理速度和下行速度业务数据的质量可以得到保证，“声画题”的延迟是可以接受的。毕竟那时候已经是4G时代了。如果用户端网速不好，可能无法正常观看视频流。为了实现业务数据流的独立传输，需要实现一个长连接、高性能的网关服务器（支持100W用户同时在线，20W并发答题，实时弹幕推送等），我们的技术选择是：Netty，ProtoBuf，WebSocket，选择理由：1.Netty：Netty是当时最流行的高性能异步NIO框架。在直播答题的业务场景中，涉及到提问投放、弹幕、红包雨等众多推送场景。而且，在一次问答活动中，客户端与服务端的通信比较频繁，长连接在性能上要优于短连接。2.ProtoBuf：作为客户端和服务端之间的一种数据交换格式，PB是一种二进制数据传输格式，具有极好的效率和兼容性。在码流和序列化速度上明显优于JSON、XML、Hessian等主流格式，同时支持向前向后兼容和各种主流语言。3、WebSocket：是HTML5的一个新协议，用于实现客户端与服务端的长连接通信。3、服务器的部署方案选择前面提到，直播答疑只是商城的一项运营活动，依赖于商城原有的用户系统、操作系统、大数据系统、提现通道等。现有商城系统部署在我们自建机房。为了降低对商城现有交易系统的低干扰，我们采用“私有云+公有云”的混合部署方案。将高并发应答系统及其依赖的缓存、MQ等公共组件部署在公有云上，方便弹性扩展，降低流量对商城交易系统的影响。04架构设计方案1.音视频直播架构以上是腾讯云直播方案的架构图，其他云厂商（如阿里云）的直播方案技术架构类似。感兴趣的同学可以直接去腾讯云官网详细了解，这里就不展开了。2、数据推流方案音视频推流采用腾讯云的直播推流方案，业务数据推流（活动、问答、弹幕、红包等）采用自研长连接方案。架构图中的答题系统和答题操作后台也是自研的。客户端会分别处理两个通道的数据，以控制用户交互的变化。三、基于TCP长连接的通信架构以上通信架构用于业务数据流的传输，流程如下：1.客户端使用websocket与服务器通信，用户进入时建立连接直播间回答问题，退出直播间时间中断打开连接。2.Nginx负载均衡websockets。3、TCP网关是基于netty实现的。用于维护长连接和转发业务请求。它不负责具体的业务逻辑。它通过RPC接口与底层业务系统（应答系统）进行交互。主要考虑是以后其他业务可以复用TCP网关。层，所以业务会降低。客户端和网关之间的心跳机制保证连接的有效性，检测僵尸连接。4、消息推送（如弹幕、问题发布、答案公布等多种场景）由底层业务（答题系统）通过MQ通知给TCP网关，再由TCP网关推送给客户端。4.长期连接通信中数据传输格式的定义通信体系结构中另一个重要的事情是数据传输格式的定义。protobuf格式用于客户端和TCP网关之间，以及TCP网关和应答系统之间。下面分别说说几种关键格式定义。4.1客户端请求报文格式1.报文类型标识：-1表示心跳报文，0表示用户认证报文，>0表示业务报文2.用户ID：用户的唯一标识，已经在pre中获得-登录流程3.Token：用户登录APP后的授权token，在登录前流程已经获取到4.BizData：真正的业务数据，protobuf序列化的字节数组，底层业务自己定义了更具体的格式4.2Customers终端响应消息的格式1.消息类型标识：与请求中的消息类型一致2.状态码：0表示处理失败，1表示处理成功3.BizData：真正的业务数据，如果状态码为0，则该字段为4字节的异常码（100表示??token校验失败，101表示向业务层请求失败）。如果状态码为1，则该字段为业务层返回的protobuf序列化后的字节数组，也是下层业务自己定义的。具体格式4.3业务数据的ProtoBuf格式定义1messageMes??sage2{3MessageTypemessageType=1;//消息类型，枚举值4stringsequence=2;//消息序号6Requestrequest=3;//请求消息7Responseresponse=4;//响应消息8Notificationnotification=5;//推送消息9}这里的格式设计的还是挺巧妙的。Request、Response、Notification三种类型的消息，通过Message顶层消息进行封装，定义一个MessageType枚举值来表示消息类型。sequence字段表示消息的唯一序号，需要在发送方内部唯一，以便发送方收到Response后进行匹配处理。通过以上统一的消息格式，应答系统可以为不同的MessageType定义不同的消息处理器，配置映射关系后，就可以实现消息路由。五、系统总体架构1、网关层：该架构同时采用了TCP网关和HTTP网关。TCP网关在上一章已经解释过了。主要用于维护百万用户同时在线，答疑时的实时数据交互（包括加入直播间、推送问题、答题、推送答案、抢红包、弹幕推送等。).HTTP网关为APP端提供Restful接口，用于低频数据请求，如赛事首页、排行榜、个人奖金明细、新人邀请、分享等场景。2、问答系统：核心业务服务Dubbo实现，为C端和B端系统提供RPC接口，包括事件管理、题库管理、直播间管理、C端高并发接口（比如加入直播间、答题、抢红包等）。本集群使用了很多高并发设计的常用方法：比如服务的水平扩展能力、多级缓存、异步化、限流等，后面的章节会详细介绍。另外，MQ的交易消息+对账机制保证了资金流向在应答系统和余额系统中的一致性。3、答疑运营系统：后台系统，供运营商和场控人员在直播时使用，可以管理活动和问题，以及直播期间的各种业务操作（如配合主持人口述发布问题和发布答案）、红包等）。6、部署架构在线用户数和直播答疑并发量远超商城交易系统。为降低对主交易流程的影响，采用上述“私有云+公有云”混合部署方案，自建机房与云机房通过网络专线打通。直播答疑相关的应用服务器、存储服务器、网络带宽都在云端，可以根据流量监控快速扩容。随着运营计划的调整，服务器也可以随时增减，灵活性高。七、答题系统高并发设计方案7.1答题界面高并发设计方案答题界面并发量预计为20WQPS。在说设计方案之前，先简单罗列一下接听界面的判断逻辑：1.需要判断接听活动是否还在进行中2.需要判断用户是否答错了，出局了游戏的。3、需要判断用户输入的问题是否为当前正在回答的问题。4、需要判断用户上次的正确答案是否与本题连续。已经超时6.需要判断用户的回答是否正确。7、如果答错，需要判断用户是否有复活卡。8.如果有复活卡，需要判断上一题是否使用了复活卡。除了上面的判断逻辑，还有一些写操作，比如更新每个答案选项的选择人数，更新用户的正确答案数或出局题数，更新复活的使用记录卡片等。一般来说，答题就是一个读多写少的界面。为了应对高并发，我们采用了以下技术方案：1、接听接口的所有逻辑只操作缓存，不操作数据库。采用WriteBehindCaching的更新方式（即只更新缓存，回答完问题后异步批量更新数据库）。2、多级缓存：本地缓存+Redis缓存。同时，在问答活动开始之前，活动的配置信息、问题、答案等所有静态数据都会被预热到本地缓存中。3、Redis一主多从+哨兵的部署架构保证了高并发和高可用。同时配置多组Redis实例（用户、弹幕、直播答题、奖励榜），供业务模块进一步分发。4.调整判断逻辑顺序。上面说的8个判断逻辑，前4个属于安全验证，因为客户端已经通过交互拦截了。如果用户不使用作弊手段，验证肯定会通过。所以我们把第5、6、7步的逻辑放在前面，通过之后再进行前4步的验证，这样就大大减少了计算量。7.2推送答题结果的设计方案如何在主播播答的那一刻，将答题结果推送给数十万答题用户？因为用户的回答结果有很多种状态：有正确答案和错误答案，有使用复活卡的和没有使用复活卡的，还有出局的。状态推送。为了解决这个并发计算问题，我们采用了一个比较巧妙的设计方案，将有状态推送转化为无状态推送：1.答案结果的计算在用户提交答案时同步完成（上文第1节），相当于将瞬时的计算压力分配到10秒的答题时间内。2.用户的回答结果也是在步骤1计算完成后立即推送给用户。无需等待主持人播报答案的那一刻。否则，仍然涉及并发读取应答结果和有状态推送，会影响存储服务器和带宽的一时压力。3.但是如果提前把回答结果推送给客户端，肯定存在安全问题。黑客通过抓包可以提前知道答案是否正确，可以利用批号进行作弊。为了解决这个问题，我们采用XOR对答案结果进行对称加密，同时延迟秘钥的发布，直到公布答案的那一刻，随机生成每道题的秘钥。这样就很好的解决了安全问题。4、在发布答案的那一刻，我们只需要向客户端推送一个很小的数据包，这个数据包对所有用户都是一样的。7.3抢红包界面高并发设计方案当红包下雨到屏幕上时，用户触摸屏幕时红包会直接被拆除，所以抢红包界面的并发度非常高，而且单个用户可以在1秒内通过触摸屏发起4-5次抢红包请求，按照百万用户在线，最高并发可达百万级QPS，技术方案如下：1.红包数量为预先计算并加载到redis：创建活动时，运营商可以配置红包总量和红包总数创建活动时，系统会预先计算每个红包的数量并存储在redis中，相当于预计算。2、客户端限流：在设计接口的时候，我们预先埋下了一个限流因子参数，可以让服务端动态控制客户端的限流比例。在通知客户端抢红包的界面中，我们根据当前在线用户数和红包总数动态计算限流因子，这样最多只能发送10WQPS的请求到服务器。3、服务器端限流：根据服务器数量和红包总数提前计算出每秒产生的token数量，基于Guava的RateLimiter进行二次限流。4.前三步基本降低并发，然后使用lua脚本保证原子性。抢红包的结果也会在活动结束后异步刷新到数据库。7.4其他针对高并发的优化点1.Redis缓存的对象要尽量精简（不要存放不用的字段），key的长度尽量短（高并发下的瓶颈在IO），并善于使用管道组装多个Command（但command数量不宜过多）2.各种连接池和JVM参数的调整：涉及redis连接池、dubbo线程池、JVM内存大小，合理取值可以在压力测试环境中找到。3、答题系统可以水平扩展（scaleout），同时通过dubbo的分组配置将ToB和ToC接口隔离部署，避免相互影响。最后简单总结一下直播架构：1.音视频编码传输，这些基本的直播功能，除非公司有钱有实力，否则建议直接使用腾讯云或者阿里云（斗鱼）的解决方案、蘑菇街）这些知名的直播应用也使用了腾讯云）。2、架构设计着眼于应用本身，首先根据直播应用的用户层级和业务特点，确定通信架构（长连接或短连接，或两者混合）。3、根据业务高峰进行方案设计。如果是高并发场景，应该把高并发看做一个系统性的问题：从客户端到服务端，从网络带宽到部署架构，甚至产品设计。考虑，挖掘各种细节。
