CSDN

訂閱

發行量:967 

20 萬台 QQ 伺服器全面上雲

作者| 胡巍巍是的,你現在正在用的QQ,已經是「雲上QQ」!截至目前,QQ已經把所有業務,都搬到了騰訊雲上。

2020-01-18 00:09 / 0人閱讀過此篇文章  

作者 | 胡巍巍

是的,你現在正在用的QQ,已經是「雲上QQ」!

截至目前,QQ已經把所有業務,都搬到了騰訊雲上。

20多歲的QQ,把近20萬台伺服器上雲,過程之艱難,堪比「把大象搬到雲端」。

這麼難的事兒,騰訊為啥要做?

事情要從2018年騰訊「930調整」說起。

如果你熟悉騰訊的開發工具,就會發現他家框架超級多。

以至於在騰訊內部論壇上,經常有新人問,這麼多開發框架,到底該用哪一個?

騰訊內部也流傳著這樣一個故事,一個從騰訊互娛BG轉崗到微信BG的程式設計師,竟然發現他需要重新熟悉開發框架。

此外,「930調整」之前,騰訊很多基礎框架,也沒有進行內部開源,很多部門間的代碼,都是相互封閉的。

因此,「930調整」後,騰訊啟動開源協同和自研業務上雲兩大業務方向。

過去一年,不僅是對內開源,即便是對外開源,騰訊也堪稱「瘋狂」。

而在自研業務上雲方面,騰訊拿自家元老級產品QQ試水,其決心可見一斑。

QQ成功上雲後,工程師們發現,業務研發效率更高了,從前開發一個產品需要很久,現在哪怕是從0到1開發一個新產品,也只需要短短一周。

其次就是,工程師的自我價值得到了更大體現,當看到自己開發的組件,上傳到雲上成為一種被很多人使用的服務,那種自豪感油然而生!

更重要的是,QQ上雲讓騰訊雲積累很多寶貴經驗,這些經驗對整個雲計算行業,都大有裨益。

那麼,QQ上雲過程中,就遇到過哪些困難?又是怎樣克服的?

1月13日,CSDN採訪了騰訊云云伺服器副總經理李力,力圖為你揭曉QQ上雲的那些事兒、以及騰訊雲背後的技術。以下為經過整理後的部分採訪實錄。

關於QQ上雲

CSDN:QQ本身有二十多年歷史,它是有一定歷史技術包袱的,技術架構和雲架構的適配難度也更大。那麼,QQ上雲的過程中,遇到最大的困難是什麼?騰訊云云伺服器副總經理李力:遇到的問題主要是,QQ對性能和成本的要求,在某些場景下對雲會有一個衝擊。QQ業務的特點,在於它是海量用戶互相訪問的過程,這個過程既不可預測,很難做一個良好規劃。CSDN:那麼是怎麼克服困難的?騰訊云云伺服器副總經理李力:回到雲本身的基礎架構來說,如果要簡單區隔雲和物理機房,就得儘可能通過軟體定義,這樣才能讓雲具備更好的靈活性。

在具體內網的通過性上面,我們對所有的網絡流量和網絡關係,進行了軟體建模。所以我們給QQ的每一個連接和每一個包,都做了軟體層面的轉發。

這種情況下,雖然UDP(用戶數據報協議,User Datagram Protocol)沒有連接,但是在軟體定義裡面,有一個虛擬連接。並且,我們也會把建立連接的過程變成可控的,建立好之後,數據包就會不斷發送從而形成數據。

早期我們更傾向優化數據的性能,因為大部分情況下,都是數據包建立好之後,工程師們再去進行數據傳輸。但在QQ裡面,並不完全是這樣。

由於QQ通訊裡面,會建立大量臨時的UDP訪問,而這也變成QQ上雲之後的性能瓶頸。而這個非常小的性能瓶頸,可能會導致成本急劇增加。

那麼,如何解決?在早期面對QQ場景時,我們會先把資源做補充,但是這樣就會失去成本優勢。後來,我們的研發團隊和虛擬化團隊花了很長時間,在具體細節方面做了很多工作,最後終於以一個非常合理的資源和成本,滿足了QQ群的業務要求。

以應對依賴和容災問題為例,大家都知道,上雲需要進行灰度遷移,而遷移時不可避免地會造成自研機房和雲機房的帶寬穿越,為此,工程師們需要提前評估自研機房到雲機房所需的帶寬。

假如使用城市方案,專線帶寬應該跟現有的三地部署方案對齊(CSDN註:QQ伺服器分布在天津、上海和深圳三地)。那麼,QQ核心系統大概需要幾十G的帶寬。

假如採用IDC(Internet Data Center,網際網路數據中心)方案,QQ裡面有很多業務,使用的是有狀態的尋址方式,因此得把同城內的機房全部打散訪問(類似一致性哈希)。

為此,工程師們評估了自研到雲機房的帶寬,評估之後發現支持QQ幾大核心系統(接入、消息、狀態、資料、關係鏈、登錄)所需要的帶寬為N。

而所有QQ基礎功能都遷移到雲上,則至少需要2N的帶寬。考慮到容災問題,工程師們實際上拉了兩條專線互備(防止專線被挖斷形成孤島),即為QQ上雲專門搭建了4N的帶寬專線。

關於VStation對於QQ上雲的加持

CSDN:有報導稱,騰訊雲分布式調度系統VStation,可以把成千上萬台伺服器的管理,做到像管理一台伺服器那麼簡單,這個過程是怎麼實現的?騰訊云云伺服器副總經理李力:騰訊的技術理念跟QQ微信是一脈相承的,也就是說我們想要解決的是海量高並發的業務場景。如果只去看管理成千上萬台物理機這麼一件事,它跟管理一台物理機,其實沒有太大差別。

所以,我們一開始思考這個問題時,主要思考的是如何通過一個自研系統,去調度整個雲機房內的物理機,讓它能夠生產和調度虛擬機。

而騰訊的VStation,跟其他系統不一樣的地方,在於我們特彆強調可擴展性和高可用性。比如,原來調度一台機器,現在要調度一百台、一千台,這看起來是無限可擴展的,似乎只需要把這個腳本在一台機器上執行、或者到一千台機器上執行就可以。

但這裡面最大的問題在於,我們想要做到讓它像一台機器一樣,它就一定要快。可是在大規模集群里,一個很大的問題在於它很難快起來。

雲的系統比較複雜,它包括計算網絡存儲、監控、安全、周邊的管理系統和機房的DCS系統(Distributed Control System,分布式控制系統)。

所以,整個雲計算系統看起來只是在做一些運維調度,但是要牽涉到上百個模塊的協同,然後還會牽涉到幾千上萬台物理機的分布式通信。

所以我們在可擴展上面臨的挑戰,就是很有可能在一台機器上執行的操作,會在機器規模提高之後變成線性的時間增長。

而如果我們無法接受線性時間增長,它就不能像機器的簡單擴容一樣把這個系統做好。這裡面還有一點在於,假如我現在要創建一台虛擬機,我應該選擇哪一台物理機來作為它的溯源機?

這個過程非常複雜,如果只考慮單次的調用是很簡單的,我只需要拿到全部信息,然後想辦法在一個單點計算一下就可以。但是我們的場景,很有可能同時迎來很多請求。

因此,我們做了很多技術優化,目的就是儘可能地有更多的執行體,並讓每一個執行體都有更多調度輸入。

而每一次調度時,因為全部信息隨時在變,我拿到的是隨時在變的全部信息。然後,我們會在這些信息里,挑選出足夠多的、並且打分也比較高的資源池,然後再做一個隨機排序,再加上一些哈希算法,從而避免伺服器之間的碰撞。

另外,當模塊數量特別多的時候,所有主業之間的通信都會面臨問題。比如,開源系統規模越來越大時,它會面臨一個典型問題:即一旦它的消息發出去之後,一旦中斷或者處理異常,就會加大運維過程的難度。

因此,我們在一開始設計微原生雲系統時,所秉持一個核心思想,就是把通信和業務割裂開。

但是我們不用Service Mesh(服務網格),而是把整個業務按照簡單的原子接口方式去實現,然後通過Search Flow(搜索流)的概念,把它組合成一個有效而完整的DAG(Database Availability Group,資料庫可用性組)。

再在通信框架和後台框架里,把這個有效而完整的圖做優化,從而讓它儘量並行,最後在有效完整圖里做一個回顧。

也就是說,我在某一個地方吃飯,這個地方會自動按照圖的逆序回過來,並能把原來做的章數清理掉。這樣就實現了大型分布式系統裡面的事務概念,最終實現集群規模的增加。

有了這樣的能力後,我們在QQ上雲的過程中,主要面臨的問題就是性能調優。可以說,騰訊雲的整個調動框架,已經接受過騰訊超大的業務考驗,所以現在的集群規模在實驗室環境下,已經擁有管理上百萬台物理伺服器的能力。

採訪手記

偉人曾言:「不破不立。」

2018年騰訊「930調整」,曾在業界引起巨大反響。如今回頭來看,改革的結果非常成功。

如果說這次調整,有哪些代表作,QQ上雲一定是其中之一。

今天的你我,都在享受QQ上雲後的好處,它或許不像點擊一個App按鈕那樣直接,但是正如西方經典所講:「所見的是暫時的,所不見的是永遠的。」

芸芸眾生里,一個工程師名字和容貌,很難被記住。

但他們的產品,能被很多人使用,也是一種記住。





文章標籤: