转自：https://zhuanlan.zhihu.com/p/32637387
我在1月4日看到虎嗅推送”王思聪撒币”的消息，然后开始推敲背后技术。其中涉及直播流、实时弹幕、OAuth2.0开放授权、SMS api、Push网关、支付接口等业务，其技术实现并不复杂，我们对此进行剖析。
UI设计
可以说冲顶大会是照搬HQ的商业逻辑、业务逻辑和UI设计。想必在短期内会有更多的知识问答APP蜂拥出现。对此我不做过多评论，只说背后的技术实现，无关商业。
Flutter
可以说我是谷歌的脑残粉，据传言Google的Fuchsia OS UI都是用Flutter设计的，在这里，Android和IOS的适配都可以使用Flutter实现。具体设计可以完全模仿HQ。
业务逻辑
冲顶大会类APP的技术难点在于高并发和时效性。为此我们要对业务进行解耦合，将注册/登录、直播、弹幕、问答、奖池、推送、分享全部进行业务分离，这样有助于业务拓展，保证高并发以及后续维护问题。
其中主要的业务难点和重点在直播、弹幕、问答。直播和弹幕是主要的流量出口，将其分离有助于保证高并发和时效性。
直播
企业可以自行搭建直播服务，当然也可以购买云服务。假设这里选用阿里的视频直播服务。直播环节将视频流编码传输、转码、加速后推送数据流到客户端。
弹幕
弹幕可以做成简单的request请求方式，也可以使用消息队列。当然消息队列也可以选取云服务，但这里我们使用kafka，部署到服务器集群上进行负载均衡。对于网速较低的用户我们可以默认关闭弹幕功能，以增强用户体验。关于高并发和时效性，我们后面再谈。
问答
问答环节作为用户最相关的业务逻辑，我们要保证用户”秒级”接收消息，这里可以应用一个小技巧，即”同步推送，异步反馈”。也就是说，主持人在说出题目后由单一服务器进行问题推送，但考虑到用户的网络情况存在不同延迟，我们可以异步接收用户的答题结果，我们可以将异步反馈的最大时效设计为10s、15s。
其他业务
注册/登录：调用微信OAuth 2.0开放授权。具体参考微信开放平台接口文档，这里不在赘述。 奖池：在问答环节结束后进行统一分配，业务简单，不在赘述。调用支付宝提现接口。 推送：可以使用push网关，也可以使用http轮询，也可以使用云服务。 分享：调用各平台分享接口即可。
高负载
我建议分别在北京、上海、香港进行负载均衡服务器的假设，北京服务北方用户，上海服务南方用户，香港服务港澳台以及海外用户。技术上使用hadoop、zookeeper、docker、nginx等。
对于不同地理位置的用户IP，需要进行DNS解析，进行流量自动分发和适配。我们设置可以针对用户的地理位置不同而进行弹幕的分区域显示。 使用cdn加速。
运营
可以说每一次直播都是一次运营，因为有”主持人”因素，所以问答推送和答题结果都是需要”手动”控制的。 具体操作是在直播前准备题目，并且将题目录入数据库，或者某个配置脚本中。在主持人互动过程中，进行实时题目推送，并将答题结果反馈到主持人。
最后
我们排除人力成本和奖金成本，单独计算技术成本。单次问答直播大概20min，我们以10G流量峰值每天进行试算，大概每天的技术成本是1万元。当然，这是在用户数量达到一定规模之后。在互联网行业，这并不高。所以，在短时间内，一定会有大量的知识问答APP问世。
本文只在整体角度考量技术实现，并未涉及过多细节。但对于一些有经验的公司，特别是直播类公司，我想做出这种APP，不会超过一个星期。我们拭目以待吧。
原文链接：https://www.cnblogs.com/isabelle/p/8278228.html
原创文章，作者：优速盾-小U，如若转载，请注明出处：https://www.cdnb.net/bbs/archives/1507
