冲顶大会APP技术选型及架构设计

我在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,不会超过一个星期。我们拭目以待吧。

本文欢迎注明出处的转载,但微信转载请联系公众号:caiyongji进行授权转载。

相关文章
相关标签/搜索