Categories
程式開發

QQ 是如何完成20萬台服務器全量上雲的?


截止到目前,QQ所有的業務都已經遷移到了騰訊雲上。

2019年1月4日,騰訊技術委員會正式成立,同時下設了兩個項目組“開源協同”和“自研上雲”。現在,作為騰訊自研上雲的先行軍,QQ已經率先完成了全量上雲。

QQ業務場景有哪些特徵?全量上雲的整體節奏是什麼樣的?遷移上雲的難度在哪裡?關鍵過程有哪些? …為了解開這些謎題,我們採訪了參與QQ全量上雲的多位技術專家。

QQ的業務場景

突發+群發是最恐怖的場景。

QQ是一個典型的社交產品,社交場景的主要特點就是會有裂變的情況,比如如果一個消息是發在群裡的,雖然看起來只是一條消息,但從送達的角度來看,可能會翻百倍。另外,一條消息不是一次發送出去就完事了,有時還會互相轉發,轉發給另一個人,甚至是另一個群。由於QQ使用的是UDP,所以即使是在勻速發包的情況下,也會比騰訊雲上其它的大客戶大N倍。

然而,這還不是最恐怖的是,騰訊雲原生架構總經理肖世廣表示:“最恐怖的情況是,在突發的情況下,發生大規模轉發的情況。即使是在雲的場景下,也不可能準備如此多的資源,所以在上雲的時候,我們做了很多方面的優化,例如計算、存儲、網絡等等,除了提升雲性能,更重要的是要降低成本。”

QQ全量上雲的整體節奏

2018年9月30日是QQ上雲的一個重要節點。

“930”調整之前,騰訊集團內部其實已經在做很多上雲的嘗試,部分服務也已經跑在雲架構上了。 “930”調整之後,騰訊內部做了很大的變革,不僅成立了新的雲與智慧產業事業群,同時啟動了“開源協同”和“自研業務上雲”的兩大戰略方向。在此背景下,QQ上云成為了勢在必行且迫在眉睫的事情。

  • 2017年,所有QQ用戶是在私有云上;

  • 2018年年底,15%的QQ用戶從華南區遷移到廣州雲;

  • 2019年6月,30%的QQ用戶遷移到公用雲上;

  • 現在,QQ所有用戶全部遷移到公用雲上;

QQ 是如何完成20萬台服務器全量上雲的? 1

據了解,目前QQ的雲中架構是“三雲一地”,所有用戶分佈在華北、華東和華南三大區域,其中華南區域又分為廣州雲和深圳自研機房兩大機房。每個區域都是完全獨立的存儲和業務邏輯服務,華南的整個用戶都都可以調度到華北和華東區,業務可以隨時在不同的雲區域和自研區域之間來回調度。

上雲的方式

由於之前QQ有些服務是在本地和私有云上,所以在上雲過程中避免不了要做改造。據了解,QQ上雲的方式共有三種,分別是先改造後上雲、邊改造邊上雲,以及先上雲再改造,其中第一種和第二種方式用的更多。

以容器為例,QQ團隊在2016年的時候就已經在嘗試容器方面的實現,並積累了自動化、彈性伸縮等方面的能力。決定全量上雲之後,在容器方面選擇了使用騰訊的TKE引擎,並通過邊上雲邊改造的方式做了很多優化:

  • 在TKE彈性伸縮能力的基礎上做了功能疊加,例如業務畫像,根據業務的長期趨勢和突發活動去做預測,通過算法預估容量在什麼時間窗會達到多少水位,提前準備相應的容器資源擴容;

  • 將業務特性與TKE相結合,例如原生K8s是不支持跨地域的,而QQ是三地分佈,且上雲之後還進一步區分了自研和雲的機房屬性,所以TKE中增加了跨地域的特性;

  • 權限限制,QQ業務對於權限的要求非常嚴格的,要求基於IP鑑權,而容器是很難去做基於IP的權限管理,所以QQ使用了固定IP,每個容器都有自己的IP,交付時註冊到CMDB上,並完成鑑權等自動化交付流程。

上雲的難度

QQ上雲的難度在哪裡呢?

首先,QQ業務是屬於海量的用戶互相訪問的過程,既不可預測,也沒法做一個良好規劃。 QQ的訪問中,有大量臨時的UDP(用戶數據報協議)的訪問會建立起來,會帶來各方面對基礎的虛擬化和網絡、計算性能的挑戰。

其次,是成本問題。騰訊內部對於成本是有極致要求的,但我們都知道虛擬機因為要做管理工作是一定會有損耗的,如何優化虛擬機性能就成為了一個挑戰。

第三,QQ是一款擁有二十年積累的產品,為了支撐業務,QQ技術團隊也在很多方面都做了創新和優化,如何將這些累積的技術與雲上技術結合在一起呢?

除此之外,具體到實際的上雲實施,將QQ服務搬遷到雲上還面臨著以下具體的挑戰:

  • 安全問題(內網環境可以受到自研環境保護,搬到雲上之後更容易被惡意入侵);

  • 依賴問題(QQ服務依賴關係複雜,無法一次性將全部服務搬遷到雲機房);

  • 容災問題(雲上模塊需要通過雲機房到自研機房的專線進行通信,若專線發生故障,雲機房可能成為孤島);

  • 灰度問題:由於QQ是款即時通訊產品,用戶對實時性的要求很高,如何合理灰度,做到用戶對上雲過程無感知也是一個問題;

基礎設施向雲上遷移

QQ上云不能有額外的成本支出!

QQ和空間業務的體量有近20萬台服務器,因為不能有額外的成本支出,如果遷移上雲,這些存量服務器要怎麼辦?虛擬機肯定有損耗,這方面的成本差距如何彌補呢?

騰訊運營管理部運營規劃負責人陳鐵鋼表示:“QQ是一個運營時間比較長的業務,很多服務其實已經到了服役年限了,就自然裁撤了,少量的可用服務器置換給其它雲下業務使用了。不只是QQ業務,騰訊所有業務上雲都不是一下子把所有服務器從自研搬到雲上,而是有一個上雲的節奏,先用三年的時間把每年的增量業務搬到雲上,而存量業務會隨著服務器的壽命而陸續裁撤和消滅。”

虛擬機與物理機之間的成本差距如何彌補呢?騰訊自研了服務器產品——星星海。據了解,在QQ某個業務測試中,星星海服務器帶來了25%的性能收益,達到了原來物理機都沒有達到的性能。

上雲過程沒有額外的成本支持,上雲之後的成本效益又體現在哪裡呢?陳鐵鋼表示主要體現在三個方面:

  • 從管理角度來看,過去,資源是分散在每個業務組中的,為了滿足業務突發和裂變的情況,每個業務組都會留一些buff。這就會造成一個問題,所有的buff加起來會很大,但分割到具體業務後又很小,既不能很好的支持業務擴展,從公司層面看又很浪費。如果把這些資源都整合在一起,通過錯峰效應,所需buff的數量減少了,但卻能滿足各個業務增長的要求。

  • 很多QQ之前自己做不好的業務,可以通過雲原生技術來優化。例如調度,上雲之後利用Kubernetes的統一調度能力,提高設備的利用率。

  • 自研業務上云不是在公有云上劃一塊獨立集群給自研業務用,而是完全融入整個公有云環境,改變了過去騰訊雲和自研業務是兩個完全割裂的資源體系的情況。資源打通之後,當業務出現激增時,可以通過公有云的彈性能力快速擴展。

基礎設施上雲的節奏

如果從用戶量級的角度來看,QQ基礎設施上雲的節奏可以劃分為兩大階段500萬在線和1000萬在線,同時,QQ在這兩個階段遇到的問題也會不同。

500萬在線是速度和質量的平衡,這個階段需要重點關注可行性。

  • 丟包問題,丟包只是表象,其背後隱藏的是各種環境的適配問題、穩定性問題、質量問題。這個階段的丟包主要是網關問題和VPC緩存會話造成的;

  • 獲取VIP問題,QQ調度系統依賴用戶側上報接入IP的可用性和耗時,來判斷接入服務是否健康,並作出調度策略。而到了雲環境中,由於目標IP填寫的是所在虛擬機自身的內網IP,調度系統在客戶端不升級、不修改登錄協議的情況下,無法獲得VIP;

1000萬在線就要開始迎接海量的挑戰,這個階段雲設施的基礎能力已經驗證沒有問題,但網絡質量、時延的問題需要重點關注。

  • 丟包仍是一個需要關注的問題,只是這個階段的丟包原因會有所變化,大部分丟包可能是由虛擬機默認緩存區太小、物理母機緩衝區太小以及VPC會話數限制太小造成的;

  • 批量死機,一台雲主機死機可能會造成其他機器的死機。比較好的解決方法是同個模塊分配的機器不能處於同一台物理機上;

數據庫和組件遷移

數據遷移是上雲的重頭戲,QQ數據從私有云遷移到公有云主要是通過以下三種方式:

  • 冷遷移方式,先將數據全備,然後將數據遷移到雲上Redis集群,數據遷移完之後,開始做新增數據的追加。適合於私有組件數據遷移到公有云的場景,例如騰訊內部的自研數據庫,如QQ的Grocery KV存儲。

  • 使用DTS工具將數據遷移到雲上,適合於開源組件遷移到公有云的場景,例如自研組件、開源組件、以及基於開源組件二次開發的組件。

  • 私有組件直接上雲,由於雲上可能沒有某些組件,且業務也沒有將私有組件改造成雲的標準服務,所以只能在雲上直接部署一套組件集群,通過同步中心或主備等方式將數據遷移到雲上。

下面我們以MySQL為例來看看QQ數據遷移具體是如何做的。

QQ 是如何完成20萬台服務器全量上雲的? 2

MySQL是使用騰訊雲DTS遷移工作從自研IDC遷移到雲上的。 MySQL是主從模式,通過內部DNS類名字服務來尋址,先分配業務一個實例名稱,然後通過DNS 拿到這個實例的 IP 端口,再去訪問具體的實例。 DTS將自研IDC的數據遷移到雲上的MySQL之後,開發團隊只需在雲上切換服務就可以完成數據實例的遷移。

另外,通過主—備模式也可以將MySQL遷移到雲上。在自研機房有數據庫服務器的主和備,在雲機房部署幾台備機,通過主備同步的方式,把所有數據都同步到雲機房,然後將雲機房的某台備機切換成主機,將自研的主機降級為備機,完成數據庫遷移。

寫在最後

從用戶體驗來看,QQ是否上雲變化並不會太大,但是從QQ自身業務和技術架構來看,上雲的益處眾多,也更利於未來發展。如果從整個騰訊來看,QQ上云不只成為了外界衡量騰訊雲能力的一個重要評判標準,同時也為產品矩陣中的其它業務上雲提供了寶貴經驗。

事實上,在採訪中陳鐵鋼也透露出了微信的上雲情況,“微信目前已經在灰度上雲,且在按照自己的節奏逐步上雲。”