看騰訊運維應對「18歲照片全民懷舊」事件的方案，你必定不後悔！

做者丨魏暘：騰訊高級工程師，15年運維經驗的老專家，負責QQ空間、微雲、QQ空間相冊的運維工做，親歷8億軍裝照、QQ空間異地多活建設等重大架構升級事件。

2017年12月30日，元旦假期的第一天，你的朋友圈被18歲照片刷屏了嗎？聽說「曬18歲照片」的根源是2017年年未，最後一批90後將度過他們的18歲生日。這意味着，90後已所有成年，集體告別了青蔥芳華。

這是一個青春的、也是懷舊的年華，QQ空間作爲國內第一批社交平臺產品，承載了較多的用戶記憶，大量的用戶涌入QQ空間翻找本身多年前的18歲照片曬上社交平臺。集體引爆了空間相冊山洪峯涌而至的照片流量。

下面這篇文章讓咱們回顧12月30日，空間相冊面對突發四倍流量，七成訪問落在後端冷存儲的極端壓力下，相冊運維、開發團隊如何憑藉平時基礎功底，從告警、容量、擴容、柔性、調度等全方面運維能力，扛過「18歲照片」的全民懷舊事件。

業務數據回顧

忽然來襲的用戶集中行爲，給咱們平臺的能力帶來了很是嚴峻的考驗，先讓咱們先來看一組數據：

1） 圖片下載量峯值達到平日晚高峯的4倍，且70%以上都彙集在平日不怎麼訪問的冷圖片。

2） 圖片上傳量達到平日晚高峯的4倍。

3） 帶圖說說峯值達到平日晚高峯的12倍。

業務架構剖析

面對忽然涌入的用戶請求，相冊開發與和運維是如何堅守陣地，度過此次難關的呢？

在介紹一系列的措施以前，首先不得不介紹下相冊業務架構，下圖較爲抽像地介紹了相冊的主要架構：

1. 上傳鏈路： 用戶上傳圖片/視頻，數據流主要由上圖中間鏈路處理，通過proxy->邏輯（分片、權限、緩存等）->存儲接入（分片整合、生成文件地址等）->落地存儲
2. 下載鏈路：
3. 用戶經過空間（說說、日誌、動態等）訪問相冊圖片，圖片適配模塊根據用戶請求、終端、請求量等場景適配出最優圖片規格，返回用戶圖片、視頻URL。
4. 用戶經過上一步獲取的URL 訪問後端存儲的圖片、視頻。

平常運維工做

同時，咱們介紹一下騰訊SNG社交網絡運營部平時進行的一些平常容量管理工做。

1） 鏈路梳理

如上節所述，咱們梳理出相冊核心鏈路，經常使用梳理過程有幾種：

• 經過抓包形式肯定鏈路模塊
• 經過設備上報的主被調數據肯定調用鏈路
• 名字服務中獲取相關的調用鏈數據。
• 經過全鏈路數據彙總出相關的鏈路。

2）壓測：

按期對整條鏈路作壓測，壓測手段有異地調度壓測，或單機壓測，經過壓測找出鏈路內存在瓶頸的模塊，及時修正鏈路模型。

3）高低負載處理：

依據壓測容量數據，分配設備擴容。負載較低的模塊設備進行縮容下線以節省成本。

容量應急措施

可是這裏的問題是顯而易見的：以上常規性的工做，只能發現常規場景下內部存在的瓶頸。像18歲照片這種特殊場景（用戶大量讀取空間相冊，獲取冷數據），沒法經過常規壓測檢測出來問題, 這就須要一系列的機制來解決

1) 監控和容量彈性機制：

經過IaaS層監控對系統的基礎特徵進行監控，（如CPU負載，出入流量），當模塊容量出現異常時，彈性擴容機制須要介入處理，進行擴容。

如何快速支持短期擴容上千臺設備呢？不得不介紹一下騰訊SNG的織雲運維理念。

如上文所述，咱們的設備被分配到不一樣的「業務模塊」，而每個模塊有以下的屬性：

1） 包：業務處理邏輯文件包，包含業務包與基礎包。

2） 配置：包含業務包要使用到的各類配置

3） 權限：包含支撐業務包正常運行時須要的數據庫、內部鑑權系統等權限

4） 測試工具：包含業務包啓動後，可否接入現網的測試標準

織雲提倡的自動化理念是：標準化 -> 配置化 -> 自動化，讓企業的經常使用操做固化成流程工具。不依賴容易過時的文檔，不依賴容易流失的人的經驗。

參考持續交付的原則「爲軟件的發佈建立一個可重複且可靠的過程」，運維團隊爲了解決人肉操做經驗差別的難題，將運維操做經過流程DIY編排能力，實現標準操做的固化。「18歲照片」活動擴容，任何一個運維人員只須要執行QQ相冊的擴容功能便可實現容量擴展，而織雲流程會自動化的完成整個服務部署和上線的操做。（以下圖）

柔性業務架構

前面咱們說過，相冊在當天的峯值下載量漲了4倍，且可能是訪問冷數據，但在短期內沒法籌集到4倍的資源，業務是如何應對的呢，在保證用戶核心體驗不受影響的前提下，咱們採用了一些柔性手段。

回顧一下，當時咱們在容量不足時碰到如下的問題，致使短期內部分圖片拉取耗時過長，影響用戶體驗。

1） 存儲壓力過大。

2） 自身模塊壓力過大。

針對存儲壓力過大的問題，咱們採用瞭如下幾個手段來下降業務負載：

1） 存儲手段

a. 圖片適配優化索引策略減小存儲壓力

減小拉取照片分批次數，下降後端存儲處理壓力。分批拉取照片列表數量增長3倍。交互次數直接降低近2/3。

b. 圖片上傳增長本地緩存空間減小存儲高負載形成的用戶上傳失敗

調整上傳邏輯模塊，從原來的本地內存緩存優化爲內存+本地磁盤緩存，經過增長本地緩存空間減小後端存儲高負載對用戶側上傳圖片/視頻的影響。雖然底層存儲高負載了，可是用戶仍是能夠不受底層影響，將圖片經過接入上傳到邏輯層緩存。存儲壓力釋放後便可將邏輯層緩存的數據上傳到存儲層。

c. 下降圖片規則，減小圖片下載流量：

一張圖片分爲小、中、大三種規格，爲了節約存儲容量中圖是經過圖片壓縮模塊實時壓縮返回給用戶的，小圖和大圖真實存儲在存儲模塊。爲了下降圖片下載的流量壓力，咱們調整了適配策略，用戶訪問大圖，適配直接返回小圖的url，減小了圖片壓縮邏輯，而且下降了帶寬。調整後圖片下載帶寬對好比下：

d. 上傳不檢查相冊有效性，減小存儲索引訪問量：

正常狀況，在用戶上傳圖片時到相冊時，會檢查相冊是否存在，如相冊已被刪除，則直接報錯。柔性策略跳過相冊有效性檢查，直接上傳圖片到後端存儲，下降索引訪問量，下降索引模塊負載。

同時在業務邏輯上，也作了如下的柔性措施：

a. 核心模塊啓用過載保護機制：

判斷單機cpu使用率超過80%時，會自動丟棄多餘的請求，以保證業務邏輯模塊在大量用戶請求場景下不雪崩。

b. 柔性關閉非核心業務功能減小業務自身負載

每張圖片在高速存儲會存儲一份位置信息，圖片裁剪時用於標示一張圖片核心元素的位置。禁用此邏輯後，用戶看到的圖片無人臉中心點, 客戶端裁剪可能不許確。

關閉用戶刪除標記，適配圖片適配前會預先檢測圖片是否被刪除，如已被刪除則不會返回對應的圖片列表。刪除標記邏輯也會頻繁和索引模塊交互，高峯期時會佔用大量計算資源。禁用此邏輯，用戶訪問相冊時會看到已被刪除的圖片，可是會標記爲灰色已刪除。

調度：相冊業務分佈在三地，每地分別承載了約33%的用戶，某地請求太高時，咱們能夠調度用戶至其餘容量相對較低的地域。

小結

從「18歲照片全民懷舊」熱點社交事件能夠看到，事發過程當中留給運維的時間至關少，只有嚴格貫徹「養兵千日用兵一時」的標準化運維理念，建設完善的運維體系，才能在突發事件中游刃有餘。

後記

此次18歲照片活動，相冊經過多種手段頂住了業務壓力。 同時經過此次活動，咱們也對將來的運維工具進行了進一步規劃，好比：

a) 基於容量的智能調度體系

b) 資源託管平臺。

c) 自動演習系統。

織雲平臺的運維能力在不斷迭代，期待在下一次活動來臨時可以作到更加有條不紊。