《騰訊:3億人次實戰演習驗證異地容災架構與快速調度能力》要點:
本文介紹了騰訊:3億人次實戰演習驗證異地容災架構與快速調度能力,希望對您有用。如果有疑問,可以聯系我們。
作者介紹:
李光
現就職于騰訊SNG社交網絡運營部,負責SNG移動類產品的業務運維,同時也負責運營平臺規劃與運維產品運營推廣工作
前言
社交網絡事業群擁有眾多海量規模的業務,在海量的運營壓力下,服務器設備的數量也突破了10w大關,并有序的分布在全國不同的IDC中實現異地容災的高可用架構.
但正因為社交業務的多IDC管理的復雜性,使運維小伙伴們經常會遇見一些難搞定的場景,如運營商網絡出口異常流量驟降、網絡延時突增、IDC斷電斷網、光纖被挖斷等突發事件,假設沒有第一時間發現和處理好這些事件,就會有較大的機率影響騰訊社交產品的服務質量,甚至會造成用戶大范圍的登錄與訪問中斷.
如何在種種不可控的突發情況來臨時,業務能在用戶“零感知”的情況下第一時間恢復服務質量呢?這就需要我們的業務要有健壯的異地容災架構與快速的全網調度能力.
本文介紹的是手機QQ與Qzone兩個服務于海量用戶的平臺級業務,在無損用戶服務質量的基準原則下,通過億量級人次的限時調度實戰演習來驗證我們的異地容災架構與快速調度能力.
海量服務之道就是要給億級用戶持續提供高質量與分級可控的服務,所有的研發與運維行為都應該圍繞保障與提升用戶服務質量展開,面對種種不可控的突發情況時,恢復業務的服務質量為最高優先級要務.
讓我們把時間撥回一年前,2015年8.13日天津爆炸事件,相信很多的互聯網從業人員都印象頗深,騰訊天津數據中心距離起爆點直線距離僅一公里,可能會受到波及,華北7000多萬QQ用戶將面臨著登陸和訪問中斷的可能,那天晚上我們通過多次調度與柔性控制,在用戶“零感知”的情況下,順利的將天津全量用戶調回深圳.
容災能力是服務于業務,隨著業務的持續發展.現在我們的整體容災架構是三地分布,三地三活,在各業務分布上實現set化部署,鏈路均衡分布,完善容量架構,從而減少風險.
QQ與Qzone的容災能力演進主路線也是單地—>雙地—>三地,三地分布也提升了服務質量,方便用戶更加的就近接入.
為了行文方便,后續出現“雙平臺”字眼時,如無特殊說明均指“QQ+Qzone”的統一體.
對于調度用戶,一般都是從流量入口即接入層分流用戶,雙平臺也沿用與此思路.
前端支撐手Q2.59億同時在線用戶,后端連接幾百個業務模塊,接入層上千臺機器主要分布在三大城市的數十個IDC,每分鐘處理20多億個業務包,7*24小時不間斷為億萬用戶提供著穩定的接入服務……這就是手Q接入層SSO.
手Q終端與SSO之間并不是直連的,兩者之間還加入了TGW,TGW全稱是TencentGateway,它是公司內部自主研發的一套多網統一接入,支持負載均衡的系統;它具有可靠性高、擴展性強、性能好、抗攻擊能力強等特點.加入TGW后終端與SSO、后臺之間的關系如下圖所示:
QQ用戶登錄概要流程如下圖所示:
Qzone的主要流量入口來自手Q,因此雙平臺用戶可以聯動調度.
調度動作概要來說就是干預用戶的接入點,下圖是一個非常概要的流程:
根據業務發展的推動與場景的細化,雙平臺的調度能力主要為兩個方向.
測速調度:
重定向調度:
在對后臺無沖擊壓力的情況下,我們可以完成千萬在線用戶10分鐘之內調度完畢,并且在調度期間用戶無感知 ,上圖就是我們在單次調度時清空一地在線用戶數的下降速率.
調度場景:
調度操作:
我們先來看兩個場景,相信這兩個場景運維小伙伴或多或少都可能經歷過.
故事場景1:
某個電閃雷鳴、風雨交加的夜晚,運維小哥正舒服的窩在床上看著電影,突然手機一波告警襲來,N個服務延時集體飆高,經排查是運營商網絡出口異常,運營商也暫時未能反饋修復時間,經評估后快速根本的解決方法就是將故障城市的xxx萬用戶調度到B城市,運維小哥正準備使出洪荒之力乾坤大挪移的將用戶移走,但杯具的是調度系統掉鏈子了,調度任務計算與下發異常,極速吼上相關同學排查調度系統問題,同時開啟后臺柔性撐過故障期.
故事場景2:
活動開始,用戶量逐步攀升,并且有地域聚集現象,A城市的整體負載已經偏高了,需要遷移XXX萬用戶調度到B城市,以便減少A的整體負載,在調度過程中發現B因某條業務鏈路的短板,所能承載的增量用戶要小于前期建設評估的整體用戶量,增量壓過去,會把B壓垮.
上面兩個場景,直接折射出問題是什么?
只有通過實際場景檢驗的能力,才是我們運維手里真正可用的武器,而不是在軍械庫里放著,只是在盤點的時候“具備”的能力.
容災能力與容量架構把控是海量運維必修內功,能力的鍛煉就是要通過不斷的實戰演習得來,要讓我們所“具備”的能力變為關鍵時刻的武器.
如上圖所示,通過一個完整的閉環流程,來不斷的精耕細作以便提升我們的能力,通過實戰將問題暴露出來,避免緊急事件時的被動.
QQ是一個體量非常之大的業務(DAU:8.3億),業務功能樹復雜,一個葉子節點的異常就有可能導致大范圍用戶的有損體驗與投訴.假設演習期間某個環節有問題,將有可能導致一個大范圍的事故.
我們在思考如何安全落地演習的時候,也主要基于以上緯度的考慮.話說不打無準備的仗,事前評估越完善,相應的就能提升我們整體演習的成功率,下圖就是我們最終落地的一個可執行的詳細演習流程圖.
如上圖所示 演習也是一個節點較多的閉環流程,生命周期主要分為以下三部分
要通過演習生產出我們所需的數據與檢驗我們的業務質量,雙平臺是服務于海量用戶,全網業務鏈路復雜,我們期望能從下面三個維度檢驗我們的能力.
驗證業務質量與容量:
量化調度能力:
運營平臺:
我們堅持月度/季度的實際演習調度,并在業務峰值實施調度演習.整個演習期間用戶“零感知”,業務質量無損,無一例用戶投訴.如此量級的演習在雙平臺的歷史上也屬于首次.演習也是灰度逐步遞進的節奏,下面圖例展示了,我們對一個城市持續三次的調度演習,用戶量級也是逐步增多 2000W?4000W?清空一個城市.
如上圖所示 演習也是一個節點較多的閉環流程,生命周期主要分為以下三部分
要通過演習生產出我們所需的數據與檢驗我們的業務質量,雙平臺是服務于海量用戶,全網業務鏈路復雜,我們期望能從下面三個維度檢驗我們的能力.
驗證業務質量與容量:
量化調度能力:
運營平臺:
我們堅持月度/季度的實際演習調度,并在業務峰值實施調度演習.整個演習期間用戶“零感知”,業務質量無損,無一例用戶投訴.如此量級的演習在雙平臺的歷史上也屬于首次.演習也是灰度逐步遞進的節奏,下面圖例展示了,我們對一個城市持續三次的調度演習,用戶量級也是逐步增多 2000W?4000W?清空一個城市.
演習的目的就是在于發現問題而不是秀肌肉,暴露的問題越多越好,每個問題都要完全閉環,幫助業務架構和運維能力持續優化與完善.
在海量用戶場景與復雜的互聯網環境下,全網調度要做到 調度用戶量精準與快速調度用戶,其實也是一個蠻復雜坑也蠻多的的事情,通過這9次的實戰演習,我們的調度平臺、業務架構、調度速率均還有繼續優化深挖的空間.這里并不是說單獨有一個很強大的調度平臺就可以了,而是一個環環相扣的閉環.
文章出處:高效運維(公眾號ID:greatops)
轉載請注明本頁網址:
http://www.snjht.com/jiaocheng/4398.html