寫在前面

QQ 相冊(cè)作為重量級(jí)資深業(yè)務(wù)，穩(wěn)定運(yùn)營(yíng)、有效容災(zāi)，一直是相冊(cè)團(tuán)隊(duì)追求的目標(biāo)。QQ 相冊(cè)架構(gòu)一直在演變進(jìn)化，本文重點(diǎn)介紹相冊(cè)***的一次重構(gòu)細(xì)節(jié)。重構(gòu)進(jìn)行了大規(guī)模的存儲(chǔ)搬遷、功能模塊合并，抽象了圖片上傳“兩階段”，并在此之上設(shè)計(jì)了輕量級(jí)的容災(zāi)方案。新架構(gòu)精簡(jiǎn)了大量模塊，優(yōu)化了圖片上傳流程，減輕了運(yùn)維工作，從實(shí)際運(yùn)營(yíng)效果看，系統(tǒng)穩(wěn)定達(dá)到 4 個(gè) 9 的服務(wù)質(zhì)量，并具備跨 IDC 容災(zāi)的能力。

項(xiàng)目背景

QQ 相冊(cè)在之前已經(jīng)上線了索引異地容災(zāi)，當(dāng)時(shí)容災(zāi)的設(shè)計(jì)和實(shí)施，受限于人力和設(shè)備資源以及保守的升級(jí)策略，我們?cè)谠械南鄡?cè)架構(gòu)和業(yè)務(wù)流程上進(jìn)行非常輕量的設(shè)計(jì)，從過去一年的實(shí)際運(yùn)營(yíng)情況看，雖然在各種波動(dòng)和故障中起到了一定的作用，但是由于容災(zāi)場(chǎng)景有限，相冊(cè)體量龐大，存儲(chǔ)和索引分布在很多機(jī)房，稍有網(wǎng)絡(luò)波動(dòng)，業(yè)務(wù)仍然有較高的感知度。QQ 相冊(cè)接入架平這十年來，業(yè)務(wù)對(duì)相冊(cè)上傳成功率和整體服務(wù)質(zhì)量的要求越來越高，但由于相冊(cè)邏輯的復(fù)雜性，原有架構(gòu)在容災(zāi)、運(yùn)維和維護(hù)（尤其是對(duì)新人來說）等方面，并不友好。今年，我們對(duì)系統(tǒng)進(jìn)行了重構(gòu)！本文總結(jié)此次重構(gòu)的設(shè)計(jì)和實(shí)施，并展示新架構(gòu)下相冊(cè)的容災(zāi)細(xì)節(jié)和演習(xí)效果，***總結(jié)項(xiàng)目實(shí)施過程中的一些思考。

重構(gòu)目標(biāo)

從業(yè)務(wù)角度來說，本項(xiàng)目的實(shí)施旨在提高 QQ 相冊(cè)上傳的成功率，在各種小型網(wǎng)絡(luò)波動(dòng)和故障中低感知甚至不感知（上傳成功率分鐘粒度穩(wěn)定達(dá)到 3 個(gè) 9，全天成功率達(dá)到 4 個(gè) 9），在機(jī)房故障甚至大型災(zāi)難時(shí)，具備快速異地容災(zāi)和恢復(fù)的能力。對(duì)于相冊(cè)平臺(tái)來說，主要有以下幾個(gè)目標(biāo)：

1. 模塊合并
2. 簡(jiǎn)化架構(gòu)
3. 優(yōu)化上傳流程
4. 優(yōu)化容災(zāi)邏輯

解決方案

整體架構(gòu)調(diào)整

 一、原相冊(cè)架構(gòu)

QQ 相冊(cè)對(duì)外提供了豐富的接口，目前存儲(chǔ)量超過 300PB，用戶索引存儲(chǔ)按歸屬地分布，也達(dá)到數(shù)百 TB 的量級(jí)。當(dāng)前相冊(cè)平臺(tái)雖然較穩(wěn)定地支撐了如此大量級(jí)的業(yè)務(wù)，但是，系統(tǒng)架構(gòu)中，模塊眾多，數(shù)據(jù)流程復(fù)雜，這給開發(fā)、運(yùn)維和維護(hù)帶來不少麻煩。原相冊(cè)架構(gòu)如圖 1 所示。

圖 1：原 QQ 相冊(cè)上傳架構(gòu)

用戶使用 app 或 pc 客戶端進(jìn)行 QQ 相冊(cè)操作，比如上傳，修改，刪除，拉列表等，這些請(qǐng)求由 preupload 模塊完成，而 zz 模塊負(fù)責(zé)圖片的旋轉(zhuǎn)和轉(zhuǎn)載，recycle 模塊負(fù)責(zé)相冊(cè)回收站的操作。這里以最重要的上傳操作為例來說明各核心模塊的功能以及數(shù)據(jù)流向，如圖 2 所示。相冊(cè)數(shù)據(jù)龐大，索引分布在多個(gè)園區(qū)，單個(gè)用戶的全部索引信息都落在同一個(gè)園區(qū)內(nèi)。通過路由模塊可以查詢用戶索引的歸屬地。

圖 2：原用戶上傳流程圖

 二、重構(gòu)架構(gòu)

以往的架構(gòu)調(diào)整，大都是用“拆”，但是，隨著業(yè)務(wù)數(shù)據(jù)量的增長(zhǎng)，以及業(yè)務(wù)需求變化的緩和，我們更加關(guān)注系統(tǒng)的穩(wěn)定性和高可用性，于是此次重構(gòu)，我們采用了“合”的思路，把 zz 和 rececyle 整合進(jìn) preupoad。看上去功能耦合了，preupload 變得更加臃腫，但是從 zz 和 recycle 的功能邏輯來看，和 preupload 是一樣的或者很相似的，底層也是共用一套存儲(chǔ)，將他們獨(dú)立部署，時(shí)間久了，三個(gè)模塊的代碼邏輯差異越來越大，直接導(dǎo)致開發(fā)維護(hù)和運(yùn)維的困難。新架構(gòu)還把一些已經(jīng)沒用的模塊去掉，比如 ckv 系統(tǒng)，原圖系統(tǒng)等，然后將原圖功能完全接入秒傳率更高的微云系統(tǒng)，容災(zāi)模塊也從原來三地部署、兩兩互備，變成單獨(dú)園區(qū)部署。重構(gòu)如圖 3 所示。

圖 3：新 QQ 相冊(cè)上傳架構(gòu)

由于相冊(cè)用戶有歸屬地的問題，導(dǎo)致就近上傳請(qǐng)求有超過一半的概率需要進(jìn)行異地同步索引，在原架構(gòu)中，上傳流程需要判斷這一邏輯并分別處理，這使得原本就復(fù)雜的上傳邏輯變得更加難以理解，而且還給容災(zāi)造成極大的困擾。在重構(gòu)的時(shí)候，重點(diǎn)考慮了這一情況，并將上傳流程抽象為兩個(gè)階段：數(shù)據(jù)落地和索引落地。這樣，上傳流程簡(jiǎn)化為：就近 preupload 接收到上傳請(qǐng)求，先將圖片數(shù)據(jù)進(jìn)行壓縮落地，然后將索引信息發(fā)送到索引 preupload 去落地索引，如圖 4 所示。

圖 4：新用戶上傳流程圖

容災(zāi)流程調(diào)整

 一、原相冊(cè)上傳容災(zāi)

大致的容災(zāi)流程如圖 5 所示。

圖 5：原 QQ 相冊(cè)上傳容災(zāi)流程

 二、優(yōu)化容災(zāi)流程

在新的架構(gòu)上，把數(shù)據(jù)落地和索引落地獨(dú)立看待，容災(zāi)流程可以進(jìn)一步簡(jiǎn)化。首先，我們利用上傳請(qǐng)求協(xié)議中的一個(gè)預(yù)留標(biāo)志位，巧妙地把普通請(qǐng)求改造成容災(zāi)請(qǐng)求，并通過容災(zāi)配置項(xiàng)，預(yù)設(shè)模塊的容災(zāi)級(jí)別。系統(tǒng)根據(jù)請(qǐng)求類型（是否容災(zāi)請(qǐng)求）、配置項(xiàng)和動(dòng)態(tài)統(tǒng)計(jì)信息，實(shí)施相應(yīng)的容災(zāi)策略。容災(zāi)的數(shù)據(jù)流如圖 6 所示。

圖 6：新 QQ 相冊(cè)上傳容災(zāi)流程

 三、容災(zāi)策略

新的容災(zāi)流程，容災(zāi)策略比較簡(jiǎn)單，總結(jié)起來就是：

1. 根據(jù)索引 preupload 的可用性和超時(shí)率，決定要不要將上傳請(qǐng)求改造成容災(zāi)上傳請(qǐng)求（容災(zāi)請(qǐng)求或容災(zāi)重試）
2. 根據(jù)上傳 preupload 的可用性和超時(shí)率，決定要請(qǐng)求就近的上傳 preupload 還是異地的上傳 preupload（異地請(qǐng)求或異地重試）

下面通過不同的視角說明具體的策略實(shí)施。

業(yè)務(wù)視角

業(yè)務(wù)根據(jù)請(qǐng)求情況進(jìn)行容災(zāi)：

1. proxy 不可用，由業(yè)務(wù)切請(qǐng)求到可用 proxy
2. proxy 超時(shí)，超時(shí)率在 10% 以內(nèi)可重試一次，超時(shí)率在 10% 以上，視容量切請(qǐng)求到異地 proxy（超時(shí)率閥值會(huì)根據(jù)實(shí)際運(yùn)營(yíng)進(jìn)行調(diào)整）
3. proxy 過載，不可重試，視容量切請(qǐng)求到異地 proxy
4. proxy 返回錯(cuò)誤，不建議重試

proxy 視角

1、大型故障導(dǎo)致模塊整體不可用，需要直接進(jìn)行異地請(qǐng)求或索引容災(zāi)，請(qǐng)求失敗不進(jìn)行重試。

表 1：大型故障容災(zāi)配置及操作

2、普通故障和小波動(dòng)，直接請(qǐng)求就近 preupload，請(qǐng)求失敗則根據(jù)超時(shí)率和錯(cuò)誤碼采取相應(yīng)的重試措施。

表 2：大型故障容災(zāi)配置及操作

上傳 preupload 視角

上傳 preupload 收到 proxy 的請(qǐng)求，先落地圖片數(shù)據(jù)，如果是容災(zāi)上傳，需要生成容災(zāi)索引發(fā)送到 synsrv，普通上傳則生成常規(guī)索引發(fā)送到索引 preupload，然后寫 synsrv 備份索引，不進(jìn)行任何重試。

索引 preupload 視角

索引 preupload 收到上傳 preupload 的請(qǐng)求，寫主索引和次要索引，不進(jìn)行任何重試。

synsrv 視角

1. 收到備份請(qǐng)求，直接回復(fù)成功，并且寫備份索引；
2. 收到容災(zāi)請(qǐng)求，先寫備份索引，再存儲(chǔ)容災(zāi)索引，并標(biāo)記 bitmap，所有都成功才返回成功；
3. 定期檢測(cè)是否有容災(zāi)索引，有的話，同步回索引點(diǎn) preupload。

四、關(guān)于超時(shí)時(shí)間的設(shè)置

重試是容災(zāi)的重要手段甚至是必要手段，但是看似簡(jiǎn)單，實(shí)則用好不易，特別地，重試會(huì)放大流量，在失敗率很高的情況下，過多的重試可能導(dǎo)致機(jī)器過載，甚至擊垮后端服務(wù)，另外，對(duì)于多步驟流程的任務(wù)來說，在哪些步驟上做重試，以及每一步的超時(shí)時(shí)間設(shè)置，都是挑戰(zhàn)。

我們考慮了所有模塊的過載保護(hù)功能，并極簡(jiǎn)重試機(jī)制：在設(shè)定的超時(shí)率范圍內(nèi)，僅在 proxy 層面做一次本地重試或異地重試！圖 7 以一條最長(zhǎng)的鏈路說明每個(gè)流程的超時(shí)時(shí)間設(shè)定。根據(jù)經(jīng)驗(yàn)，業(yè)務(wù)對(duì)于上傳的超時(shí)時(shí)間為 120 秒，proxy 本地請(qǐng)求一次超時(shí)為 60 秒，本地重試一次超時(shí)為 60 秒，異地請(qǐng)求一次超時(shí)為 60 秒。超時(shí)時(shí)間可能會(huì)在實(shí)際運(yùn)營(yíng)后進(jìn)行調(diào)整優(yōu)化。

圖 7：上傳接口各流程超時(shí)時(shí)間配置

重要成果

項(xiàng)目上線已有一段時(shí)間，從實(shí)際運(yùn)營(yíng)效果看，較好的達(dá)到設(shè)定的目標(biāo)。

1、模塊精簡(jiǎn)。相冊(cè)重構(gòu)后，直接下架了三地原圖中轉(zhuǎn) rawupload、兩地原圖落地 rawupload、四個(gè)園區(qū)的轉(zhuǎn)載 preupload 和回收站 preupload 等模塊，并將原來多園區(qū)部署的容災(zāi)系統(tǒng)模塊統(tǒng)一到深圳園區(qū)，業(yè)務(wù)模塊數(shù)量從原來的 37 個(gè)減少到 18 個(gè)，極大地簡(jiǎn)化了維護(hù)和運(yùn)維工作。

2、成功率提升。優(yōu)化了上傳流程以及重試策略，重點(diǎn)排查了出現(xiàn)頻次 top 10 的錯(cuò)誤碼，目前上傳的成功率從全天平均接近 3 個(gè) 9 提升到穩(wěn)定的分鐘平均 3 個(gè) 9、全天平均 4 個(gè) 9 的水平。圖 8 為重構(gòu)優(yōu)化前的上傳成功率統(tǒng)計(jì)，圖 9 為重構(gòu)優(yōu)化后的上傳成功率。

圖 8：重構(gòu)前上傳成功率

圖 9：重構(gòu)后上傳成功率

3、容災(zāi)能力提升。新的容災(zāi)策略基于精心整理的錯(cuò)誤碼分類，能做到精準(zhǔn)的異地容災(zāi)，容災(zāi)功能上線以來，可以看到一些小波動(dòng)的故障也能及時(shí)觸發(fā)異地容災(zāi)，成功率得到更完備的保障。不過，上線以來還未出現(xiàn)過大型故障，因此我們也進(jìn)行了現(xiàn)網(wǎng)故障演習(xí)，演習(xí)結(jié)果表明，新的容災(zāi)邏輯在應(yīng)對(duì)大型故障也有不錯(cuò)的表現(xiàn)。表 3 和表 4 分別為容災(zāi)級(jí)別為 2 級(jí)和 3 級(jí)配置下的演習(xí)數(shù)據(jù)。

表 3：容災(zāi) Level=2 配置下小規(guī)模容災(zāi)演習(xí)成功率

表 4：容災(zāi) Level=3 配置下小規(guī)模容災(zāi)演習(xí)成功率

寫在***

相冊(cè)上傳重構(gòu)項(xiàng)目落地已有一段時(shí)間了，從實(shí)際運(yùn)營(yíng)效果來看，在系統(tǒng)維護(hù)、運(yùn)維、實(shí)際上傳成功率、業(yè)務(wù)投訴量等方面，都有不錯(cuò)的優(yōu)化效果。架構(gòu)設(shè)計(jì)中的“分分合合”，是一門學(xué)問，相冊(cè)把數(shù)據(jù)和索引分開存儲(chǔ)，索引又分為主索引和次要索引，輕重分離，提高了存儲(chǔ)效率；新架構(gòu)抽象了上傳流程，把數(shù)據(jù)落地和索引落進(jìn)行邏輯分離和模塊分離，更易于理解和容錯(cuò)設(shè)計(jì)；而合并了邏輯重合度高的模塊，則有利于系統(tǒng)的維護(hù)和運(yùn)維。架構(gòu)設(shè)計(jì)上沒有永遠(yuǎn)的相聚也沒有永遠(yuǎn)的分離，只有變化的線上需求，變化的流程，當(dāng)架構(gòu)不再適應(yīng)新的場(chǎng)景時(shí)，需要進(jìn)行重構(gòu)調(diào)整。