看腾讯运维应对“18岁照片全民怀旧”事件的方案，你一定不后悔！

前言

2017年12月30日，元旦假期的第一天，你的朋友圈被18岁照片刷屏了吗？据说“晒18岁照片”的根源是2017年年未，最后一批90后将度过他们的18岁生日。这意味着，90后已全部成年，集体告别了青葱芳华。

这是一个青春的、也是怀旧的年华，QQ空间做为国内第一批社交平台产品，承载了较多的用户记忆，大量的用户涌入QQ空间翻找自己多年前的18岁照片晒上社交平台。集体引爆了空间相册山洪峰涌而至的照片流量。

下面这篇文章让我们回顾12月30日，空间相册面对突发三四倍流量，七成访问落在后端冷存储的极端压力下，相册运维、开发团队如何凭借平时基础功底，从告警、容量、扩容、柔性、调度等全方面运维能力，扛过“18岁照片”的全民怀旧事件。

业务数据回顾

突然来袭的用户集中行为，给我们平台的能力带来了非常严峻的考验，先让我们先来看一组数据：

图片下载量峰值达到平日晚高峰的4倍，且70%以上都聚集在平日不怎么访问的冷图片。
图片上传量达到平日晚高峰的4倍。
带图说说峰值达到平日晚高峰的12倍。

业务架构剖析

面对突然涌入的用户请求，相册开发与和运维是如何坚守阵地，度过这次难关的呢？

在介绍一系列的措施之前，首先不得不介绍下相册业务架构，下图较为抽象地介绍了相册的主要架构：

1. 上传链路：

用户上传图片/视频，数据流主要由上图中间链路处理，经过proxy->逻辑（分片、权限、缓存等）->存储接入（分片整合、生成文件地址等）->落地存储

2. 下载链路：

a) 用户通过空间（说说、日志、动态等）访问相册图片，图片适配模块根据用户请求、终端、请求量等场景适配出最优图片规格，返回用户图片、视频URL

b) 用户通过上一步获取的URL 访问后端存储的图片、视频。

日常运维工作

腾讯SNG运维团队会例行化地进行容量管理工作，包括：

1）链路梳理

如上节所述，我们梳理出相册核心链路，常用梳理过程有几种：

通过抓包形式确定链路模块；
通过设备上报的主被调数据确定调用链路；
名字服务中获取相关的调用链数据；
通过全链路数据汇总出相关的链路。

2）压测：

定期对整条链路做压测，压测手段有异地调度压测，或单机压测，通过压测找出链路内存在瓶颈的模块，及时修正链路模型。

3）高低负载处理：

依据压测容量数据，分配设备扩容。负载较低的模块设备进行缩容下线以节省成本。

容量应急措施

但是这里的问题是显而易见的：以上常规性的工作，只能发现常规场景下内部存在的瓶颈。像18岁照片这种特殊场景（用户大量读取空间相册，获取冷数据），无法通过常规压测检测出来问题, 这就需要一系列的机制来解决

1) 监控和容量弹性机制：通过IaaS层监控对系统的基础特征进行监控，（如CPU负载，出入流量），当模块容量出现异常时，弹性扩容机制需要介入处理，进行扩容。

如何快速支持短时间扩容上千台设备？不得不介绍下腾讯SNG的织云运维理念。

如上文所述，我们的设备被分配到不同的“业务模块”，而每一个模块有如下属性：

包：业务处理逻辑文件包，包含业务包与基础包。
配置：包含业务包要使用到的各种配置
权限：包含支撑业务包正常运行时需要的数据库、内部鉴权系统等权限
测试工具：包含业务包启动后，能否接入现网的测试标准

织云提倡的自动化理念是：标准化 -> 配置化 -> 自动化，让企业的常用操作固化成流程工具。不依赖容易过期的文档，不依赖容易流失的人的经验。

参考持续交付的原则“为软件的发布创建一个可重复且可靠的过程”，运维团队为了解决人肉操作经验差异的难题，将运维操作通过流程DIY编排能力，实现标准操作的固化。“18岁照片”活动扩容，任何一个运维人员只需要执行QQ相册的扩容功能即可实现容量扩展，而织云流程会自动化的完成整个服务部署和上线的操作。（如下图）

柔性业务架构

前面我们说过，相册在当天的峰值下载量涨了4倍，且多是访问冷数据，但在短时间内无法筹集到4倍的资源，业务是如何应对的呢，在保证用户核心体验不受影响的前提下，我们采用了一些柔性手段。

回顾一下，当时我们在容量不足时碰到以下的问题，导致短时间内部分图片拉取耗时过长，影响用户体验。

1）存储压力过大。

2）自身模块压力过大。

针对存储压力过大的问题，我们采用了以下几个手段来降低业务负载：

1）存储手段

图片适配优化索引策略减少存储压力

减少拉取照片分批次数，降低后端存储处理压力。分批拉取照片列表数量增加3倍。交互次数直接下降近2/3。

图片上传增加本地缓存空间减少存储高负载造成的用户上传失败：

调整上传逻辑模块，从原来的本地内存缓存优化为内存+本地磁盘缓存，通过增加本地缓存空间减少后端存储高负载对用户侧上传图片/视频的影响。虽然底层存储高负载了，但是用户还是可以不受底层影响，将图片通过接入上传到逻辑层缓存。存储压力释放后即可将逻辑层缓存的数据上传到存储层。

降低图片规则，减少图片下载流量

一张图片分为小、中、大三种规格，为了节约存储容量中图是通过图片压缩模块实时压缩返回给用户的，小图和大图真实存储在存储模块。为了降低图片下载的流量压力，我们调整了适配策略，用户访问大图，适配直接返回小图的url，减少了图片压缩逻辑，并且降低了带宽。

上传不检查相册有效性，减少存储索引访问量

正常情况，在用户上传图片时到相册时，会检查相册是否存在，如相册已被删除，则直接报错。柔性策略跳过相册有效性检查，直接上传图片到后端存储，降低索引访问量，降低索引模块负载。

同时在业务逻辑上，也做了以下的柔性措施：

核心模块启用过载保护机制：

判断单机cpu使用率超过80%时，会自动丢弃多余的请求，以保证业务逻辑模块在大量用户请求场景下不雪崩。

柔性关闭非核心业务功能减少业务自身负载

每张图片在高速存储会存储一份位置信息，图片裁剪时用于标示一张图片核心元素的位置。禁用此逻辑后，用户看到的图片无人脸中心点, 客户端裁剪可能不准确关闭用户删除标记，适配图片适配前会预先检测图片是否被删除，如已被删除则不会返回对应的图片列表。删除标记逻辑也会频繁和索引模块交互，高峰期时会占用大量计算资源。禁用此逻辑，用户访问相册时会看到已被删除的图片，但是会标记为灰色已删除。

调度：相册业务分布在三地，每地分别承载了约33%的用户，某地请求过高时，我们可以调度用户至其他容量相对较低的地域。