阿里云丰富而可靠的产品,保障上万视频平台客户的多样化的实时互动推送需求,大数据、弹性伸缩、Docker支撑这一年来业务指数级增长。

丰富产品体系

Video++,国内首家视频多维互动+内容识别技术提供商,以人工智能+成熟的产品架构为驱动,让视频平台实现在视频中的购物、百科、虚拟植入、卡牌互动、投票、发红包等互动功能。月均为11135家视频平台提供101亿次服务,月独立覆盖用户2.8亿,近30天视频播放量21.2亿。

我们业务开始早期是使用某家云服务器厂商的,他们也是非常优秀的。但随着业务发展,我们的视频播放量从每天百万量级很快突飞猛进到每日5000万量级,而且直播业务的峰谷效应,还有近乎变态的瞬间高并发都对云服务都提出了极其严苛的要求。因此我们迁移到了阿里云,看重的就是阿里云的丰富而可靠的产品。

问题1:由于接入我们技术的都是视频直播或者点播平台,突发流量比较多,而且我们又是服务这些平台,所以流量变化巨大,瞬间流量翻几倍是家常便饭,最终ESS能解决我们的问题。问题2:我们是服务平台的技术SaaS,所以平台的最终用户就是我们的用户,所以我们的用户规模就是平台用户的综合,经常出现大规模在线,然而我们又有对这些最终客户端实时推送消息的需求,如果自己搭建MQTT集群,会出现运维成本高,扩缩容不及时,突发流量不好应对的问题,最终ONS提供的MQTT服务解决了我们的问题,性价比和性能都很赞。

用了阿里云之后,业务高峰时,再也不需要去批量购买机器,然后批量部署服务,效率提升很多,业务流量下降时,可以自动释放,更好的利用服务器资源,节省成本。MQTT都是按量付费,比实际自己搭建集群,成本少了很多,而且还能抗更高的流量,非常灵活。而且阿里云的产品线非常丰富,我们已经将原有的日志搜集系统替换为阿里云的日志搜集,这样的例子很多。阿里云更像一个生态系统,你需要的各个组件都有,你只要根据自己的需要用你的code去组装即可,让用户更加专注于自己的产品。

架构图

使用场景

迫切需求:弹性配置,产品丰富

建议选用:

架构解读

  • 我们先对请求做了动静分离,然后先进入阿里云的SLB做分流,在进入我们自己的网关集群,根据用户的不同的请求,将流量转移到各个业务集群,我们的网关集群和业务集群都有组的概念,基于组的弹性伸缩,可以快速应对突发流量。
  • 缓存系统我们用了阿里云的Redis实例,涉及到强事务依赖的情况我们会用阿里云的RDS,事务需求不强的采用阿里云的Mongodb,我们的ECS上跑的都是docker,docker里面已经封装了阿里云日志服务的agent,可以自动实现日志的搜集,最终日志可以用于EMR大数据的分析和运维的监控。