作者 | 胡巍巍

出品 | CSDN（ID：CSDNnews）

是的，你現在正在用的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按鈕那樣直接，但是正如西方經典所講：「所見的是暫時的，所不見的是永遠的。」

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

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