更多云场景实践研究案例，点击这里：【云场景实践研究合集】联合不是简单的加法，而是无限的生态，谁会是下一个独角兽
在移动互联网时代，创业团队在技术储备、经验积累以及资金等有限的情况下，该如何选择合适的服务端技术解决突发式流量增长所带来的压力以及最大化节省运营成本是一个非常值得思考的问题。而具有千万用户的爆款APP小咖秀在最初就是基于阿里云搭建而成，从开始的一台云服务器扩展到现在的接近一百台服务器的规模，而专职运维人员却很少，这是因为其系统级别的监控使用自己搭建的监控平台，而服务方面则依赖于阿里云的成熟的云监控。
“初创团队采用云服务，在技术支持和成本控制上可以获得一定程度上的帮助。例如小咖秀在7月底遇到系统瓶颈时，阿里云技术团队给予了很大的帮助，极大的降低了系统自建时间、人力成本，确保产品的正常运行。此外云服务的高稳定性，也减轻了运维人员的压力。”
——张华伟
小咖秀技术总监
采用的阿里云产品
- 阿里云云服务器 ECS
- 阿里云云数据库 RDC
- 阿里云云数据库 Memcache 版
为什么使用阿里云
爆款产品一般都是“现象级应用”，后期用户容易审美疲劳，进入稳定期。如果继续采用高峰值的服务器、网络带宽配置，势必导致资源浪费。
小咖秀初期在不确定业务量的情况下，先从最小化开始购买，逐步根据压力情况适当调配，借助阿里云，升级一个实例配置的时间仅需几秒时间，可实现热升级，过程十分平滑，即使出现闪断，闪断时间也仅在几秒钟之内。
关于 小咖秀
小咖秀App于2015年5月份上线，最初只推出了IOS客户端的单机版，但用户留存达到60%以上。在持续的人力和技术投入下，于该年6月份推出带服务的版本。7月27日登顶App Store，雄踞榜首长达一个月。小咖秀引爆了中国对嘴型飙演技的浪潮，并从高端的娱乐圈走进大众的日常生活中流行开来，引领了2015年视频领域的潮流。
为什么选择阿里云？
打造爆款产品对于架构设计的硬性需求
爆款产品的特点十分明显。首先其团队规模较小，资金少，在未得到风险投资前，花的都是创始人的钱，因此要做好规划；同时产品上线初期用户量较少，但用户增长速度快，指数级的爆炸式增长，如果初期的架构设计不合理，会导致后期该产品的崩溃，无法使用；爆款产品一般都是“现象级应用”，后期用户容易审美疲劳，进入稳定期。如果继续采用高峰值的服务器、网络带宽配置，势必导致资源浪费。
基于爆款产品的上述特点，因此在搭建其系统时要注意架构设计的高可用性。首先系统应该做到集群化设计，无单点，并且需要支持纵横扩容。即使初期整个系统部署在物理机上，也需要有这个理念，以保证后期压力增加时，能快速拆分、扩容。同时要注意系统可模块化拆分，可拆成单独的子系统，子系统之间可通过服务化方式组合。此外数据存储应做到持久化存储，研发人员通过修改配置或者加数据库中间件可以灵活地将每一个模块的数据库、数据表单独拆分到不同的物理机上，做到数据的灵活调配。与此同时，系统还需要尽可能利用缓存，互联网产品中，缓存的重要性不言而喻，通过缓存，可以减轻后端的数据库的压力。在系统设计中，将耗时操作异步队列化，可以提升业务集群的吞吐量，数据的容错率也随之提高。如果系统设计之初不考虑上述情况，后期用户量增长时，需要进行停机维护。
小咖秀系统模块化拆分设计
小咖秀系统模块化拆分
如图所示的是系统模块化拆分过程，按功能将系统拆分成负载均衡、URL路由、业务处理集群、缓存集群、数据库集群五层，按模块路由。URL路由按地址将不同的功能拆分成不同的模块，每个模块后面都有单独的业务集群、缓存集群和数据库集群。
URL分层
上图案例中URL分层可分为用户、评论、视频、图片四个模块，这里的分层方式是根据二级目录划分，在后期可以通过路由将不同的功能模块划分到不同的集群上，这里之所以采用二级目录划分而非二级域名，是因为二级域名数量过于庞大。
功能独立的模块化
每个业务集群设计时需要将独立功能进行模块化设计，每一个小的模块单独出来就是一个子系统，比如评论，本身就具有自己的缓存和数据库，并且在设计之初，就已经考虑数据库的分库分表。上图的四个业务模块对应于URL的四个分层，中间的系统API类似总线功能，其不处理业务逻辑，主要用于模块间交互。持久化耗时业务进行队列任务化，用来减轻并发的压力。系统内部交互非常频繁，每个模块之间通过内部API进行封装调用，将结果反馈给前端用户，同时数据库做到分库分表，不同数据库根据业务模块的特征、压力配置进行读写分离。
小咖秀基于阿里云的系统架构设计
小咖秀基于阿里云服务结构
如图所示的是小咖秀在云服务上的部署结构。小咖秀架构最初就是依赖于阿里云搭建而成，从开始的一台云服务器扩展到现在的接近一百台服务器的规模。云服务架构的最前端采用负载均衡，可以通过流量分发扩展应用系统对外的服务能力，通过消除单点故障提升应用系统的可用性。中间是URL分发路由，内部的子系统通过ECS服务器搭建PHP集群。缓存部分分为一级缓存和二级缓存两个部分。一级缓存主要通过云Memcache搭建，二级缓存是在ECS部署的Redis搭建而成。最后端是数据库集群，开始阶段是采用自建的MySQL数据库。后期从自建MySQL迁移到RDS上，迁移中通过DPS热切换，切换时间仅用了几十秒的时间，并且迁移过程中没有停机。
在该架构中采用了多种缓存方式，其中Redis可以用于存储多种数据类型，但由于Redis本身是单进程单线程的，I/O和CPU与物理机相比还有一定的差距，所以导致在并发量高的情况下，压力较大。因此架构设计的巧妙地将大量的Key -Value请求全部转移到云Memcache上。同时考虑到ECS的I/O瓶颈，目前Redis集群采用主备方式，将写等持久化操作放在从库上，从库不用与对外提供服务，单独用于持久化操作。这样做目的一方面是可以进一步缓存数据库的压力，另一方面如果缓存集群崩溃时，可以Sliver切换为主库，快速实现产品上线。根据模块的功能、压力不同，个性化调整数据库采用RDS主从模式。云服务不同于物理机，开发者需要根据云服务的特性，适当调整程序部署，配置来做优化。
云应用的关键指标
从物理机刚开始切换到云上需要一个适应过程。首先内网流量不能再像之前使用物理机那样随意使用，具有一定的上限。另外网卡过包量也是一个很关键的指标。磁盘I/O，云磁盘的I/O相对于物理机还是有一定差距。最初，小咖秀系统架构中将PHP程序部署普通云磁盘上，后期将PHP代码迁移到内存之中。这样的操作之后，系统运行时无需提取磁盘内的内容，加上PHP本身的内存优化，得到性能的大幅度提升。在使用RDS需要注意IOPS和连接数两个指标，两者受限于本身购买的资源配额、实例的大小。小咖秀初期在不确定业务量的情况下，先从最小化开始购买，逐步根据压力情况适当调配，升级一个实例配置的时间仅需几秒时间，可实现热升级，过程十分平滑，即使出现闪断，闪断时间也仅在几秒钟之内。
云服务应用关键指标
在使用云服务过程中，应注意其关键指标变化情况。上图显示的是云服务应用的部分实时关键指标图表，最上面是对数据过包量的监控，通过对数据过包量的监控，可以观察影响系统的访问速度的因素。左下角是当前RDS实例IOPS使用量，从表格中可以看出，其峰值趋于稳定状态，中间突发高峰值是系统完成一次任务产生的。右下角显示的是链接数，当有任务执行时，峰值也仅在200左右，整体来看非常平滑，这得益于前期的结构分层、分模块、缓存优化。
云Memcached实例监控
上图是使用云Memcache时的实例监控，最开始缓存的命中率达到98%左右，经过数据过期等优化后，目前在90%左右，目前仍在不断优化。在云Memcache重点关注的QPS指标，在峰值的时候可以接近20万左右。
关于小咖秀的更多实践详情：千万级用户App小咖秀：服务端架构设计分享
原文发布日期：2016-03-20
云栖社区场景研究小组成员：贾子甲，仲浩。
