【驚】騰訊：3億人次的實戰演習，如何做到絲般順滑？

作者介紹：

李光

現就職于騰訊SNG社交網絡運營部，負責SNG移動類產品的業務運維，同時也負責運營平臺規劃與運維產品運營推廣工作

前言

社交網絡事業群擁有眾多海量規模的業務，在海量的運營壓力下，服務器設備的數量也突破了10w大關，并有序的分布在全國不同的IDC中實現異地容災的高可用架構。

但正因為社交業務的多IDC管理的復雜性，使運維小伙伴們經常會遇見一些難搞定的場景，如運營商網絡出口異常流量驟降、網絡延時突增、IDC斷電斷網、光纖被挖斷等突發事件，假設沒有第一時間發現和處理好這些事件，就會有較大的機率影響騰訊社交產品的服務質量，甚至會造成用戶大范圍的登錄與訪問中斷。

如何在種種不可控的突發情況來臨時，業務能在用戶“零感知”的情況下第一時間恢復服務質量呢？這就需要我們的業務要有健壯的異地容災架構與快速的全網調度能力。

本文介紹的是手機QQ與Qzone兩個服務于海量用戶的平臺級業務，在無損用戶服務質量的基準原則下，通過億量級人次的限時調度實戰演習來驗證我們的異地容災架構與快速調度能力。

• 三地三活的容災能力

• 風馳電掣的調度能力

• 3億人次的實戰演習

一、三地三活的容災能力

海量服務之道就是要給億級用戶持續提供高質量與分級可控的服務，所有的研發與運維行為都應該圍繞保障與提升用戶服務質量展開，面對種種不可控的突發情況時，恢復業務的服務質量為最高優先級要務。

讓我們把時間撥回一年前，2015年8.13日天津爆炸事件，相信很多的互聯網從業人員都印象頗深，騰訊天津數據中心距離起爆點直線距離僅一公里，可能會受到波及，華北7000多萬QQ用戶將面臨著登陸和訪問中斷的可能，那天晚上我們通過多次調度與柔性控制，在用戶“零感知”的情況下，順利的將天津全量用戶調回深圳。

容災能力是服務于業務，隨著業務的持續發展。現在我們的整體容災架構是三地分布，三地三活，在各業務分布上實現set化部署，鏈路均衡分布，完善容量架構，從而減少風險。

QQ與Qzone的容災能力演進主路線也是 單地—>雙地—>三地 ，三地分布也提升了服務質量，方便用戶更加的就近接入。

1. QQ與Qzone 用戶數據三地均勻分布 1：1：1；

2. 單地常態負載不高于66%兩地容一地，可在用戶“零感知”的情況下，將用戶調往三地之一；

為了行文方便，后續出現“雙平臺”字眼時，如無特殊說明均指“QQ+Qzone”的統一體。

二、風馳電掣的調度能力

對于調度用戶，一般都是從流量入口即接入層分流用戶，雙平臺也沿用與此思路。

1. 手機QQ接入層

前端支撐手Q 2.59億同時在線用戶，后端連接幾百個業務模塊，接入層上千臺機器主要分布在三大城市的數十個IDC，每分鐘處理20多億個業務包，7*24小時不間斷為億萬用戶提供著穩定的接入服務……這就是手Q接入層SSO。

手Q終端與SSO之間并不是直連的，兩者之間還加入了TGW，TGW全稱是Tencent Gateway，它是公司內部自主研發的一套多網統一接入，支持負載均衡的系統；它具有可靠性高、擴展性強、性能好、抗攻擊能力強等特點。加入TGW后終端與SSO、后臺之間的關系如下圖所示：

QQ用戶登錄概要流程如下圖所示：

Qzone的主要流量入口來自手Q，因此雙平臺用戶可以聯動調度。

2. 調度能力介紹

調度動作概要來說就是干預用戶的接入點，下圖是一個非常概要的流程：

根據業務發展的推動與場景的細化，雙平臺的調度能力主要為兩個方向。

測速調度：

• 全網網絡質量的最優路徑測算；

• 實時干預能力即將用戶調度到最優路徑上；

• 更細力度調度 如按網關ip調度；

重定向調度：

• 禁用VIP新建客戶端鏈接；

• 將原VIP已登錄用戶重定向到新VIP；

在對后臺無沖擊壓力的情況下，我們可以完成 千萬在線用戶10分鐘之內調度完畢 ，并且在調度期間用戶無感知 ，上圖就是我們在單次調度時清空一地在線用戶數的下降速率。

調度場景：

• 三地用戶常態分布比例選用全網質量測速調度；

• 緊急事件時選用快速的重定向調度方式；

• 非極端情況下不會選用跨運營商調度，例如將電信用戶調往聯通；

調度操作：

• 分鐘級完成調度配置，并實時計算下發；

• 全自動化估算三地容量變化；

三、3億人次的實戰演習

我們先來看兩個場景，相信這兩個場景運維小伙伴或多或少都可能經歷過。

故事場景1：

某個電閃雷鳴、風雨交加的夜晚，運維小哥正舒服的窩在床上看著電影，突然手機一波告警襲來，N個服務延時集體飆高，經排查是運營商網絡出口異常，運營商也暫時未能反饋修復時間，經評估后快速根本的解決方法就是將故障城市的xxx萬用戶調度到B城市，運維小哥正準備使出洪荒之力乾坤大挪移的將用戶移走，但杯具的是調度系統掉鏈子了，調度任務計算與下發異常，極速吼上相關同學排查調度系統問題，同時開啟后臺柔性撐過故障期。

故事場景2：

活動開始，用戶量逐步攀升，并且有地域聚集現象，A城市的整體負載已經偏高了，需要遷移XXX萬用戶調度到B城市，以便減少A的整體負載，在調度過程中發現B因某條業務鏈路的短板，所能承載的增量用戶要小于前期建設評估的整體用戶量，增量壓過去，會把B壓垮。

上面兩個場景，直接折射出問題是什么？

只有通過實際場景檢驗的能力，才是我們運維手里真正可用的武器，而不是在軍械庫里放著，只是在盤點的時候“具備”的能力。

1. 為什么要現網演習？

容災能力與容量架構把控是海量運維必修內功，能力的鍛煉就是要通過不斷的實戰演習得來，要讓我們所“具備”的能力變為關鍵時刻的武器。

如上圖所示，通過一個完整的閉環流程，來不斷的精耕細作以便提升我們的能力，通過實戰將問題暴露出來，避免緊急事件時的被動。

2. 如何規劃演習？

QQ是一個體量非常之大的業務（DAU:8.3億），業務功能樹復雜，一個葉子節點的異常就有可能導致大范圍用戶的有損體驗與投訴。假設演習期間某個環節有問題，將有可能導致一個大范圍的事故。

我們在思考如何安全落地演習的時候，也主要基于以上緯度的考慮。話說不打無準備的仗，事前評估越完善，相應的就能提升我們整體演習的成功率，下圖就是我們最終落地的一個可執行的詳細演習流程圖。

如上圖所示 演習也是一個節點較多的閉環流程，生命周期主要分為以下三部分

• 演習前期規劃與準備；

• 演習實施，過程監控；

• 演習結束，整體質量評估與問題跟蹤；

3. 演習的目標

要通過演習生產出我們所需的數據與檢驗我們的業務質量，雙平臺是服務于海量用戶，全網業務鏈路復雜，我們期望能從下面三個維度檢驗我們的能力。

驗證業務質量與容量：

• 通過實戰演習驗證三地條帶化容量建設是否符合預期？

• 每增加千萬用戶時整體與關鍵業務鏈路負載是否可控？

• 短時間內因千萬用戶集中登錄與關聯行為所產生的壓力后臺是否能抗的住？

• 柔性控制是否符合預期？

量化調度能力：

• 異地調度時每分鐘能遷移走多少用戶？

• 異地調度1000W用戶需要多少時間？

• 清空一個城市的用戶需要多少時間？

• 調度速率是否均衡穩定？

運營平臺：

• 現有的平臺能力(實時容量、地區容量、調度平臺、業務質量監控)是否能較好的支撐到演習與實際場景調度；

• 發現平臺能力的短板，以容量指標來及時度量調度的效果；

4. 演習效果

我們堅持月度/季度的實際演習調度，并在業務峰值實施調度演習。整個演習期間用戶“零感知”，業務質量無損，無一例用戶投訴。如此量級的演習在雙平臺的歷史上也屬于首次。演習也是灰度逐步遞進的節奏，下面圖例展示了，我們對一個城市持續三次的調度演習，用戶量級也是逐步增多 2000W?4000W?清空一個城市。

演習很重要的參考指標便是投訴量。結合輿情監控“天王星”系統的數據，可以高效的監控外網用戶投訴量在演習期間的變化，確保對用戶無影響。 九次的實戰演習，沉淀了較多的準確的數據，與標準化的調度規范，且隨著運維調度能力的工具化，后續的演習由一個運維同學即可完成。

固化能力，演習例行化：

• 時間緯度： 月度常態演習，每次演習量級在4000W—8000W之間；

• 場景緯度： 聯合網絡運維一起演習，模擬城市級別突發斷網的場景；

5. 演習質量評估

如何評估演習的質量，一般來說可以主要從下面兩個緯度評估

• 調度質量

  • 調度效率是否符合預期：例如計劃10分鐘遷移多少用戶量；

  • 調度速率是否可控：調度的用戶量細化到分鐘粒度應該是基本均等，不能忽快忽慢；

  • 調度量級是否符合預期：整體遷移用戶量級穩定可控；

• 業務質量

  • 調度期間是否有用戶共性投訴反饋；

  • 后臺服務質量是否可控；

  • 監控系統是否有批量告警；

  • 業務負載增長是否符合預期；

6. 演習流程的閉環跟蹤

演習的目的就是在于發現問題而不是秀肌肉，暴露的問題越多越好，每個問題都要完全閉環，幫助業務架構和運維能力持續優化與完善。

總結

在海量用戶場景與復雜的互聯網環境下，全網調度要做到 調度用戶量精準與快速調度用戶，其實也是一個蠻復雜坑也蠻多的的事情，通過這9次的實戰演習，我們的調度平臺、業務架構、調度速率均還有繼續優化深挖的空間。這里并不是說單獨有一個很強大的調度平臺就可以了，而是一個環環相扣的閉環。

 

 

來自：http://www.greatops.net/?id=40