<s id="xcxsa"></s><rp id="xcxsa"></rp>

  • <span id="xcxsa"><pre id="xcxsa"><rt id="xcxsa"></rt></pre></span>
    <dd id="xcxsa"></dd><tbody id="xcxsa"></tbody>
        首頁 運維干貨QQ是如何完成20萬臺服務器全量上云的?

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

        運維派隸屬馬哥教育旗下專業運維社區,是國內成立最早的IT運維技術社區,歡迎關注公眾號:yunweipai
        領取學習更多免費Linux云計算、Python、Docker、K8s教程關注公眾號:馬哥linux運維

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

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

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

        1、QQ 的業務場景

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

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

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

        2、QQ 全量上云的整體節奏

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

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

        • 2017 年,所有 QQ 用戶是在私有云上;
        • 2018 年年底,15% 的 QQ 用戶從華南區遷移到廣州云;
        • 2019 年 6 月,30% 的 QQ 用戶遷移到公用云上;
        • 現在,QQ 所有用戶全部遷移到公用云上;

        QQ是如何完成20萬臺服務器全量上云的?插圖

        據了解,目前 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 是款即時通訊產品,用戶對實時性的要求很高,如何合理灰度,做到用戶對上云過程無感知也是一個問題;

        3、基礎設施向云上遷移

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

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

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

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

        上云過程沒有額外的成本支持,上云之后的成本效益又體現在哪里呢?陳鐵鋼表示主要體現在三個方面:
        從管理角度來看,過去,資源是分散在每個業務組中的,為了滿足業務突發和裂變的情況,每個業務組都會留一些 buff。這就會造成一個問題,所有的 buff 加起來會很大,但分割到具體業務后又很小,既不能很好的支持業務擴展,從公司層面看又很浪費。如果把這些資源都整合在一起,通過錯峰效應,所需 buff 的數量減少了,但卻能滿足各個業務增長的要求。

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

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

        基礎設施上云的節奏

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

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

        • 丟包問題,丟包只是表象,其背后隱藏的是各種環境的適配問題、穩定性問題、質量問題。這個階段的丟包主要是網關問題和 VPC 緩存會話造成的;
        • 獲取 VIP 問題,QQ 調度系統依賴用戶側上報接入 IP 的可用性和耗時,來判斷接入服務是否健康,并作出調度策略。而到了云環境中,由于目標 IP 填寫的是所在虛擬機自身的內網 IP,調度系統在客戶端不升級、不修改登錄協議的情況下,無法獲得 VIP;

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

        • 丟包仍是一個需要關注的問題,只是這個階段的丟包原因會有所變化,大部分丟包可能是由虛擬機默認緩存區太小、物理母機緩沖區太小以及 VPC 會話數限制太小造成的;
        • 批量死機,一臺云主機死機可能會造成其他機器的死機。比較好的解決方法是同個模塊分配的機器不能處于同一臺物理機上;

        4、數據庫和組件遷移

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

        • 冷遷移方式,先將數據全備,然后將數據遷移到云上 Redis 集群,數據遷移完之后,開始做新增數據的追加。適合于私有組件數據遷移到公有云的場景,例如騰訊內部的自研數據庫,如 QQ 的 Grocery KV 存儲。
        • 使用 DTS 工具將數據遷移到云上,適合于開源組件遷移到公有云的場景,例如自研組件、開源組件、以及基于開源組件二次開發的組件。
        • 私有組件直接上云,由于云上可能沒有某些組件,且業務也沒有將私有組件改造成云的標準服務,所以只能在云上直接部署一套組件集群,通過同步中心或主備等方式將數據遷移到云上。

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

        QQ是如何完成20萬臺服務器全量上云的?插圖1

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

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

        5、寫在最后

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

        事實上,在采訪中陳鐵鋼也透露出了微信的上云情況,“微信目前已經在灰度上云,且在按照自己的節奏逐步上云?!?/p>

        本文鏈接:http://m.abandonstatusquo.com/31438.html

        網友評論comments

        發表評論

        您的電子郵箱地址不會被公開。

        暫無評論

        Copyright ? 2012-2022 YUNWEIPAI.COM - 運維派 京ICP備16064699號-6
        掃二維碼
        掃二維碼
        返回頂部
        十分钟免费观看视频高清下载