千万级用户App小咖秀：服务端架构设计分享

摘要 小咖秀的张华伟带来的分享是在移动互联网时代，创业团队在技术储备、经验积累以及资金等有限的情况下，怎样选择合适的服务端技术解决突发式流量增长所带来的压力以及最大化节省运营成本等方面的经验和建议。同时也对划分URL目录，合理使用缓存等问题给出自己独特的答案。

3月18日云栖社区在线实时分享顺利结束，本次由小咖秀技术总监张华伟分享了分享是在移动互联网时代，创业团队在技术储备、经验积累以及资金等有限的情况下，该如何选择合适的服务端技术解决突发式流量增长所带来的压力以及最大化节省运营成本等方面的经验和建议 。本次视频直播的整理文章、视频、幻灯片整理完毕，如下内容。

爆款产品特点

图一　爆款产品的特点

爆款产品的特点十分明显。首先其团队规模较小，资金少，在未得到风险投资前，花的都是创始人的钱，因此要做好规划；同时产品上线初期用户量较少，但用户增长速度快，指数级的爆炸式增长，如果初期的架构设计不合理，会导致后期该产品的崩溃，无法使用；爆款产品一般都是“现象级应用”，后期用户容易审美疲劳，进入稳定期。如果继续采用高峰值的服务器、网络带宽配置，势必导致资源浪费。

图二　高可用系统设计要点

基于爆款产品的上述特点，因此在搭建其系统时要注意架构设计的高可用性。首先系统应该做到集群化设计，无单点，并且需要支持纵横扩容。即使初期整个系统部署在物理机上，也需要有这个理念，以保证后期压力增加时，能快速拆分、扩容。同时要注意系统可模块化拆分，可拆成单独的子系统，子系统之间可通过服务化方式组合。此外数据存储应做到持久化存储，研发人员通过修改配置或者加数据库中间件可以灵活地将每一个模块的数据库、数据表单独拆分到不同的物理机上，做到数据的灵活调配。与此同时，系统还需要尽可能利用缓存，互联网产品中，缓存的重要性不言而喻，通过缓存，可以减轻后端的数据库的压力。在系统设计中，将耗时操作异步队列化，可以提升业务集群的吞吐量，数据的容错率也随之提高。如果系统设计之初不考虑上述情况，后期用户量增长时，需要进行停机维护。

系统模块化拆分

图三　系统模块化拆分

上图是系统模块化拆分过程，按功能将系统拆分成负载均衡、URL路由、业务处理集群、缓存集群、数据库集群五层，按模块路由。URL路由按地址将不同的功能拆分成不同的模块，每个模块后面都有单独的业务集群、缓存集群和数据库集群。

图四　URL分层

上图案例中URL分层可分为用户、评论、视频、图片四个模块，这里的分层方式是根据二级目录划分，在后期可以通过路由将不同的功能模块划分到不同的集群上，这里之所以采用二级目录划分而非二级域名，是因为二级域名数量过于庞大。

图五　功能独立的模块化

每个业务集群设计时需要将独立功能进行模块化设计，每一个小的模块单独出来就是一个子系统，比如评论，本身就具有自己的缓存和数据库，并且在设计之初，就已经考虑数据库的分库分表。上图的四个业务模块对应于URL的四个分层，中间的系统API类似总线功能，其不处理业务逻辑，主要用于模块间交互。持久化耗时业务进行队列任务化，用来减轻并发的压力。系统内部交互非常频繁，每个模块之间通过内部API进行封装调用，将结果反馈给前端用户，同时数据库做到分库分表，不同数据库根据业务模块的特征、压力配置进行读写分离。

小咖秀云服务结构

图六　小咖秀云服务结构

上图是小咖秀在云服务上的部署结构。小咖秀架构最初就是依赖于阿里云搭建而成，从开始的一台云服务器扩展到现在的接近一百台服务器的规模。云服务架构的最前端采用负载均衡，可以通过流量分发扩展应用系统对外的服务能力，通过消除单点故障提升应用系统的可用性。中间是URL分发路由，内部的子系统通过ECS服务器搭建PHP集群。缓存部分分为一级缓存和二级缓存两个部分。一级缓存主要通过云Memcached搭建，二级缓存是在ECS部署的Redis搭建而成。最后端是数据库集群，开始阶段是采用自建的MySQL数据库。后期从自建MySQL迁移到RDS上，迁移中通过DPS热切换，切换时间仅用了几十秒的时间，并且迁移过程中没有停机。

在该架构中采用了多种缓存方式，其中Redis可以用于存储多种数据类型，但由于Redis本身是单进程单线程的，I/O和CPU与物理机相比还有一定的差距，所以导致在并发量高的情况下，压力较大。因此架构设计的巧妙地将大量的Key -Value请求全部转移到云Memcached上。同时考虑到ECS的I/O瓶颈，目前Redis集群采用主备方式，将写等持久化操作放在从库上，从库不用与对外提供服务，单独用于持久化操作。这样做目的一方面是可以进一步缓存数据库的压力，另一方面如果缓存集群崩溃时，可以Sliver切换为主库，快速实现产品上线。根据模块的功能、压力不同，个性化调整数据库采用RDS主从模式。云服务不同于物理机，开发者需要根据云服务的特性，适当调整程序部署，配置来做优化。

云应用的关键指标

从物理机刚开始切换到云上需要一个适应过程。首先内网流量不能再像之前使用物理机那样随意使用，具有一定的上限。另外网卡过包量也是一个很关键的指标。磁盘I/O，云磁盘的I/O相对于物理机还是有一定差距。最初，小咖秀系统架构中将PHP程序部署普通云磁盘上，后期将PHP代码迁移到内存之中。这样的操作之后，系统运行时无需提取磁盘内的内容，加上PHP本身的内存优化，得到性能的大幅度提升。在使用RDS需要注意IOPS和连接数两个指标，两者受限于本身购买的资源配额、实例的大小。小咖秀初期在不确定业务量的情况下，先从最小化开始购买，逐步根据压力情况适当调配，升级一个实例配置的时间仅需几秒时间，可实现热升级，过程十分平滑，即使出现闪断，闪断时间也仅在几秒钟之内。

图七　云服务应用关键指标

在使用云服务过程中，应注意其关键指标变化情况。上图显示的是云服务应用的部分实时关键指标图表，最上面是对数据过包量的监控，通过对数据过包量的监控，可以观察影响系统的访问速度的因素。左下角是当前RDS实例IOPS使用量，从表格中可以看出，其峰值趋于稳定状态，中间突发高峰值是系统完成一次任务产生的。右下角显示的是链接数，当有任务执行时，峰值也仅在200左右，整体来看非常平滑，这得益于前期的结构分层、分模块、缓存优化。

图八　云Memcached实例监控

上图是使用云Memcached时的实例监控，最开始缓存的命中率达到98%左右，经过数据过期等优化后，目前在90%左右，目前仍在不断优化。在云Memcached重点关注的QPS指标，在峰值的时候可以接近20万左右。

初创团队采用云服务，在技术支持和成本控制上可以获得一定程度上的帮助。例如小咖秀在7月底遇到系统瓶颈时，阿里云技术团队给予了很大的帮助，极大的降低了系统自建时间、人力成本，确保产品的正常运行。此外云服务的高稳定性，也减轻了运维人员的压力。

QA环节：

1、作为架构设计师，在设计架构时最为重要的一点是？

答：最为重要一点系统一定要支持纵横扩容，可以拆分。比如你设计了一个很好的系统，但只能部署在一台机器上运行，某一天压力上来后如果不能进一步拆分，那整个系统就无法承载更多的业务量，就毫无意义。

2、优化应该是系统开发哪一个阶段进行考虑？

答：对于快速上线的产品，前期需要有优化的理念，设计时要有所预留。如果开发团队很小的情况下，可以先快速上线，上线后逐个模块进行优化，优先优化核心模块。

3、小咖秀在涉黄、防护攻击方面对应的措施？

答：事实上，在小咖秀最初运行时也遭遇过几次攻击。最初小咖秀的负载均衡是自行搭建的，后来将负载均衡迁移到阿里云的SLB上。鉴黄方面，小咖秀将视频和图片通过鉴黄系统进行打分分值较高的直接屏蔽，分值中间段的，通过后台人员重点关注审核。

4、目前小咖秀的运维人员有多少？

答：目前专职运维人员只有一人，系统级的监控是自己搭的监控平台；服务方面的方面依赖于云监控，因为云监控目前比较成熟。

5、PHP服务器具体使用的是那种框架？

答：小咖秀核心业务服务器都是PHP实现的，框架是我们自己开发的一套MVC框架，比较轻量级，没有开源。

6、请问读写分离是如何实现的？

答：小咖秀底层数据库操作驱动使用PHP封装过，直接支持分表分库和主从分离操作，这个用数据库中间件就可以实现。

7、PHP代码放到内存是如何实现的？

答：可以把PHP代码复制到/dev/shm目录中，符合连接到应用配置目录就可以。需要注意的是/dev/shm目录只能使用物理内存50%的空间。

直播视频：

点击图片观看

幻灯片下载地址： https://oss.aliyuncs.com/yqfiles/9a8fc5f636a0151d678e125f0e63678f.pdf

关于分享者

张华伟，小咖秀技术总监

小咖秀App于2015年5月份上线，最初只推出了IOS客户端的单机版，但用户留存达到60%以上。在持续的人力和技术投入下，于该年6月份推出带服务的版本。7月27日登顶App Store，雄踞榜首长达一个月。小咖秀引爆了中国对嘴型飙演技的浪潮，并从高端的娱乐圈走进大众的日常生活中流行开来，引领2015年视频领域的潮流。

转自：https://yq.aliyun.com/articles/8530