截止到目前，QQ 所有的業務都已經遷移到了騰訊雲上。
2019 年 1 月 4 日，騰訊技術委員會正式成立，同時下設了兩個項目組“開源協同”和“自研上雲”。現在，作爲騰訊自研上雲的先行軍，QQ 已經率先完成了全量上雲。
QQ 業務場景有哪些特徵？全量上雲的整體節奏是什麼樣的？遷移上雲的難度在哪裏？關鍵過程有哪些？…… 爲了解開這些謎題，我們採訪了參與 QQ 全量上雲的多位技術專家。
1、QQ 的業務場景
突發 + 羣發是最恐怖的場景。
QQ 是一個典型的社交產品，社交場景的主要特點就是會有裂變的情況，比如如果一個消息是發在羣裏的，雖然看起來只是一條消息，但從送達的角度來看，可能會翻百倍。另外，一條消息不是一次發送出去就完事了，有時還會互相轉發，轉發給另一個人，甚至是另一個羣。由於 QQ 使用的是 UDP，所以即使是在勻速發包的情況下，也會比騰訊雲上其它的大客戶大 N 倍。
然而，這還不是最恐怖的是，騰訊雲原生架構總經理肖世廣表示：“最恐怖的情況是，在突發的情況下，發生大規模轉發的情況。即使是在雲的場景下，也不可能準備如此多的資源，所以在上雲的時候，我們做了很多方面的優化，例如計算、存儲、網絡等等，除了提升雲性能，更重要的是要降低成本。”
2、QQ 全量上雲的整體節奏
2018 年 9 月 30 日是 QQ 上雲的一個重要節點。
“930”調整之前，騰訊集團內部其實已經在做很多上雲的嘗試，部分服務也已經跑在雲架構上了。“930”調整之後，騰訊內部做了很大的變革，不僅成立了新的雲與智慧產業事業羣，同時啓動了“開源協同”和“自研業務上雲”的兩大戰略方向。在此背景下，QQ 上雲成爲了勢在必行且迫在眉睫的事情。
2017 年，所有 QQ 用戶是在私有云上；
2018 年年底，15% 的 QQ 用戶從華南區遷移到廣州雲；
2019 年 6 月，30% 的 QQ 用戶遷移到公用雲上；
現在，QQ 所有用戶全部遷移到公用雲上；
據瞭解，目前 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 業務，騰訊所有業務上雲都不是一下子把所有服務器從自研搬到雲上，而是有一個上雲的節奏，先用三年的時間把每年的增量業務搬到雲上，而存量業務會隨着服務器的壽命而陸續裁撤和消滅。”
虛擬機與物理機之間的成本差距如何彌補呢？騰訊自研了服務器產品——星星海。據瞭解，在 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 數據遷移具體是如何做的。
MySQL 是使用騰訊雲 DTS 遷移工作從自研 IDC 遷移到雲上的。MySQL 是主從模式，通過內部 DNS 類名字服務來尋址，先分配業務一個實例名稱，然後通過 DNS 拿到這個實例的 IP 端口，再去訪問具體的實例。DTS 將自研 IDC 的數據遷移到雲上的 MySQL 之後，開發團隊只需在雲上切換服務就可以完成數據實例的遷移。
另外，通過主—備模式也可以將 MySQL 遷移到雲上。在自研機房有數據庫服務器的主和備，在雲機房部署幾臺備機，通過主備同步的方式，把所有數據都同步到雲機房，然後將雲機房的某臺備機切換成主機，將自研的主機降級爲備機，完成數據庫遷移。
5、寫在最後
從用戶體驗來看，QQ 是否上雲變化並不會太大，但是從 QQ 自身業務和技術架構來看，上雲的益處衆多，也更利於未來發展。如果從整個騰訊來看，QQ 上雲不只成爲了外界衡量騰訊雲能力的一個重要評判標準，同時也爲產品矩陣中的其它業務上雲提供了寶貴經驗。
事實上，在採訪中陳鐵鋼也透露出了微信的上雲情況，“微信目前已經在灰度上雲，且在按照自己的節奏逐步上雲。”