《百億次QQ紅包背后的運維實力》要點：
本文介紹了百億次QQ紅包背后的運維實力，希望對您有用。如果有疑問，可以聯系我們。

 

作者簡介

周小軍

騰訊SNG社交網絡運營中心高級運維工程師

資深運維專家,擁有十幾年的IT運維經驗,擅長互聯網網站架構、云計算平臺及運維、自動化運維開發等領域,具有十萬臺級規模的基礎設施規劃及運營能力,騰訊學院講師. 目前在騰訊社交網絡運營中心負責數據運維和接入運維工作.

前言

本文來自于?GOPS 2017 深圳站的演講“從騰訊社交平臺春節大活動的背后看運維自動化”.

2016年除夕夜,QQ 在線用戶峰值 2.6億,這一晚全球QQ用戶共刷了 72 900 000 000 次紅包.我們好奇什么樣的運維技術才能撐得住如此巨大的流量沖擊,帶著這個疑問,聽騰訊運維老兵為我們揭開謎底.

一、活動背景

運維有三座大山：大活動、大變更、大故障.這幾個運維場景是最消耗運維人力的.特別是大活動,非常考驗彈性能力,對運維自動化挑戰很大.

我今天所分享的主題就是深入百億次紅包大活動的背后,解析騰訊運維的方法體系,了解織云平臺如何幫助運維實現大活動高效運維,如何減少運維人海戰術.

過年大家都刷過微信紅包和 QQ 紅包,QQ 紅包的業務主要有幾種產品形態：刷一刷紅包、拼手氣紅包、AR紅包和空間紅包等.2016年跨年除夕這天有2.6億的在線用戶刷了729億次的紅包.這么大的體量給整個架構體系帶來的沖擊是非常大的.

今天將從”刷一刷紅包”的業務架構、活動背景、計劃擴容、壓測和演習、運維策略及活動現場這幾個方面來分享我們的活動型背后的運維支撐工作,希望給大家在產品大活動時提供參考和幫助.

挑戰

大活動前的二個月,產品會給研發和運維提供詳細的產品運營指標,今年春節前”刷一刷”紅包所規劃的產品指標預估為峰值每秒800萬,同時活動及節假日也帶來相關QQ消息量和空間說說量2-5倍的上漲.

根據運營指標,運維按歷史性能數據、容量模型和業務架構,評估出春節活動需要2萬臺虛擬機和3千臺數據庫服務器擴容支撐.

節前恰好遇到廠商內存供貨問題,服務器供應非常緊張,采購比原計劃延期了一個多月.甚至有個別型號的服務器到春節封網前一天才到貨.緊張的設備供給運維增加了擴容壓力.

二、活動計劃

2.1 日歷表

運維有2個月時間來準備和實施紅包活動,上圖是活動日程表.在確定產品策略和活動方案后,12月進入資源采購流程,元旦前后進入擴容部署.

業務擴容有兩周時間,到1月的中旬,也就是離春節還有2周的時間開始進行業務和模塊壓測,以及活動演習及預案,大年三十我們開始進入活動現場.

在活動現場,產品、開發和運維全部在第一線保障紅包,一直堅守到大年初一的凌晨一兩點鐘.

2.2活動梳理

由于活動涉及業務多,模塊核心鏈條關系錯蹤復雜,運維在前期的活動梳理中,要做好基礎能力、外部服務壓力和支撐等復雜的評估準備工作.

支撐工作梳理包括內網專線穿越流量梳理,因為業務均為多地部署(深圳、天津和上海),同城也有幾個大的核心IDC,業務不僅有同城跨IDC 部署,也有跨城異地部署,評估同城、跨城的專線容量是容量評估重點之一,如果超出閾值有什么應急方案,跨城調度與容災怎么做,柔性與過載保護策略等,這些都是運維要考慮的核心保障工作.

三、擴容

3.1 刷一刷紅包架構

在分享擴容之前,我先從刷一刷紅包的系統架構開始,先讓大家對業務進一步的了解.

業務架構由抽獎系統、消息系統和支付系統三個核心架構組成.

• 接入層SSO統一接入：手Q自身系統與客戶端唯一連接.
• 抽獎主邏輯：含抽獎相關邏輯、數據上報等、排行榜、訂單管理等.路由采用L5(自研內部路由系統簡稱)的HASH一致性功能,保證同一個用戶的不同請求會落到同一臺機器.
• 存儲：中獎記錄和獎品等信息統一存儲.統一使用公共組件Grocery(自研NoSQL分布式存儲系統)進行存儲.
• 禮包發貨：現金外的其他獎品發貨,包括公司內外業務的禮券.
• 公眾號消息：負責用戶中獎以及發貨通知.
• 支付系統：現金和獎品發貨,還包括后端的銀行接口等.
• CDN 資源：用于獎品圖片信息等資源下載.

根據這三個層,架構分成無狀態層和有狀態層,無狀態層為接入層和邏輯層；有狀態層即數據存儲層,數據持久化存儲.

擴容包括無狀態層和有狀態層的設備擴容.

上圖是系統的架構圖

3.2 無狀態服務自動擴容

3.2.1 傳統擴容流程

下面講一下怎么做無狀態的擴容,這是傳統的擴容流程,傳統運維的擴容流程一般是通過腳本來部署.我們把流程拆解下,可以看到它主要由以下核心步驟組成,包括部署操作系統、服務部署、配置下發、業務模塊關聯、業務代碼包發布、業務權限管理、啟動服務、模塊測試、服務上線和加入監控告警.

藍色圓圈是流程執行的時間消耗,這里一臺設備約消耗半小時.如果擴容一千臺機器需要兩個人/月.如果用腳本或開源運維工具批量的擴容,一個模塊按一人一天,這樣的工作量還是非常繁瑣的,非常依賴人海.

藍色圓圈是流程執行的時間消耗,這里一臺設備約消耗半小時.如果擴容一千臺機器需要兩個人/月.如果用腳本或開源運維工具批量的擴容,一個模塊按一人一天,這樣的工作量還是非常繁瑣的,非常依賴人海.

藍色圓圈是流程執行的時間消耗,這里一臺設備約消耗半小時.如果擴容一千臺機器需要兩個人/月.如果用腳本或開源運維工具批量的擴容,一個模塊按一人一天,這樣的工作量還是非常繁瑣的,非常依賴人海.

3.2.2 全自動擴容

在我們強大的織云自動化運維平臺支撐下,我們的業務模塊都是一鍵式擴容模式,也稱一鍵上云.一個模塊下的上百臺設備,整個擴容流程跑完只消耗5分鐘時間.

我們來看一下我們這邊是怎么做的,這是我們基于CMDB的全自動擴容,CMBD 是我們非常核心的擴容系統,包括資產、模塊、業務對象、軟件包、配置等等的數據信息都在這里面.

新部署服務器從 CMBD 獲取屬性以后,會進入到服務包的部署,之后到告警屏蔽,下面有發布自檢,會檢測裝的包是否正常的.然后到業務測試,灰度上線,體檢報告.整個流程效率比較高,一般來講部署一臺設備或一個模塊也就5分鐘,因為它是并發來做擴容的.織云已經把運維操作抽象成幾百個流程.

整個春節期間走了700多次擴容流程,每天都有上百個業務模塊并行,春節我們擴容了200多個模塊,平均一個模塊是100多臺設備.

上圖是織云的一鍵上云頁面,左邊是管理列表,右邊是服務器屬性.包括它屬于哪個模塊,IP是多少,什么機型,運營狀態,操作系統,監控等等.

當我們點擊”新增設備”按紐,下面就是擴容流程,就會彈出一個界面,會顯示出要擴什么樣的機型,系統支持Docker、虛擬機等等五種類型.下面就是設備責任人,IDC等等.點擊發布完,就會根據參考IP自動化把擴容批量IP走完整個流程.

剛剛說到我們擴容的最后流程是變更體檢報告,變更體檢報告是變更系統和監控系統的融合,依賴于變更系統的變更日志和監控系統的監控數據和監控告警.變更系統需要把每次現網變更記錄下來,變更體檢報告根據這個記錄,取得變更設備和變更對象列表,然后分析這些變更對象的監控數據,得出最終結果.

體檢報告的檢測結果為正常,需關注,異常.正常表示本次變更正常；需關注表示此次變更中有一些監控指標波動比較大,需要相關人員關注下,對業務本身沒有造成重要影響；異常表示本次變更造成了現網故障,需要立即回滾.正常的體檢報告不發送任何通知,需關注的體檢報告發送郵件通知,異常的體檢報告既發送郵件也發送短信通知.

檢查項大體可分為兩類：基礎特性檢查項,業務檢查項.

• 基礎特性檢查項是指與機器相關的監控項,如cpu,流量,包量等.
• 業務檢查項則是與業務相關的服務間調用(簡稱模調),自動化測試等.

體檢周期為5、10、20、30分鐘.

7個檢查特性包括CPU、網外卡流量、內外網卡包量、CPU超過80%的設備數、自動化測試告警、模調告警等,并分別進行評分.評分為0則正常,小于一定值則需要關注,總分大于一定值為異常.

上圖里面,變更5分鐘,告警數,容量告警、DLP 告警都是零,第10分鐘也是這個告警,到了第20分鐘出現四條模調告警,就觸發一條告警信息給運維,運維通過郵件把這個發給業務負責人.保證這個變更是閉環,從設備的申請到發布自檢到報告都是一個閉環的流程,這個運維是非常高效的.

剛才說過的傳統的擴容跟織云擴容的對比,傳統擴容基于用 Excel 或 Word 來管理業務信息和資源信息,稍進步一點的用數據庫來管理.運維要登錄跳板機或總控臺,在總控臺用命令行或頁面跑各種安裝腳本,腳本之間需要人工確認.

比如說裝一個 MySQL,安裝完成以后要手工把IP、端口等信息粘貼到下一個腳本或流程來由運維繼續執行,腳本間沒有全流程概念,需要人工去更新信息.一個業務工程師同時只能做一個模塊的變更或擴容,如果并發同時做多個變更,極易出錯出現故障.

織云高效的實踐是,它是以運維標準化為基石,以 CMDB 為核心的自動化運維平臺.通過 Web 界面的一鍵式上云,基于業務原子任務和流程引擎,形成一個完整的運維流程,最后并行執行.一個模塊一個人5到10分鐘就可以做完所有操作.

高效擴容的背后是基于一套標準化的理念.包括分層標準化、可運維規范、軟件標準化,并且標準化以 CMDB 落地.

我們以 CMDB 為核心,把資產配置、硬件配置、軟件配置、運營配置,比如說這個IP是在哪個地方部署的,因為我們有容災,還有權限的管理,我們模組之間有管理,把這些配置都打包到 CMDB 里面,通過引擎實現自動化發布機制.到線上服務以后,后面還會有監控告警、一致性、變更體檢等等閉環的服務.從 CMDB 到線上服務,整個流程都是閉環的.

這是運維標準化的實踐.把架構、配置、監控、軟件包、工具等等先實現標準化,然后落實到 CMDB 配置中心,通過工具或流程快速交付.標準化是要落地,如果沒有這些跟 CMDB 的實踐,標準化就是一個紙面的東西,是沒有辦法實現的,這四步缺一不可.

3.3 有狀態層的自動擴容

剛才講到無狀態的擴容,現在是講有狀態的數據層擴容.通常來講,數據層擴容是 DBA 工作中工作量最大、最易出故障的變更.但在我們這邊,數據層擴容已經實現了與無狀態層一樣的靈活性.

我們的數據層分兩層架構,上層是無狀態接入機,負責數據路由配置,下層是存儲機,負責數據存儲.

接入機擴容跟無狀態層的擴容方法類似.

存儲層通過數據搬遷,同時并行修改接入機路由表來實現擴容.

存儲層擴容的原理是,我們首先把記錄 KEY HASH 1萬到桶,桶再分配到存儲機的存儲單元,通常是 1GB 一個內存存儲單元,一臺 64GB 內存的存儲機有56個存儲單元.

桶是搬遷最小單元,通過桶搬遷方式來實現記錄的擴縮容,整個桶搬遷是全自動化,運維只要指定一臺或一批目標存儲機,桶和記錄就會自動搬遷分布到目標存儲機之上,搬遷過程中代理機的路由表是實時更新的,因此搬遷過程中業務的訪問不受任何影響,只是搬遷過程中的KEY不能刪除,但這個過程只有數秒時間,業務基本無感知.

上圖是數據層的架構,存儲層分內存存儲和固態盤存儲二級,數據可以自動根據冷熱規則在內存和存儲之間分布,以節省內存成本.目前我們共有2萬多臺 DB,人均管理兩千多臺 DB,存儲機擴容的效率很高,但由于數據搬遷速度較慢,通常是一臺 64GB 內存的內存存儲機在生產環境下需要1小時完成搬遷,因此3千臺 DB 花了兩三周時間來完成擴容.

四、壓測和演習

運維擺脫了設備擴容的人海戰術后,就像特種部隊一樣,把精力聚焦到有價值的工作中,譬如業務架構評審、資源評估和規劃,壓測及演習、應急預案、監控等等和業務相關的事情,這是業務運維應該更關注的地方.

4.1 紅包容量評估

如何評估活動容量?我們會根據四個維度來評估容量.首先是IDC 的容量,像電力、機柜、專線的容量等等.以服務器為維度,會關注四個核心指標,CPU、網絡的磁盤IO、網卡流量、網卡包量,判斷這個設備的整體容量水平.這是基礎的維度.

業務這邊,我們會有業務維度的評估,譬如紅包業務的每秒紅包容量.根據設備的能力來推導出業務容量的水平,譬如模塊單機能抗3千個 QPS,假設模塊下有一百臺設備,那么該模塊的 QPS 就能支撐30萬 QPS,并且這個容量負載必須是線性的增長.

4.2 紅包壓測

容量完成擴容前后,我們會多次對模塊和業務進行壓測,來評估容量基準值,擴容之后的水位能否支持到業務高峰.

我們通過演習的方式來模擬實際的用戶請求.

我們的業務是多地部署的,譬如 QQ 是分布到深圳、上海和天津三地.那么,我們把全國流量調度到其中一地,譬如深圳,觀察容量、延遲等指標,因為我們業務關鍵鏈路會有幾十個模塊,在這個過程中,有些模塊如果有問題會出現異常或告警,比如說有些模塊 CPU 會過熱,會上到 80%-90% 的高水位,或者失敗率開始增加.業務會根據這些模塊的容量,根據高負荷的模塊做一些性能的優化或擴容.保證這些模塊負載都是合理范圍.

第二部分是線上灰度,我們會逐漸放開搶紅包的活動,譬如對華南區域的用戶放開”刷一刷紅包”的入口,用戶有提示先去刷,刷的時候發現這個產品的測試是否符合預期,關鍵模塊的容量是不是達到我們的標準.我們會有灰度逐步放量,最后全部放量.還有一個小年夜的多時段,比如說在晚上定點來分別放開”刷一刷”這個活動的流量.

這是有一個壓測出問題的例子,我們在壓測的時候發現有一些存儲機的網卡流量被壓爆了,這是一臺網卡流量的巔峰,平時是 200-300Mb 的水平,到了壓測的時候壓滿 1Gb 的帶寬.我們分析發現,這個是存儲器上有熱 KEY,然后我們根據壓測出的情況繼續推動各種優化.

4.3 紅包演習

上圖是紅包演習的范例,我們把手Q的深圳 IDC 1000 萬用戶調到天津去,以模擬深圳的IDC掛后天津的壓力.運維日常以及節假日前會通過各種調度來做各種演習.

五、運維策略

5.1 業務錯峰部署

業務策略多變,之前評估供給的設備不一定能滿足實際產品指標,因此我們還做了業務錯峰部署,在一批服務器上同時部署了紅包和空間的服務,一臺機器會部署兩套服務.在紅包活動時這些設備用于紅包活動,紅包活動結束后,通過調度快速把機器調度到空間服務進程上,這樣錯峰來重用服務器計算資源.

大家可能會覺得這種切換風險比較高,后來經過我們的驗證,我們的調度能力還是確保這些多設備的復用達到我們的預期.我們通過技術的方式來做,即可以做到業務錯峰,也可以進行擴容.

5.2 柔性保護

在活動過程中還有很多服務故障,我們還需要對服務的柔性做一些測驗.我把我們”刷一刷紅包”分層,針對每個層出現的問題做一切特殊的過載保護.比如說QQ用戶,如果8點準點開放給用戶,同時會有2億的用戶涌入這個架構,系統的峰值會非常高.

在用戶層我們做了錯峰的開放,譬如在20：00到05分把用戶隨機放進來,把請求隨機分布在300秒區間.

如果接入層這邊出現容量和負載過高,我們會在這里隨機丟棄一些請求,根據用戶UIN的HASH進行隨機丟包.

如果是銀行這邊的接口出現瓶頸,我們會降低現金的的派發速度等等.消息系統出現瓶頸,我們會設置一定比例的用戶不發送消息.每一個層都會跟研發一起考慮這個容量出現問題的時候怎么做柔性保護

這是我們運維這邊一鍵下發屬性的界面(見PPT),我們可以選擇不同的模塊,然后選擇柔性的配置表,通過一鍵下發的方式將柔性策略實時下發,并實時生效.

六、活動現場

6.1 看監控

前面的擴容、壓測和應急預案等已經做完了,到了春節活動現場,運維主要有三類工作,一是看現場視圖,二是擴容過熱模塊,三是處理熱KEY.

有些業務模塊,通過壓測手段是沒有辦法模擬現網的,在現網情況下會出現容量超過閾值的情況.運維會通過視圖或告警快速發現,經過簡單評估后從備用資源池中緊急提取設備,對模塊進行擴容,把容量負載降到正常水位.

這是大年30運維部門的現場(見PPT),大家都在看視圖和快速擴容模塊,這是我們運維主要做的事情.

上力量是織云的運維核心視圖(見PPT),可以看到集成了各業務核心視圖,包括紅包大盤、紅包相關模塊告警,QQ 核心模塊容量,紅包視圖等等,運維主要是看這些視圖,看告警來保證活動是正常的.

6.2 現場挑戰-熱KEY

數據存儲在活動高峰面臨的挑戰之一是熱 KEY.即某一些熱點記錄的訪問量過大,高峰期甚至上漲百倍.

我們有幾種常用方法來處理熱KEY.首先是拆記錄,比如說這個記錄的訪問量非常大,每秒有十幾萬,我們會把 KEY 的 Value 分拆成多份,分布到不同的表實例.

其二是限制記錄的長度,有些 KEY 的 Value 很長,在熱點訪問時會給存儲機內存拷貝、網卡造成壓力.我們會查找出過長的 KEY-Value,讓業務通過字段壓縮、刪除冗余字段等方式來減少記錄長度.

第三是把千兆的存儲機換成萬兆的存儲機,讓網卡流量突破1Gb限制,在現網萬兆存儲機能跑到 5-6Gb 的水平.

第四是記錄打散,快速通過搬遷方式,把集中的熱點 KEY 分布到十幾臺存儲機來支撐.

最后,業務在前端可能會有幾十臺邏輯設備,業務可在邏輯設備上用內存做前端緩存,減少對后端存儲機的訪問.

七、回顧

回顧整個紅包的活動策略,萬臺級設備擴容僅用了2天時間,極大解救了運維.運維從擴縮容的工作量中解脫出來后,可以把更多的時間和精力更深入理解業務,為業務在質量、成本和速度幾個方面給用戶提供更多的價值,為業務保駕護航.

原文來自微信公眾號：高效運維

轉載請注明本頁網址：
http://www.fzlkiss.com/jiaocheng/2710.html