歡迎光臨
每天分享高質量文章

以朋友圈為例,騰訊資深架構師揭秘鵝廠大資料平臺是怎樣運營的

導讀:本文將從構成運營成本的主要運營資源(設備資源、帶寬資源、專線資源)出發,以實際案例分別闡述精細化技術運營實施的要點。

需要提醒註意的是:精細化技術運營的標的是創造價值,而不是為了摧毀價值。精細化提升要註意把握度,切忌為了精細化而過於精細,掉入到鑽牛角尖的地步,反而可能導致得不償失。對於價值增加沒有幫助的精細化工作要大刀闊斧地砍掉。

作者:熊普江


2015年7月22日,微信朋友圈圖片顯示出現了“清帳”問題:即圖片都不能正常顯示,取而代之的是顯示一個粉色圖片,上面列有「清賬」兩字。雖然故障持續的時間只有短短幾分鐘,但影響面卻十分之廣,引發各種猜想。著名自媒體作者Fenng在公眾號“小道訊息”文章《微信居然也會缺少服務器資源,你信麽?》也提出該問題的討論。

問題產生的原因確認是少數服務器升級所致,但也反映出設備資源對業務的支撐十分重要,而且運營的精細化還沒有做得足夠好。如何保障業務發展需要,保障用戶體驗,同時又充分利用好資源,控制好運營成本,是設備資源精細技術運營需要持續探索的關鍵。

01 設備資源精細化技術運營要點

設備資源精細化技術運營的方法論與要點。這裡簡要回顧一下:

第一步:明確業務運行時的主要設備資源瓶頸所在

第二步:使用性價比最合適的服務器硬體機型來適配

第三步:從以下精細化技術運營評估點上逐個檢查評估:

  • 是否可減少不合理/不必要的呼叫請求量

  • 是否可優化減少呼叫層級或減少呼叫放大

  • 分配到服務器上的呼叫請求是否均勻

  • 是否可使用快取減少後端資料層的儲存訪問

  • 架構上是否使用了異步呼叫或協程訪問

  • 網絡協議是否恰當

  • 網絡收發包量是否合理

  • 操作系統或內核引數是否已做優化

  • 資料儲存的內容、格式/編碼、份數是否合理

  • 資料訪問是否存在冷熱

第四步:從管理策略與措施上進行提升,包括:

  • 是否可使用新服務區或長尾服務區進行業務新上線或下線管理

  • 容災備份系統或區域可否用於跑離線業務

  • 資源供給能力是否可進一步提升,降低容量的水位線

我們將通過多個業務實際案例來闡述上述設備資源精細化技術優化的應用。

02 微信訊息

微信收發訊息是微信產品的核心業務,也是使用設備資源量的頭部業務,因此對該業務功能的技術運營,具有重要價值。我們主要針對三個方面精細化:呼叫關係複雜、請求分佈不均,資源使用瓶頸不一。

1. 呼叫關係複雜

為什麼說呼叫關係非常複雜?微信訊息收發分為兩種情形,單聊與群聊。單聊指的是用戶A和用戶B之間發訊息,群聊是單用戶在群裡面對N個用戶發訊息。我們看相對簡單的收發單聊訊息過程(見下圖)

▲微信單聊訊息發送微模塊

單聊實際上有9個以上的步驟:發一條訊息,系統在後臺處理要處理9次以上。訊息連接接入,發送訊息的邏輯模塊,邏輯模塊之後鑒權(帳號存在與否、帳號屬性是否正常)、安全檢查(是否垃圾、是否有害等)、收訊息人檢查(通信地址本)、生成訊息序列號(確認不丟訊息及訊息有序拉取)、儲存訊息體、發送訊息通知、收取新訊息等。可見呼叫關係是非常複雜的。

因此,我們針對複雜的呼叫關係邏輯進行了優化,包括:調整RPC接口與後臺資料儲存,合併RPC呼叫;減少呼叫層次,縮減模塊;邏輯層引入強一致性快取,減少account/attr等模塊持久資料的RPC訪問;分離冷熱資料,減少對冷資料的RPC訪問等等。這些精細技術優化在2014年實施時,節省的設備量超過400台。

2. 請求分佈不均

微信訊息是多機集群處理的,如果負載不均的話,有些機器達到瓶頸時,有些機卻還很空,需要將請求均衡的分佈到機器上面。例如:訊息的KV儲存由按分號段儲存改為一致性hash,使得每機性能更均勻:原來是按號段儲存每機的負載很不均勻,而擴容是按最大負載的機器去擴容的;有些服務是串行處理的,例如優化容災架構,使用異步佇列進行IO優化。這些精細的技術優化在2014年節省設備近500台。

3. 資源使用瓶頸不一

訊息業務的每個key都放記憶體,海量key致使需多台服務器來存放資料,顯然這些服務器的資源瓶頸在記憶體上;適當將冷資料的key落地到磁盤上,可以縮小記憶體容量;同時考慮零散碎小模塊可以合併一起,使資源充分使用;而合併在一起儲存,就需要技術方法解決某個業務突變引起擴容。

另外,有些業務模塊則資源瓶頸的CPU或磁盤儲存上,甚至在不同的時間消耗的資源量不同,可以考慮資源混合與錯峰調度。

解決資源使用瓶頸及錯峰調度,2014年微信優化中節省服務器超過250台。

4. 其他的優化措施

操作系統優化及RPC框架性能改進。如原來微信服務器的操作系統層面單機性能比較差,每台機器只能處理不到100萬左右的訊息呼叫量,使用tlinux大幅將單機性能提升到近200萬。微信單機性能改進的優化於2014年中節省設備超過3000台。

服務器的容量管理,優化容量水位,提升快速擴縮容能力。

新業務服務區及長尾服務區的管理優化。設定業務進入或遷出新服務區或長尾服務區的請求呼叫量閥值標準。

03 朋友圈

朋友圈是微信里最為重要功能之一,幫助用戶向好友展示自己的想法與最近狀況,同時便於用戶瞭解好友的狀態、評論或點贊。朋友圈與收藏很相似,用戶資料也是永久儲存,不會刪除。

朋友圈的產品形態很特別。細心的讀者會發現,用戶發一條朋友圈,實際上是先在用戶自己個人相冊裡面存一條記錄資料;但同時會往該時刻、允許查看其朋友圈且未屏蔽該用戶的好友時間線上插一條索引資料

  

▲朋友圈時間線與個人相冊

也就是說朋友圈有兩個功能點:

  • 看所有自己發的朋友圈記錄,就是個人相冊,儲存了自第1條朋友圈以來的所有朋友圈訊息記錄。訪問的頻率相對不高,但這部分儲存資料,用戶一般很少刪除,它是持續增長的,這個儲存量是巨大的。

  • 我們平時刷朋友圈,即朋友圈信息流,按時間倒序,列出某個時刻,好友發了一條狀態信息(文字、圖片、視頻、圖文等),這就是時間線。只存放2000條索引記錄,儲存所需空間不會有太大變化,但用戶訪問頻率高,經常被掃清訪問。用戶如果要看2000條以外的好友朋友圈訊息,只能點開到某個好友的個人相冊才能看了。

朋友圈每天上傳圖片請求近10億次,上傳視頻請求近1億次。資料訪問超過5000億次/天,單機峰值訪問超過120萬次/分鐘。為確保資料可靠性與良好體驗,會儲存多個規格及儲存份數。因此,朋友圈的儲存體量及訪問量是非常大的,而且是永久儲存,隨時間推移,只會增不會少。這就有一個問題,如果都使用高性能儲存來服務用戶的話,服務器資源成本將會是天量。

技術運營團隊跟蹤運營資料發現,用戶看朋友圈的時候,訪問一天之內發的朋友圈內容,大約占了70%,一天之外內容被訪問次數大幅減少,當前1天之內的朋友圈內容儲存量只占總朋友圈儲存量的0.3%。90%以上的訪問請求的資料都在1個月以內,當前1個月之內的朋友圈內容儲存占總朋友圈儲存量的6.5%。

也就是說,朋友圈業務呈現訪問量大、資料冷熱非常分明的特點。需要將考慮將資料分成熱資料集群與冷資料集群,而且基本可以確定,熱資料集群的增長不會太明顯,增長主要在冷資料集群上。熱資料集群我們就用性能最好的設備,讓大家可以很快速訪問到所需的內容與資料;冷資料集群就使用價格低廉的多的大容量儲存設備。從架構上,除要支持按時間序列進行冷熱資料的遷移轉換,還需要支持用戶訪問的轉換。最終重新優化實現新的朋友圈資料冷熱分離儲存架構,如下圖:

朋友圈冷熱分享架構示意圖

這裡的熱資料集群,使用高性能SSD儲存機型TS8/TS80;冷資料集群使用高儲存量的SATA儲存機型TS6/TS60。

其中TS8/80 使用SSD盤,作RAID5的情況下,最大儲存量為2.4T,極限隨機iops可達到50000次,TB訪問量可達到2w次/s。

TS6/TS60使用機械SATA盤,每台機器12塊,單塊盤容量為2T,測試併發情況下極限iops不到200次。No Raid情況下總容量為24T,極限隨機iops為2000次。TB訪問量為100次/s。

單台TS6/TS60硬體的成本約為TS8/TS80的70%。但定義TB儲存成本為每TB資料儲存對應的硬體價格,則可知在磁盤完全利用的情況下,TS6/TS60的TB儲存成本僅為TS8/TS80的7%。滿足iops要求,磁盤不能完全利用情況下,TS6的TB儲存成本為TS8的15%。也就是說,冷熱集群的儲存成本,可節約85%的成本。

冷熱集群架構上,還有很多細節的技術優化點:如滿足時間序列的熱資料儲存結構優化(採用LSM Tree演算法);滿足冷資料平行擴容的冷資料儲存結構優化(採用單點串行寫入的一致性模型)等等。

04 大資料平臺管理

現在一般上規模的公司,都會建立公司統一的大資料平臺。騰訊也不例外,資料平臺部建有超大規模的資料處理集群平臺TDW(Tencent distributed Data Warehouse:資料倉庫),包括實時計算、離線計算等等,用於全公司的資料實時處理、離線分析、個性化推薦、業務計費等。

由於移動互聯網的發展,資料呈現爆炸性增長,同樣騰訊的TDW集群規模也迅猛增長。目前TDW單一集群能力已達2萬台。資料處理平臺的管理與利用,成為業務發展與成本優化管控的巨大挑戰。

大資料平臺的管理分為計算單元與儲存單元的管理。2016年以前,騰訊TDW集群從CPU利用率上看,平均達85%。集群儲存資料中,3個月內資料占比56%,6個月內資料占比70%,12個月以上占比16%;集群計算使用資料,73%為1個月內資料,92%為3個月內資料,12個月以上占比約2%。

在精細化運營方面,技術運營團隊實施的措施有:

首先定義了沉默資料。沉默資料是指一定時間周期內未被訪問的資料。如2015年8月,騰訊TDW中3個月以上至1年的沉默資料有25PB,1年以上的沉默資料有14PB。

其次,技術運營團隊強化了資料儲存的生命周期管理。管理規定要求:所有業務申請接入TDW的資料時,都需要填報“資料儲存周期”。通過生命周期管理及沉默資料差異化儲存,2015年前8個月僅增長23%的儲存量(見下圖)

資料平臺強化儲存生命周期管理

再次,通過監控大任務效率及清理無價值任務對計算單元進行優化。對於執行時間長、掃描資料量大的任務,實施主動監控並及時通知業務進行優化,必要時進行主動清理,確保平臺計算單元合理利用。在業務層面,清理兩類無價值任務:長期失敗任務與長期計算結果為空的任務(見下表)

無價值計算任務

定義及描述

長期失敗任務

兩周內失敗超過7

長期計算結果為空任務

入庫、計算、出庫任務連續10個周期的計算結果為空

獨立計算

不依賴入庫或其它計算任務且計算結果無其它任務依賴,計算結果不出庫

無價值計算

資料入庫後沒有被訪問,或計算結果出庫後沒有被訪問

無價值任務說明

在2015年前8個月時間內,通過監控大任務效率及清理前兩類無價值任務(18398個),已優化計算單元超過800個(見下圖)

清理無價值任務個數

對於計算單元的管理,除了無價值計算外,可以通過類似於域名管理的方法來監測計算任務的有效性。即:

  • 業務每申請增加一個計算任務,需要註明:用途、有效期(預設為6個月或1年)、主要責任人(任務開發人)、次要責任人(產品或運維)

  • 任務到期前一個月或一周,提醒主要責任人renew(續期)或放棄(刪除)任務。

  • 任務到期後一個月為贖回期,任務繼續運行,但每天提醒主要責任人及次要責任人。

  • 任務過期一個月仍不續期,該任務將暫停執行。

  • 任務過期3個月,該任務將物理刪除。

關於作者:熊普江,騰訊公司佈道師、騰訊雲高級總監,負責公司雲技術、解決方案佈道及技術架構評審等工作。自1997年涉足互聯網,曾服務美國Supreme、太平洋網絡、PPTV等互聯網公司,任網絡運營總監、運維總監等職務。逾20年互聯網從業背景,對大型網絡架構規劃與建設、海量用戶平臺規劃與運營技術支持、超大規模業務資源規劃與技術架構管理優化有豐富的經驗。

本文摘編自《技術運營》,大資料(ID:hzdashuju)經出版方授權發佈,如需轉載聯繫我們。


延伸閱讀《技術運營

點擊上圖瞭解及購買

轉載請聯繫微信:togo-maruko


推薦語:由騰訊資深架構師熊普江攜手海爾電器集團CTO盛國軍共同打造!詳細闡述技術運營的精細化方法及具體實施步驟,披露大量真實案例!多位知名架構師聯袂推薦!

更多精彩


在公眾號後臺對話框輸入以下關鍵詞

查看更多優質內容!


PPT | 報告 | 讀書 | 書單 | 乾貨

Python | 機器學習 | 深度學習 | 神經網絡

區塊鏈 | 揭秘 | 高考 | 數學

猜你想看

Q: 你瞭解運維嗎

歡迎留言與大家分享

覺得不錯,請把這篇文章分享給你的朋友

轉載 / 投稿請聯繫:baiyu@hzbook.com

更多精彩,請在後臺點擊“歷史文章”查看

赞(0)

分享創造快樂