騰訊雲運維乾貨沙龍-海量運維實踐大曝光（三）

時間 2019-12-06

標籤騰訊乾貨沙龍海量實踐曝光欄目騰訊简体版

原文原文鏈接

做者丨周小軍，騰訊SNG資深運維工程師，負責社交產品分佈式存儲的運維及團隊管理工做。對互聯網網站架構、數據中心、雲計算及自動化運維等領域有深刻研究和理解。

12月16日，首期沙龍「海量運維實踐大曝光」在騰訊大廈圓滿舉行。沙龍出品人騰訊運維技術總監、復旦大學客座講師、DevOps專家梁定安，講師騰訊手機QQ運維負責人郭智文，騰訊高級工程師魏暘，騰訊SNG資深運維專家周小軍出席沙龍，並帶來精彩的技術分享。爲了便於你們學習，特將本次沙龍講師的演講內容進行了整理。您也能夠在騰訊織雲公衆號下載本次演講PPT。前端

1、活動背景

運維有三座大山：大活動、大變動、大故障。這幾個運維場景是最消耗運維人力的。特別是大活動，很是考驗彈性能力，對運維自動化挑戰很大。數據庫

我今天所分享的主題就是深刻百億次紅包大活動的背後，解析騰訊運維的方法體系，瞭解織雲平臺如何幫助運維實現大活動高效運維，如何減小運維人海戰術。後端

過年你們都刷過微信紅包和 QQ 紅包，QQ 紅包的業務主要有幾種產品形態：刷一刷紅包、拼手氣紅包、AR紅包和空間紅包等。2016年跨年除夕這天有2.6億的在線用戶刷了729億次的紅包。這麼大的體量給整個架構體系帶來的衝擊是很是大的。緩存

今天將從」刷一刷紅包」的業務架構、活動背景、計劃擴容、壓測和演習、運維策略及活動現場這幾個方面來分享咱們的活動型背後的運維支撐工做，但願給你們在產品大活動時提供參考和幫助。服務器

挑戰

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

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

節前剛好遇到廠商內存供貨問題，服務器供應很是緊張，採購比原計劃延期了一個多月。甚至有個別型號的服務器到春節封網前一天才到貨。緊張的設備供給運維增長了擴容壓力。架構

2、活動計劃

2.1 日曆表

運維有2個月時間來準備和實施紅包活動，上圖是活動日程表。在肯定產品策略和活動方案後，12月進入資源採購流程，元旦先後進入擴容部署。併發

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

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

2.2活動梳理

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

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

3、擴容

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是多少，什麼機型，運營狀態，操做系統，監控等等。

變動具有交付後無論的能力。

報告根據變動和監控記錄，取得變動設備和變動對象列表，而後分析這些變動對象的監控數據，得出體檢結果。

體檢報告的檢測結果爲正常，需關注，異常。正常表示本次變動正常；需關注表示這次變動中有一些監控指標波動比較大，須要相關人員關注下，對業務自己沒有形成重要影響；異常表示本次變動形成了現網故障，須要當即回滾。正常的體檢報告不發送任何通知，需關注的體檢報告發送郵件通知，異常的體檢報告既發送郵件也發送短信通知。

檢查項大致可分爲兩類：基礎特性檢查項，業務檢查項。

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

體檢週期爲五、十、20、30分鐘。

7個檢查特性包括CPU、網外卡流量、內外網卡包量、CPU超過80%的設備數、自動化測試告警、模調告警等，並分別進行評分。評分爲0則正常，小於必定值則須要關注，總分大於必定值爲異常。

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

剛纔說過的傳統的擴容跟織雲擴容的對比，傳統擴容基於用 Excel 或 Word 來管理業務信息和資源信息，稍進步一點的用數據庫來管理。運維要登陸跳板機或總控臺，在總控臺用命令行或頁面跑各類安裝腳本，腳本之間須要人工確認。

好比說裝一個 MySQL，安裝完成之後要手工把IP、端口等信息粘貼到下一個腳本或流程來由運維繼續執行，腳本間沒有全流程概念，須要人工去更新信息。一個業務工程師同時只能作一個模塊的變動或擴容，若是併發同時作多個變動，極易出錯出現故障。

織雲高效的實踐是，它是以運維標準化爲基石，以 CMDB 爲核心的自動化運維平臺。經過 Web 界面的一鍵式上雲，基於業務原子任務和流程引擎，造成一個完整的運維流程，最後並行執行。一個模塊一我的5到10分鐘就能夠作完全部操做。

高效擴容的背後是基於一套標準化的理念。包括分層標準化、可運維規範、軟件標準化，而且標準化以 CMDB 落地。

在DevOps的實踐中，織雲在後面這二環。開發交付包、配置和模塊名稱，經過織雲完成部署。

咱們以 CMDB 爲核心，把資產配置、硬件配置、軟件配置、運營配置，好比說這個IP是在哪一個地方部署的，由於咱們有容災，還有權限的管理，咱們模組之間有管理，把這些配置都打包到 CMDB 裏面，經過引擎實現自動化發佈機制。到線上服務之後，後面還會有監控告警、一致性、變動體檢等等閉環的服務。從 CMDB 到線上服務，整個流程都是閉環的。

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

3.3 有狀態層的自動擴容

剛纔講到無狀態的擴容，如今是講有狀態的數據層擴容。一般來說，數據層擴容是 DBA 工做中工做量最大、最易出故障的變動。但在咱們這邊，數據層擴容已經實現了與無狀態層同樣的靈活性。

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

接入機擴容跟無狀態層的擴容方法相似。

存儲層經過數據搬遷，同時並行修改接入機路由表來實現擴容。

存儲層擴容的原理是，咱們首先把記錄 KEY HASH 1萬到桶，桶再分配到存儲機的存儲單元，一般是 1GB 一個內存存儲單元，一臺 64GB 內存的存儲機有56個存儲單元。

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

4、壓測和演習

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

4.1 紅包容量評估

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

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

4.2 紅包壓測

容量完成擴容先後，咱們會屢次對模塊和業務進行壓測，來評估容量基準值，擴容以後的水位可否支持到業務高峯。

咱們經過演習的方式來模擬實際的用戶請求。

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

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

這是有一個壓測出問題的例子，咱們在壓測的時候發現有一些存儲機的網卡流量被壓爆了，這是一臺網卡流量的巔峯，平時是 200-300Mb 的水平，到了壓測的時候壓滿 1Gb 的帶寬。咱們分析發現，這個是存儲器上有熱 KEY，而後咱們根據壓測出的狀況繼續推進各類優化。