不久前中国内地网民的微信朋友圈、微博等社交平台已然被各种富有年代感的“十八岁照”刷屏，大家纷纷通过晒图形式追忆自己的青春。有趣的是，这些刷到朋友圈上的照片大多来自人人网相册以及QQ相册，这些早已经被不少人遗忘的相册服务是如何将这么多杂乱的照片安全保存至今的？腾讯技术工程师xianmau在腾讯云社区撰文解释技术内幕。
写在前面
QQ 相册作为重量级资深业务，稳定运营、有效容灾，一直是相册团队追求的目标。QQ 相册架构一直在演变进化，本文重点介绍相册***的一次重构细节。重构进行了大规模的存储搬迁、功能模块合并，抽象了图片上传“两阶段”，并在此之上设计了轻量级的容灾方案。新架构精简了大量模块，优化了图片上传流程，减轻了运维工作，从实际运营效果看，系统稳定达到 4 个 9 的服务质量，并具备跨 IDC 容灾的能力。
项目背景
QQ 相册在之前已经上线了索引异地容灾，当时容灾的设计和实施，受限于人力和设备资源以及保守的升级策略，我们在原有的相册架构和业务流程上进行非常轻量的设计，从过去一年的实际运营情况看，虽然在各种波动和故障中起到了一定的作用，但是由于容灾场景有限，相册体量庞大，存储和索引分布在很多机房，稍有网络波动，业务仍然有较高的感知度。QQ 相册接入架平这十年来，业务对相册上传成功率和整体服务质量的要求越来越高，但由于相册逻辑的复杂性，原有架构在容灾、运维和维护（尤其是对新人来说）等方面，并不友好。今年，我们对系统进行了重构！本文总结此次重构的设计和实施，并展示新架构下相册的容灾细节和演习效果，***总结项目实施过程中的一些思考。
重构目标
从业务角度来说，本项目的实施旨在提高 QQ 相册上传的成功率，在各种小型网络波动和故障中低感知甚至不感知（上传成功率分钟粒度稳定达到 3 个 9，全天成功率达到 4 个 9），在机房故障甚至大型灾难时，具备快速异地容灾和恢复的能力。对于相册平台来说，主要有以下几个目标：
- 模块合并
- 简化架构
- 优化上传流程
- 优化容灾逻辑
解决方案
整体架构调整
一、原相册架构
QQ 相册对外提供了丰富的接口，目前存储量超过 300PB，用户索引存储按归属地分布，也达到数百 TB 的量级。当前相册平台虽然较稳定地支撑了如此大量级的业务，但是，系统架构中，模块众多，数据流程复杂，这给开发、运维和维护带来不少麻烦。原相册架构如图 1 所示。
图 1：原 QQ 相册上传架构
用户使用 app 或 pc 客户端进行 QQ 相册操作，比如上传，修改，删除，拉列表等，这些请求由 preupload 模块完成，而 zz 模块负责图片的旋转和转载，recycle 模块负责相册回收站的操作。这里以最重要的上传操作为例来说明各核心模块的功能以及数据流向，如图 2 所示。相册数据庞大，索引分布在多个园区，单个用户的全部索引信息都落在同一个园区内。通过路由模块可以查询用户索引的归属地。
图 2：原用户上传流程图
二、重构架构
以往的架构调整，大都是用“拆”，但是，随着业务数据量的增长，以及业务需求变化的缓和，我们更加关注系统的稳定性和高可用性，于是此次重构，我们采用了“合”的思路，把 zz 和 rececyle 整合进 preupoad。看上去功能耦合了，preupload 变得更加臃肿，但是从 zz 和 recycle 的功能逻辑来看，和 preupload 是一样的或者很相似的，底层也是共用一套存储，将他们独立部署，时间久了，三个模块的代码逻辑差异越来越大，直接导致开发维护和运维的困难。新架构还把一些已经没用的模块去掉，比如 ckv 系统，原图系统等，然后将原图功能完全接入秒传率更高的微云系统，容灾模块也从原来三地部署、两两互备，变成单独园区部署。重构如图 3 所示。
图 3：新 QQ 相册上传架构
由于相册用户有归属地的问题，导致就近上传请求有超过一半的概率需要进行异地同步索引，在原架构中，上传流程需要判断这一逻辑并分别处理，这使得原本就复杂的上传逻辑变得更加难以理解，而且还给容灾造成极大的困扰。在重构的时候，重点考虑了这一情况，并将上传流程抽象为两个阶段：数据落地和索引落地。这样，上传流程简化为：就近 preupload 接收到上传请求，先将图片数据进行压缩落地，然后将索引信息发送到索引 preupload 去落地索引，如图 4 所示。
图 4：新用户上传流程图
容灾流程调整
一、原相册上传容灾
大致的容灾流程如图 5 所示。
图 5：原 QQ 相册上传容灾流程
二、优化容灾流程
在新的架构上，把数据落地和索引落地独立看待，容灾流程可以进一步简化。首先，我们利用上传请求协议中的一个预留标志位，巧妙地把普通请求改造成容灾请求，并通过容灾配置项，预设模块的容灾级别。系统根据请求类型（是否容灾请求）、配置项和动态统计信息，实施相应的容灾策略。容灾的数据流如图 6 所示。
图 6：新 QQ 相册上传容灾流程
三、容灾策略
新的容灾流程，容灾策略比较简单，总结起来就是：
- 根据索引 preupload 的可用性和超时率，决定要不要将上传请求改造成容灾上传请求（容灾请求或容灾重试）
- 根据上传 preupload 的可用性和超时率，决定要请求就近的上传 preupload 还是异地的上传 preupload（异地请求或异地重试）
下面通过不同的视角说明具体的策略实施。
业务视角
业务根据请求情况进行容灾：
- proxy 不可用，由业务切请求到可用 proxy
- proxy 超时，超时率在 10% 以内可重试一次，超时率在 10% 以上，视容量切请求到异地 proxy（超时率阀值会根据实际运营进行调整）
- proxy 过载，不可重试，视容量切请求到异地 proxy
- proxy 返回错误，不建议重试
proxy 视角
1、大型故障导致模块整体不可用，需要直接进行异地请求或索引容灾，请求失败不进行重试。
表 1：大型故障容灾配置及操作
2、普通故障和小波动，直接请求就近 preupload，请求失败则根据超时率和错误码采取相应的重试措施。
表 2：大型故障容灾配置及操作
上传 preupload 视角
上传 preupload 收到 proxy 的请求，先落地图片数据，如果是容灾上传，需要生成容灾索引发送到 synsrv，普通上传则生成常规索引发送到索引 preupload，然后写 synsrv 备份索引，不进行任何重试。
索引 preupload 视角
索引 preupload 收到上传 preupload 的请求，写主索引和次要索引，不进行任何重试。
synsrv 视角
- 收到备份请求，直接回复成功，并且写备份索引；
- 收到容灾请求，先写备份索引，再存储容灾索引，并标记 bitmap，所有都成功才返回成功；
- 定期检测是否有容灾索引，有的话，同步回索引点 preupload。
四、关于超时时间的设置
重试是容灾的重要手段甚至是必要手段，但是看似简单，实则用好不易，特别地，重试会放大流量，在失败率很高的情况下，过多的重试可能导致机器过载，甚至击垮后端服务，另外，对于多步骤流程的任务来说，在哪些步骤上做重试，以及每一步的超时时间设置，都是挑战。
我们考虑了所有模块的过载保护功能，并极简重试机制：在设定的超时率范围内，仅在 proxy 层面做一次本地重试或异地重试！图 7 以一条最长的链路说明每个流程的超时时间设定。根据经验，业务对于上传的超时时间为 120 秒，proxy 本地请求一次超时为 60 秒，本地重试一次超时为 60 秒，异地请求一次超时为 60 秒。超时时间可能会在实际运营后进行调整优化。
图 7：上传接口各流程超时时间配置
重要成果
项目上线已有一段时间，从实际运营效果看，较好的达到设定的目标。
1、模块精简。相册重构后，直接下架了三地原图中转 rawupload、两地原图落地 rawupload、四个园区的转载 preupload 和回收站 preupload 等模块，并将原来多园区部署的容灾系统模块统一到深圳园区，业务模块数量从原来的 37 个减少到 18 个，极大地简化了维护和运维工作。
2、成功率提升。优化了上传流程以及重试策略，重点排查了出现频次 top 10 的错误码，目前上传的成功率从全天平均接近 3 个 9 提升到稳定的分钟平均 3 个 9、全天平均 4 个 9 的水平。图 8 为重构优化前的上传成功率统计，图 9 为重构优化后的上传成功率。
图 8：重构前上传成功率
图 9：重构后上传成功率
3、容灾能力提升。新的容灾策略基于精心整理的错误码分类，能做到精准的异地容灾，容灾功能上线以来，可以看到一些小波动的故障也能及时触发异地容灾，成功率得到更完备的保障。不过，上线以来还未出现过大型故障，因此我们也进行了现网故障演习，演习结果表明，新的容灾逻辑在应对大型故障也有不错的表现。表 3 和表 4 分别为容灾级别为 2 级和 3 级配置下的演习数据。
表 3：容灾 Level=2 配置下小规模容灾演习成功率
表 4：容灾 Level=3 配置下小规模容灾演习成功率
写在***
相册上传重构项目落地已有一段时间了，从实际运营效果来看，在系统维护、运维、实际上传成功率、业务投诉量等方面，都有不错的优化效果。架构设计中的“分分合合”，是一门学问，相册把数据和索引分开存储，索引又分为主索引和次要索引，轻重分离，提高了存储效率；新架构抽象了上传流程，把数据落地和索引落进行逻辑分离和模块分离，更易于理解和容错设计；而合并了逻辑重合度高的模块，则有利于系统的维护和运维。架构设计上没有永远的相聚也没有永远的分离，只有变化的线上需求，变化的流程，当架构不再适应新的场景时，需要进行重构调整。
