本文正在参加“最佳上云实践”评选，来给我们投票吧：（编号21）

散落在网络中的神最右内容，每每看到都会眼前一亮，信息大爆炸的时代，找到有趣内容，找到合拍的小伙伴儿成为一件不易的事情。于是最右App诞生了。

最右App是青少年的娱乐社区，用户主要集中在学生群体，他们喜欢消费有趣的、互动性高的内容。最右App将散落于网络中的有趣内容聚集起来，提供一站到达式服务，为生活增添乐趣，用户可以分享、记录自己的生活。

上云之路

最右App开始就选择了阿里云服务，其当时选择云厂商时的标准：首先，阿里“背书”对最右的吸引力比较大，不论是淘宝还是早期的阿里巴巴，其技术能力都比较强；考虑稳定性、产品的质量和标准，应用性要好、成本低，并且对提供所需基本功能的完整性有一定的要求。

由于阿里云提供的云产品服务比较多，在上云前，首先需要了解这些云产品，把关自己的业务。不同的业务对技术的需求不同，根据自己的业务、云服务商提供的产品、对云基础产品的技术内幕的理解，综合考虑选择一款适合自己的云产品。

架构演进

早期由于用户比较少，服务的对象比较少，所以架构比较简单。当业务量增加之后，相互之间的混合性会导致一个服务的服务能力会严重影响另外一个服务的服务能力。这时候就考虑到把服务进行拆分，以内部服务的方式对接入层提供数据支持。

接入层通过数据的封装、合并对外提供数据支持、接口。明显的优势是可以对独立的服务进行能力扩充，对其提供的能力变得更加灵活。接入层整体是分层的结构，可以做数据缓存、预处理、压缩，提交给用户相对精简的数据包，提升用户解析、显示的体验。

这里遇到的一个问题是：从单服务向微服务过度时，需要经历服务解耦的过程。这就需要重新对架构进行梳理，将所有服务解耦，实现微服务架构对所有服务的拆分。

其中，阿里云的帮助如下：

• 以前可以通过MySQL或者日志做简单的分析操作，当数据量越来越大时，需要用到阿里云的大数据支持服务，比如ODPS；
• 数据量提升到一定规模之后，需要考虑的不仅仅是处理时间，还会出现一些新的问题，比如需要通过大数据去挖掘用户的一些行为，对数据的处理能力有了新的要求，此时用到了阿里的MapReduce和Hadoop的服务加速了推荐系统的开发。

移动加速实践

一款App，加载速度至关重要。我们在提升最右App移动用户的加载速度上也投入了很多精力。

• 首先，需要架构上的提升，早期是独立的一个服务，随着业务的提升，各种服务会拆分出来，形成了微服务架构。
• 同时，将服务做分层（接入层、底层的服务层），通过不同分层的协调和平行扩展提高并发能力，同时加上两个多级缓存对比较热的帖子、评论缓存到访问速度更快的内存里面，使用多级缓存以及精细控制缓存力度来解决用户对于数据的访问需求。
• 视频和图片资源会用到CDN服务，快速地通过边缘节点到达所要显示的内容，有效提高用户端的产品服务体验。并且，在系统架构的时候消除单点，保证服务都是可扩展。

我们也结合了阿里云在移动加速的解决方案，比如阿里云在协议方面的优化，最开始在sbity协议上做了开发，包括多路复用、长链接、请求头部压缩、最小化TCP连接。然后是链路的优化，比如源站用了ECS产品，那么CDN的节点回源过程中有专线，回源速度上有优化。最后是内容的优化，针对静态的资源有智能压缩，另外有合并请求的功能。

云上安全

作为一款内容型产品，最右App会面临恶意抓取，目前最右App采用了一套签名机制，使得恶意抓取受到了一定的控制。至于常见的DDos攻击，则使用阿里云的云盾进行阻挡。

作为一款UGC类型的App产品，最右App也面临着图片鉴黄识别等问题。最右App目前通过三种方式鉴别垃圾、广告、黄色内容：首先，确认规则系统，通过规则的判断减少垃圾内容的产生；但是机器的最大问题是存在漏判、误杀，所以有相应的运营团队对漏判和误杀的情况进行纠正；同时，结合用户反馈机制，当用户反馈量达到一定的数量时，对一些漏判和误杀进行纠正。

上云后的效果

落地阿里云最大的感受是人力成本大大减少了。以前有大量的运维，机房里有很多人做基础服务相关的保障，使用阿里云产品以后，在早期能做到零运维，开发团队只需要关注自己的业务，成本也非常低，尤其是早期的时候，资源消耗和配置都偏低，这样成本变得非常可控。更重要的是当业务发展的时候，扩大机器、提高配置变得相对容易，不需要和硬件供应商去打交道，这样可以把精力完全集中在自己的业务上。

早期使用云产品是零运维的，随着规模的增长，对于一个产品来说，如果要提升服务质量势必需要引入自己的运维团队，即从零运维转变为轻运维。