本文正在参加“最佳上云实践”评选，来给我们投票吧：（编号34）
2015年7月，video++开放平台面向市场，旨在为视频平台提供视频内AI和互动系统的技术，一些中小型平台开始陆续接入我们的服务。
起初，我们采用的是国内某家云厂商，但是随着公司不断发展，对云的要求也越来越高，单纯的一个云主机已经不能满足我们的需求。随着接入我们技术的平台流量不断增大，当时用的某云厂商的产品线的不足的问题也开始暴露出来。这个时候我们也开始接触了阿里云的产品，发现阿里的各个产品都是数据打通的，可以相互串联起来，形成一个闭环的生态。此时，由于业务的快速增长，我们也希望公司可以把更多的精力投入到业务产品研发中，而不是基础设施建设中。
2016年春节前后，芒果TV的爸爸去哪儿节目开播，全面启用了video++的视频互动产品服务。当时节目的月播放量突破十亿，周末峰值时间的视频内互动并发破百万。因为流量和并发数突增数十倍，系统开始出现严重异常，各种接口不通，导致芒果tv灵犀互动有将近十几分钟的响应异常和素材错误，经过排查，发现负载均衡带宽被打满，另外redis缓存过载，部分请求击中到mongodb数据库，后续我们立即优化了缓存策略，避免再次出现这种风险。后续我们的产品又新增了海量推送的需求，发现目前所用的某云厂商没有成熟的mqtt消息队列产品，对我们来说迫在眉睫的弹性伸缩产品也还没上线。综合这些原因，我们终于开始考虑要更换云厂商了。
但是切换云服务商对任何一家技术公司而言都是伤筋动骨的大手术，所以我们还没有完全下定决心，而是先优化我们自己的业务架构，修改缓存策略、做二级缓存、添加从库、自建MQ服务器等多种手段来进行弥补，来先满足目前的用户需求，但是成本大，非常不灵活，流量低谷时形成巨大资源浪费。
2016年5月，在充分调研、测试和压测过国内外各大云厂商的产品和技术能力后，我们正式决定迁移到阿里云。我们利用了阿里云成熟的负载均衡，弹性伸缩，MQTT推送，而且这些都是按量付费，十分符合我们的业务场景。上阿里云一个月后，系统逐步稳定下来。2016年8月，我们的月播放量已经突破20亿，国内的主要直播平台也纷纷开始全面上线我们新发布的直播互动系统。而直播的互动需求远超点播，互动并发的峰值倍增也是非常明显的。即使是阿里云的MQ服务器也开始吃力起来，初期每次高峰前阿里云的同学都会配合我们应对高峰流量，当时直播在线用户峰值突破到100W，阿里云也支撑了下来。
另外，我们之前的日志搜集系统是采用flume+kafka,业务流量是波动的，flume和kafka的压力也是波动的，如果准备大容量的集群，会出现成本浪费，我们开始尝试了阿里的日志系统，替代了原有的架构，阿里的日志系统结合我们的docker部署，使用方便，功能多样，从日志采集到最终的大数据分析，形成闭环，而且无需考虑日志丢失和系统的吞吐能力，日志存储到哪里的底层实现，节省了运维成本和服务器资源成本，对于我们这种流量波动大，有弹性日志搜集的创业公司来讲，的确很方便。
2016年9月，在斗鱼、战旗、龙珠、熊猫陆续上线之后，全民直播也开始进行全平台上线的测试，上线当天实时在线数超过200万，阿里云的MQ服务也开始出现丢消息推送缓慢或推送不成功的现象，发生了迁移到阿里云之后的首次异常状况。值得欣慰的是，阿里云当天晚上就派出技术同学紧急修复和优化。紧接着，MQ的产品经理和开发同学也专门从杭州来到上海，与我们的技术团队当面讨论优化方案，并且很快落实，从此之后，我们的系统再也没有因为高并发而出现过异常。
阿里云让创业公司有了可以支撑海量并发的能力，帮助创业公司快速成长的时候，不用花精力投入到基础建设，创业公司再也不会由于系统的吞吐能力不足而流失用户了。在我们上到阿里云到现在近一年的时间里，这样的技术服务其实也并非偶然，阿里云的行业总经理宋涛，商务经理古莜、袖手，架构师空吾，以及十几位技术专家经常来到我们公司进行交流，答疑解惑，客户第一的服务意识贯彻的很好，也是我们需要学习的地方，往后也将继续携手阿里云，成为更好的Video++。
