《【運維專家大講堂】騰訊資深運維專家周小軍：QQ與微信架構的驚天秘密》要點：
本文介紹了【運維專家大講堂】騰訊資深運維專家周小軍：QQ與微信架構的驚天秘密，希望對您有用。如果有疑問，可以聯系我們。

社交領域一直是互聯網創業的大熱門,從PC到移動端,從OICQ、MSN到QQ.到了移動互聯網時代,社交領域應用開始徹底爆發,直奔黃金期.騰訊在過去幾年里,社交平臺更是火到爆,QQ和微信坐擁幾億的粉絲,QQ空間和朋友圈各種刷屏,寫心得,曬照片,秀視頻,那么誰來為企鵝保駕護航呢?支撐QQ和微信海量數據背后的架構又有哪些驚天內幕呢?本期大講堂的內容來自今年2月份ChinaUnix對騰訊社交網絡運營服務中心資深數據運維專家周小軍的專訪.本期訪談將從運維的視角,為我們揭曉騰訊社交產品前端到后端的故事.

Q1:?您好,很高興有機會采訪到您,我了解到您,您在天涯騰訊擁有非常豐富的運維工作經驗了,能否介紹下自己?分享下自己工作中的苦與樂?

A1:?我叫周小軍,目前就職于騰訊社交網絡平臺技術運營中心,負責社交產品分布式存儲的運維及團隊管理工作.

我在運維領域工作了十多年,算是一個運維老兵.剛畢業時我進入國壽當系統管理員,負責系統和業務運維,也做過業務系統開發.較早接觸了SCO Unix操作系統和Informix數據庫,還做了一些業務系統開發.后來感覺在國企沒有技術,沒技術挑戰,技術部門也不是國企的核心,于是工作一段時間后離開了國壽.

到了2002年,我進入天涯社區,主要負責網站運維.在天涯的職業生涯中,我從運維主管做到了云計算副總監,在此期間組建起了一支精銳的運維隊伍,包括系統、網絡、數據庫、安全和運維開發等運維小團隊.

隨著越來越多的網友涌向天涯社區,天涯流量開始突飛猛進了,我不斷推進網站的架構演進,從初始的二層架構發展到包括GSLB、LVS、Haproxy、Squid、應用WEB、數據緩存及數據庫等多層可擴展的架構,從ASP/MSSQL/Windows平臺遷移到JSP/MySQL/Linux開源平臺,從腳本化運維進化到了工具化運維,我們建設了一套包括資源管理、監控、告警、配置管理、自動部署等服務在內的運維管理系統,探索了虛擬化技術的實踐,保證了天涯從最初的日百萬PV演進到日億級PV架構.

有句話說得好,叫摸著石頭過河.在天涯十多年的運維工作中,我們也踩到了許多大坑：比如被幾倍出口的DDOS打了幾小時、服務器被入侵、域名被劫持、數據中心斷電、天涯拖庫、谷歌出走等大事件,還有許多員工犯下的人為致命錯誤.回過頭來看,當初踩坑多了,心理反倒變得極其強大,遇到大故障已如鋼絲一般冷靜,在反思總結教訓的基礎上不斷提升自己的運維能力.

回顧我在天涯的時光里,遇到技術上最大的困難是雙平臺并運行的問題,天涯從Windows遷移到Linux過程中,由于架構復雜、產品繁多、技術資源投入不足,整個遷移過程持續了數年.在這個過程中,運維團隊不得不在雙平臺上投入大量精力,比如開發運維工具要在Linux寫一套Python,在Windows上寫一套C#,運維精力很難兼顧.現在反思,有幾點經驗,希望做運維的伙伴們能夠共勉,做系統重構時必須要有堅定的目標,強有力的一把手決策,投入精兵強將小分隊,正確的說服老板,敢于血戰,經受短時間的劇烈陣痛.

2012年我進入騰訊負責社交產品分布式存儲運維,這里是亞洲最大的分布式存儲集群,上萬臺內存和磁盤存儲服務器分布在全國幾個區域的存儲倉庫內.每秒有幾千萬的數據讀寫請求,服務于QQ、空間、騰訊云、相冊和廣點通等海量業務.

與此同時,騰訊業務的海量數據給我們運維人員帶來了很大的挑戰,這些挑戰都是我們未曾經歷過的.我們不斷采用創新性的方法來解決這些難題,在存儲運維上開辟新的思路,不斷從效率、成本、質量和安全四個維度力求做得更專更精,不斷追求更卓越,非常給力地支持了業務的高速發展.

Q2: 騰訊在過去的幾年里,社交平臺火到爆,QQ和微信都已經擁有了幾億的粉絲,那么如何應對QQ空間海量用戶上傳圖片、上傳視頻、上傳文字等高并發負載?

A2: 針對文字、圖片和視頻的不同應用場景,我們提供了不同的存儲解決方案.其中有面向數據的NoSQL分布式存儲和關系數據庫,也有面向圖片的圖片存儲平臺,還有面向視頻的文件存儲平臺.

不同的存儲系統各有特點,NoSQL存儲注重高性能、低延遲和高可用,圖片和文件存儲量更注重低成本和數據安全.

騰訊NoSQL存儲由騰訊內部研發團隊開發,現在有基于內存和SSD二級存儲的CKV(Cloud Key-Value)、Grocery和Quorum_KV,有基于SSD存儲介質的TSSD等.

CKV主要服務于空間、相冊、騰訊云等互聯網業務,Grocery主要服務于QQ即通業務,Quorum_KV主要服務于微信消息業務.

經過精心設計的存儲單機性能可以達到每秒十幾萬次的讀寫,完全可以應對高并發負載.比如CKV的內存存儲采取了以下的設計思想以支持高并發能力：
1)內核態網絡處理模塊,以內核模塊形式提供服務；
2)大量運用zero-copy思想,在數據傳遞,編解碼時基本達到理論上的最少次數；
3)快速hash；
4)內存快速分配；
5)多隊列網卡；
6)處理器綁定；
7)自旋鎖；
8)存儲主機無磁盤IO的設計,備機才落流水和內存鏡像到磁盤.

Q3: 八年前,騰訊就開始在社交產品中應用到了NoSQL數據庫了,大家可以通過微信朋友圈或者QQ空間輕松自由地分享視頻、文字、音頻、圖片等,那么微信與QQ在架構上究竟有哪些相似點與不同點呢?
A3: 微信使用的NoSQL存儲名稱為Quorum_KV,是基于LSMTree研發的強一致性、持久化KV分布式存儲,支持key-table 和 string-value兩種存儲模型.

Quorum_KV通過Quorum協議實現雙向可寫功能,一個最小的存儲單元由二臺存儲機和一臺仲裁機組成,寫存儲機時經過仲裁決定被寫的機器.

寫數據時直接寫內存的Memtable表.Memtable寫滿后轉換成Immutable.Immutable定期Dump到本地磁盤變成數據文件,數據文件不斷遞增形成不同level級別數據文件,不同level級別的數據文件會定期合并.

內存表使用Skiplist來做內存的Key索引.
讀數據時先讀內存表,如果找不到記錄再尋找Immutable,然后是level 0磁盤文件、level 1……直至尋找到記錄返回結果.所以可以看到,Quorum_KV的設計是面向寫量大,讀量小的業務場景,很好地適應了微信消息寫量大的特點.

再來談談QQ,它使用的NoSQL存儲名稱為Grocery,屬于最終一致性,持久化KV分布式存儲,支持Key-value和Key-key-Row數據結構.
一個最小的存儲單元由二臺或多臺存儲主、備組成,主備可組成一主多備的鏈狀結構.數據寫入主后同步到備.客戶端可同時讀取主備,因此讀到備的客戶端會有一定的數據延遲,適合對數據一致性要求不高的業務.

數據的讀寫都在內存中進行,內存的Key采用多階HASH來索引,讀寫性能極高,但受數據容量受內存的限制.數據在主、備上都落盤,保證了數據的持久性.一個存儲集群可以支持業務混合存儲,業務Key采用一致性HASH方式分布.可以看到,和Quorum_KV不同,Grocery的設計是面向寫量、讀量均大的業務.

Q4: 從存儲的“五分鐘原則”可知,當數據五分鐘內被訪問一次,該數據不應存儲在硬盤,而應該存儲在內存中,對坐擁幾億用戶的QQ和微信等社交產品,可能要應對每秒幾千萬的讀寫請求,能否和我們分享下背后的集群是如何支撐起這種大規模的分布式存儲?
A4: QQ在線峰值高達二億多,每秒要響應幾千萬的讀寫請求,對分布式存儲的壓力非常大.傳統的關系型數據庫在高性能、分布式方面存在一些瓶頸,很難適應QQ海量業務場景所帶來的挑戰.

如我之前說提及的,騰訊的NoSQL存儲系統經過精心設計,已經能夠應對海量數據的高并發、高可用、低延遲的應用場景,由幾百臺存儲機組成的存儲集群可以輕松扛起數百萬的讀寫并發.集群的性能具有線性擴展,集群最大可以容納到幾千臺存儲服務器.當然如此龐大的集群,相應地也會帶來管理上的復雜,因此我們的一個集群不會超過1千臺服務器.

在集群中,記錄通過一致性HASH、號段范圍或HASH取模等方式,均勻分布到后端的數百臺存儲設備.存儲前端采用存儲代理,屏蔽了應用對存儲的直接訪問,數據在集群擴展或收縮的過程中,通過代理的自動尋址保證了業務無對存儲的無損訪問.業務數據從1臺存儲擴展到100臺存儲,只需要數分鐘即可完成,在此過程,業務是無感知的.

此外,應對存儲集群的運維,我們還有強大的存儲調度平臺,可以保證集群中的代理和存儲做到平均水位,避免有的機器忙死,不斷應對高負載的壓力、而有的機器應對低負載,出現閑置等問題.

最后,針對存儲的內存問題,我想補充一點,業務的數據具有冷熱區域,存儲系統把熱數據保存在內存中,冷數據保存在SSD盤中.淘汰系統通過KEY的過期時間自動把冷數據從內存淘汰到SSD盤,以釋放內存空間.當冷數據第一次從SSD盤讀取后會自動上升到內存.

Q5: 在國內網絡環境下,單機房的可靠性無法滿足大型互聯網服務的要求,如機房掉電,光纜被挖的情況也發生過,微信和QQ有沒有出現過服務器宕機的時候?您們當時是如何應急處理的?有沒有更好的容災機制來確保高可用性?
A5: 早期的QQ在單IDC時代,的確有過光纜被挖斷、甚至城市運營商出口故障導致服務中斷數小時的大故障.現在騰訊已經建設起成熟的海量服務運營體系,面對單機房的可靠性采用了全網調度理念來解決跨地域之上的高可用性.

首先是SET標準化.SET是標準業務部署模塊,接入層、邏輯層和存儲層標準化成不同的SET.

每個SET內都有固定數量的服務器和標準服務容量.譬如,上海XX接入SET設計容量XXX萬用戶,當前用戶數為XXX萬,離警戒水位還有XX%,XX小時后可進入擴容點.

SET都具有自動化部署能力,幾百臺服務器的SET部署時間小于10分鐘.SET按單元分布在不同城市之間.每個重點城市都會部署許多套接入SET,邏輯SET和存儲SET.

第三,SET間、城市間、區域間都具備全網調度能力.用戶到接入SET的調度通過GLBS來切換,譬如接入SET會有許多個VIP,通過域名服務變更VIP就可以把用戶請求從天津切到上海.

接入SET到邏輯SET,或邏輯SET到存儲SET的訪問則通過內部名字服務系統來切換.這樣當任何一個IDC或某城市出現問題時,運維人員通過調度可以在幾分鐘內把流量切到正常的SET,甚至可以通過調度系統做到自動化切換.

第四,存儲層的多地同步.存儲層會在三地以上部署多套,譬如華南、華中和華北各部署一套存儲SET.有寫請求時先寫華南SET,寫成功后通過同步中心把數據同步到華中和華北SET,通過最終一致性保證數據保存在多地存儲.數據在三地同步最長時間才幾千毫秒,因此用戶對數據的不一致基本無感知.

最后是系統的柔性策略.柔性可用即對服務進行分級,當系統變得不可靠的時候,優先提供重要優先級的服務.比如節假日用戶大量訪問相冊出現流量峰值時,突然出現某機房核心專線故障,柔性系統會把相冊從全尺寸圖片瀏覽模式切到縮略圖瀏覽模式,以減少圖片的拉取,降低帶寬流量,減少壓力.

Q6: 在朋友圈的相冊、QQ空間的相冊里,或多或少會有一些個人隱私的數據,一旦丟失,后果很嚴重,那么它們對應的服務器集群是如何來確保數據的備份與安全性?
A6: 分布式存儲系統都具有主備雙機或主備多機架構.備機把更新流水落本地硬盤,并定期把內存鏡像到磁盤.后端有統一的冷備系統來保存備份數據.因此數據的安全性是非常強的.

關鍵業務還有三地以上的存儲SET同步,實現跨城容災.
圖片保存在分布式圖片存儲系統中,同樣也會保存三份以上的副本,并且有跨地域的容災副本.

Q7: 您在互聯網行業積累了十多年的運維經驗了,對很多朋友來講,要想成為一名優秀的DevOps工程師,在成長道路上,您有哪些心得經驗分享?
A7: 在運維道路上,我的切身體會比較多,簡單總結一下主要有以下幾點：
1、堅定的目標
目標是職業生涯遠處的燈塔,它能沖破迷霧,讓你在迷惘中堅定信念和方向.要想成為一名優秀的技術專家就要牢牢樹立你的目標,持之以恒,每天一點一滴地前進.

2、運維服務能力
餐飲業的海底撈以服務口碑得到顧客的認可.同樣,運維人員做為支撐服務部門,也要通過服務來獲得用戶和業務的認同.我們要以超出用戶預期的目標來為用戶和業務提供服務.

可能有人要問,我們是技術人員,為什么要特別強調服務能力?我覺得技術運維的團隊目標不是提供功能的業務,而應該是提供持續化的服務能力,如資源交付能力,變更能力,可用性能力,調度能力等等,讓業務如同水和電一樣使用我們的服務.在這些服務能力的背后需要長時間的建設和積累.
例如傳統的DBA團隊重在技術支持,而我們數據運維團隊除了技術支持之外,提供專業的服務已經成為團隊的核心目標.
在服務能力上要致力于做到超出用戶預期.什么是超出用戶預期?就是用戶期望得到五星的服務,而你能給他們提供到六星的服務.

要獲得超出預期的服務,我認為要做好以下二方面：
1)主動服務
在我們運營中心,有句口話為“服務用戶、服務業務、服務自己”,也就是說在做事時要考慮,我們的服務目標是誰.我們在制定目標和方向的時候不能只考慮到自己,要把眼光放得更長,看到業務,看到用戶.
這里有一個例子,業務在申請設備資源時,按部就班走硬件成本資源采購是B級服務；通過虛擬化技術把設備申請從周提升到小時是A級服務；在虛擬化技術之上通過調度能力保證業務上線后,能根據實際流量實現人工或自動化的資源伸縮,即節省了成本,提高業務部署速度,還提升了運維能力,這就是S級超出預期的服務.

2)提供超出預期的服務,還要主動站在用戶角度替用戶思考,給用戶帶來價值,實現多方共贏.
譬如我們在設計代碼發布系統時應該要思考,發布系統的初步目標是減少了運維團隊的工作量,同時也提升了應用團隊的發布效率.但通過更深入的思考我們還會發現,如果具備灰度發布能力,我們可以做到對用戶無損.發布過程中引入自動化測試,我們可以保證了應用的可用性.通過多隊列服務和生產者/消費者模式,我們可以瞬間完成數千臺服務器的發布,等等.做這些事情時,站在多方面來思考會讓運維工作變得有價值,而不是背黑鍋的角色.

3、一萬小時的專業技術積累和豐富的實戰
丹尼爾在《一萬小時天才理論》提出一萬小時定律,即要成為某個領域的專家,需要積累一萬小時,如果每天工作中花在學習和實踐上的時間達到4小時,那么成為一個領域的專家至少需要十年.

因此我們在工作中要善于利用時間,盡量保證20%的工作時間用在提升專業能力和運維效率方面.即使是加班時間也要把時間用在提升效率的工作上,避免加班仍是做重復性而無技術含量的事情.

“紙上得來終覺淺,絕知此事要躬行”.要把技術運用得弓馬嫻熟,武藝精通,就得把知識落地,應用到實踐中,在工作中不斷提出新想法,勇于嘗試新事物,不斷給自己新的挑戰.

4、不斷打破心理舒適期尋求突破
工作到一定程度后就會進入心理舒適期,這是讓人感到熟悉、駕輕就熟時的心理狀態.這個時候就要勇于打破心理舒適期,從這個方面去突破自己的天花板.

打破心理舒適期就要保持自我動因,譬如對技術的熱愛,保持強烈的好奇心,給自己設立中長期目標,對工作和事業的自我驅動力等.

在突破的領域上,運維人員不僅只是局限于運維技術層面,在溝通表達、項目管理、業務、產品、開發等方面都要獲得成長.

打破舒適期甚至要勇于跳離舒適的崗位、穩定的公司,尋求更好的職業發展平臺,這樣才把保證自己的價值不斷獲得增值,打破“IT只是吃青春飯”的悲觀宿論.

5、開發能力
運維自動化有三個階段,腳本化是第一階段,工具化是第二個階段,產品化是第三個階段.運維人員要掌握開發能力,來提升運維效率,解放運維生產力.

運維的開發語言可選Python、PHP甚至C/C++等.有些優秀的運維人員可能是全棧工程師,從前端到后端,從WEB開發到后臺開發都可以自己解決.

除了開發能力,運維人員還要深入了解運維需求和業務需求,規劃設計具有前瞻性的運維產品,用產品的理念來做運維系統.優秀的運維系統需要具備出色的用戶體驗,并通過模塊化、松耦合的設計,方便其他工程師在平臺上的二次開發,以提升運維開發效率和運維效率.

好的運維產品可以開源出來,回饋業界,為外界弱小的運維團隊提供更大的幫助以及貢獻度.

精通開發還便于理解業務,和開發一起共同推動業務架構的優化,成為開發的緊密合作伙伴.

具備開發能力還可以讓運維工程師掌握進入系統內部的鑰匙.運維工程師通過閱讀Linux內核源碼、MySQL源碼或者Redis源碼等,能更深入掌握操作系統、數據庫和網絡框架等服務的運行機制,根據業務特點改寫功能特性,使之更能符合業務需求.好的特性還能回饋提交社區,以結合到下一個版本中.

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