騰訊的業務體量非常龐大，在 2019 年，騰訊已擁有超過了 100 萬臺服務器，其中，社交業務包括 QQ 和空間的體量有近 20 萬臺服務器，且分布在全國三地。

　　把 QQ 這頭大象搬到云上并非易事。作為騰訊最龐大、最悠久、最復雜的業務之一，QQ 各系統間存在強耦合。上云過程中需要確保對用戶零影響，其難度可想而知。

　　面對重重挑戰，QQ 是如何迎難而上的呢？本文即將從整體規劃、方案執行、里程碑中的挑戰等方面介紹其中的技術細節，希望能為大家提供借鑒。

　　一、整體規劃

　　1.上云整體規劃

　　QQ 上云規劃時進行了系統化的梳理，包括業務評估、容量評估、業務架構、組織體系（比如運維職責的變化、研發流程的變化、資源預核算的變化、故障處理流程的變化）。

　　最重要的是，QQ 的技術體系跟著公有云進行了轉變，確定遷移方案、遷移工具、風險預案、回滾預案、混合云預案、多云預案等。

　　以過程劃分，QQ 上云整體規劃包含以下三個階段。

• 基礎設施上云，簡單說就是把基于物理網絡的自研 IDC 設備搬到云上，使用基于虛擬網絡的云 CVM 來搭建。
• 微服務和容器化改造，支持自動擴縮容。
• 架構和存儲升級，全面融入云生態。

　　其中，基礎設施上云是最底層、最基礎的第一步，本文將重點介紹。

　　2. 基礎設施上云規劃

　　基礎設施上云的規劃分為兩個階段。

• 完成所有核心功能模塊在云上的搭建，并調度 1000 萬在線用戶到云上。
• 完成整體基礎設施上云，并做好云上的三地調度演習。

　　在計劃推行的過程中，騰訊內部多個技術團隊精誠合作，共同應對復雜挑戰。然而，隨著 QQ 逐步放量上云，面向海量服務的挑戰才剛剛開始。

　　二、方案執行

　　QQ 上云方案執行前，有預測試、預驗證的過程。一些核心模塊（譬如高并發，或延遲非常敏感的模塊）在云上經過了充分壓測。真正遷移后，還有更多挑戰需要靈活應對。

　　1.QQ 后臺服務搬遷上云主要挑戰

　　QQ 后臺服務搬遷到云上部署，有這幾類主要挑戰：

• 安全問題

　　騰訊云提供的官網 VPC 可以通過配置反向代理被外網訪問，相比受自研環境保護的內網環境，缺乏自我保護的能力，搬到云上貌似更容易被惡意入侵。

• 依賴問題

　　QQ 后臺服務依賴關系復雜，無法一次性將全部服務都遷到云機房。統計后發現，QQ 后端主要的核心模塊平均依賴 40+ 個后端模塊。其中很多是外部的模塊，比如安全、架平存儲，這些模塊云上支持的時間未定，前期只能先穿越到自研 IDC 訪問。

• 容災問題

　　部署到云上的模塊，需要通過云機房到自研機房的專線進行通信，若專線發生故障，可能導致云機房成為孤島。一開始云機房只在廣州部署，無法做到云環境內部多地容災而后云自研云機房。

• 灰度問題

　　QQ 即時通訊的特點，決定了用戶對 QQ 的實時性要求很高，怎樣合理灰度，做到用戶對上云過程零感知，是一座需要跨越的大山。

　　2. 面臨挑戰，如何解決

• 應對安全問題

　　結合云上的安全產品，以及原來自研的安全服務和安全策略，騰訊有一套混合云的安全通用體系。

　　首先在公有云的大網里，劃出獨立的私有網絡 VPC-X

　　即有外部訪問的模塊（如 QQ 接入層 SSO、內網接入層 OIDB 等），可以部署在普通的 VPC 中，而核心業務需要做外部隔離部署。為此，QQ 運維和騰訊云一起建設了沒有外網環境的 VPC-X 專用云環境，并通過策略打通了普通 VPC 和 VPC-X 之間必要的訪問路徑，拒絕其他訪問。

　　
在此之上，使用網絡防護以及網絡安全的產品服務

　　云上有豐富的安全產品：主機上有主機防護，漏洞掃描；業務層有應用防護；運維有運維安全。QQ 內部積累的一些安全方案，也已回饋到云上。

　　事實上，整個公有云的安全策略和私有云是一樣的，沒有什么根本性的差別。

• 應對依賴和容災問題

　　上云過程要需要進行灰度遷移，而遷移過程會不可避免地造成自研機房和云機房的帶寬穿越，為此，需提前評估自研機房到云機房所需的帶寬。

　　假如使用城市方案，專線帶寬應該跟現有的三地部署方案對齊。QQ 核心系統大概需要幾十G的帶寬。若采用 IDC 方案，QQ 里面有很多業務使用有狀態的尋址方式，把同城內的機房全部打散訪問（類似一致性哈希）。因此，把廣州云當做深圳的 IDC 后，廣州云和深圳的專線穿越會增大。參考深圳內部的 IDC 穿越帶寬，預計需要增加幾十G的帶寬。

　　為此，開發者們評估了自研到云機房的帶寬：支持 QQ 幾大核心系統（接入、消息、狀態、資料、關系鏈、登錄）所需要的帶寬為N。而所有 QQ 基礎功能都遷移到云上，則至少需要 2N 的帶寬。考慮到容災問題，實際上拉了兩條專線互備（防止專線被挖斷形成孤島），即為 QQ 上云專門搭建 4N 的帶寬專線。

• 應對灰度問題

　　QQ 后臺的模塊眾多，一下子上云并不現實，為了確保服務切換的平滑穩定，需要考慮以下情況：

　　(1) 有問題時影響盡可能少的用戶。

　　(2) 用戶數據完好性：有問題時不能導致用戶數據丟失或錯亂。

　　(3) 機器維度回退：云上環境有問題時，可以隨時禁用，全部切回自研環境。

　　(4) 用戶維度回退：用戶登錄云 IP 有問題，能夠自動切換到自研 IP，不影響用戶使用 QQ。

　　為此，需從 3 個維度制定灰度的 3 條主線：

　　(1) 用戶維度

　　簡單說，就是灰度的用戶量級。主要考慮用最少用戶量級來發現問題。

　　(2) 后臺模塊維度

　　其實就是哪些模塊先上，哪些模塊后上。主要考慮哪些模塊出問題對用戶的影響最小。

　　基本思路是：

　　(1) 先上接入層，驗證云上的鏈接能力；

　　(2) 再上邏輯層，邏輯層通過一定用戶量級驗證沒問題；

　　(3) 再上數據層，確保用戶數據一致性。

　　(3) 后臺 Set 維度

　　一個 Set 可以認為是一套閉環的系統，比如資料后臺的一個 Set，包含“接入層+資料邏輯層+資料數據層”。這個維度的灰度，可用來確定一套系統里需要多少機器上云。

　　對于純邏輯層來說，每個模塊上兩臺機器（兩臺是為了考慮故障容災，只需確保有一臺在工作），就可以構造一個閉環的 set，但對于數據層來說，一個 set 需要的機器包含一份全量用戶的數據拷貝。

　　從灰度的角度來說，邏輯層就是堆機器的過程，數據層是先上一份最小的數據拷貝，并且先只放開“讀”服務，等到其他所有環境都驗證可行，才切“寫”服務到云上。

　　結合上面 3 個維度，總體的灰度過程是：

　　(1) 內部驗證+接入層（驗證三通接入、用戶級和機器級調度能力）

　　(2)0-100 萬用戶+接入層灰度擴容（小規模驗證，觀察用戶反饋）

　　(3)100W+ 邏輯層灰度及擴容

　　(4)100W～500W+ 數據層同步數據

　　(5)500W+ 數據層讀

　　(6)500W～1000W+ 數據層寫

　　(7)1000W～5000W+ 廣州云 1 億在線演習

　　(8) 南京云+天津云 +0～5000W

　　(9) 天津云/南京云 +5000W～1 億

　　(10) 天津云/南京云/廣州云新 3 地調度演習

　　(11) 天津/上海自研機房下架，保留深圳自研機房觀察 1 年

　　(12) 深圳自研機房下架

　　灰度過程中，通過客戶端服務質量、服務間調用延遲、全網撥測等監控指標判斷業務是否有問題。另外，此時整個服務運營體系已經轉變，QQ 必須適應相應的調整：

　　(1) 基礎運維和公共運維團隊變成由公有云的運維團隊來支持。

　　(2) 運營流程也發生很大的變化，服務 SLA 要跟公有云服務商一起制定。

　　(3) 監控工具的選擇，或改造原有的監控工具，或者換用云上成熟的監控 SaaS 服務。

　　三、里程碑中的挑戰

　　基礎設施上云，從用戶量級的角度來考慮，主要有幾個里程碑：

　　(1)500 萬是速度和質量的平衡。

　　(2)1000 萬開始迎接海量的挑戰。

　　這里分析下每個里程碑里會遇到的重點問題：

　　里程碑1：五百萬在線

　　在 0 到 500 萬在線的這個階段，需要重點關注可行性的問題，即各個系統怎樣做好充分的驗證，才能確保在云環境里成功跑起來。

• 丟包問題

　　丟包問題一般只是表象，真實的丟包原因隱藏著各種環境的適配問題、穩定性問題、質量問題。在 QQ 上云的過程中，丟包問題頻繁出現，是所有問題中最棘手的。

　　這里列舉在這個階段遇到的兩個丟包 case：

　　case 1：網關問題。

　　在資料后臺的搭建過程中，曾發現 UDP 的丟包率較大，且可穩定復現在某些用戶上。通過問題定位發現，發包和收包邏輯均正常，于是懷疑數據在鏈路上丟了。最終發現是物理網關的問題：只要是 UDP 分片，且 IP 頭后面第三個第四個字節為 3503（0D AF）就必然導致丟包，同時也發現這個問題只在第一代網關設備（VSG）出現。于是騰訊找到網關設備廠商協商，把一代網關升級為二代網關（NGW），解決了該問題。

　　case 2：VPC 緩存會話問題。

　　這其實是上個問題的延續。在一代網關（VSG）升級到二代網關（NGW）的過程中，觸發了 VPC 在宿主機 SDN 轉發實現上的一個 bug，導致 UDP 丟包。一開始騰訊云在切換路由時是先刪后加，當 VPC 內有 NAT 網關的默認路由時，就會導致流量轉發到 NAT 網關。當路由加回來時老會話不會更新路由，因此老會話中斷，而新發起的會話能正常工作。剛好自研機房有幾臺機器訪問 OIDB 的 UDP 四元組一直不變，會話就會一直不老化，導致業務一直異常。最后這個問題靠重啟業務進程解決，后續騰訊云團隊也修復了這個 bug。

　　這個時候遇到的其他丟包 case 還包括“專線被挖斷、機器故障、機器性能問題”等，不過大多不是大面積問題，其影響范圍較小，相關技術負責人能及時地解決大部分問題。

• 獲取 VIP 問題

　　QQ 調度系統依賴用戶側上報接入 IP 的可用性和耗時，來判斷接入服務是否健康，并做最優的調度策略。因此，調度系統需要知道用戶實際鏈接的對外 IP（從后臺角度看是 TGW 對外提供的 VIP）。在自研環境中，TGW 把 VIP 通過 IP 層的目標 IP 傳給 QQ 接入層 SSO，SSO 通過 getsockname 系統調用就可以獲得外網用戶看到的 VIP。但到了云上環境，接入層使用 CLB 接入，CLB 傳給 SSO 的時候，目標 IP 填寫的是 SSO 所在虛擬機自身的內網 IP。因此，在客戶端不做升級，不修改登錄協議的情況下，調度系統無法獲得 VIP。

　　解決辦法之一是客戶端升級協議，但這樣的話老用戶無法上云，無法保證上云的進度。

　　另一個辦法是修改 CLB 的實現，對齊 TGW，把外網 IP 傳給 SSO。在多方技術團隊的努力下，最終決定按此方案實現。不過因為 CLB 依賴 TGW/GRE 的實現，還需要 TGW 團隊、TLinux 內核團隊的配合，并需要將全網騰訊云的機器進行內核升級，整個修復的周期比較長，預期是 3 個月。

　　但 QQ 上云的進度，不能因此推遲 3 個月，為此，開發者們制定了一個臨時方案：通過配置文件，配置 VIP 到 RIP（Realserver IP，虛擬機內網 IP）的映射關系。這個方案要 RIP 與 VIP 一對一映射，但在現網環境中，RIP 到 VIP 的映射關系是多對多的（為了降低 TGW 和 SSO 的相互依賴，保證 SSO 多通路負載均衡）。在上云初期 SSO 機器較少的時候，人工確保一對一映射是沒問題的，但隨著上云機器數和用戶數增多，一對一映射將無法滿足現網質量要求。

　　里程碑2：一千萬在線

　　從 500 萬到 1 千萬的階段，云設施的基礎能力已經驗證沒有問題，但網絡質量、時延的問題更為凸顯。

• 丟包問題

　　隨著云上用戶量的增長，很多新的問題被暴露出來，比較典型的還是丟包問題。

　　這個時候遇到的丟包問題，大概有如下這幾種情況：

　　(1) 虛擬機默認緩沖區太小。

　　(2) 物理母機緩沖區大小設置太小。

　　(3) VPC 會話數限制太小，VPC 在實現上會存儲網絡訪問的五元組會話，QQ 后臺大量使用 UDP，而且因為 QQ 體量比較大，五元組的數量很大，超過 VPC 的限制。

• 批量死機問題

　　這是群 Server 在部署的時候遇到的一個問題：3 臺機器一起死機，定位后發現是同一臺云主機死機了。

　　在自研環境中，群 Server 是使用實體機 M10 來搭建的，到了云環境，采用相同內存大小的虛擬機來搭建。運維在部署的時候，若把主備本應該分開部署的機器放到同一臺實體機上了，這對業務來說簡直是災難。

　　最后，技術同事們協商確定，由運維來確保同個模塊分配的機器不能處于同一臺物理機上，實現方式是：在業務同一個集群下的配置組別，打散母機。

　　四、找對方法，加速上云

　　在 QQ 上云過程的細節里，有很多方法可以選擇，也離不開一些技術工具和平臺的支持。這里從“數據庫的遷移模式”、“MySQL 數據搬遷”、“數據中心同步”、“云管平臺”、“云原生”、“TKE 引擎”這幾個方面來進行簡單介紹。

　　1. 數據庫的遷移模式

　　在私有云到公有云的數據搬遷模式中，QQ 有三種模式可以選擇。

　　(1) 私有組件數據遷移到公有云

　　騰訊內部有很多自研的數據庫，像 QQ 的 Grocery KV 存儲使用的是內部私有協議，云上沒有對應服務。業務需要將數據從私有組件遷移到 Redis。

　　QQ 采取了冷遷移的方式，先將數據全備，然后把數據導到云上 Redis 集群，導完后再做新增數據追加(用數據同步中心來實現)，數據同步完之后進行業務切割：留一個業務低峰期時間，比如晚上凌晨 2 點，花 1 分鐘把數據路由服務從自研 IDC 切到公有云 Redis 集群上。

　　(2) 開源組件到公有云

　　騰訊內部有一些業務是在開源組件之上做的二次開發(如基于單機 Redis 實現自研分布式 Redis 集群)。這些基于自研或開源組件的數據遷移到公有云上對應的數據服務，可通過 DTS 遷移工具來實現。

　　騰訊云上的 DTS 也可以來做自助遷移。這個工具甚至不需要運維操作，開發團隊自己在 DTS 窗口上輸入幾個參數，點個搬遷按紐后即可自助搬遷。搬遷完成后還可自動切換。

　　(3) 私有組件直接上云

　　有時云上暫無一些特定組件，業務也沒有資源改造私有組件為云的標準服務，此時可將組件集群直接在云上部署一套，數據通過同步中心或主備備等方式搬遷到公有云上。　　

　　2. MySQL 數據搬遷

　　QQ 的 MySQL 數據搬遷分“主—從”和“主—備”兩種模式。

　　主—從的模式

　　它通過內部的 DNS 類名字服務而非 IP 和 PORT 來尋址：先分配業務一個實例的名稱，然后通過 DNS 拿到這個實例的 IP 端口，再去訪問具體的實例。然后，從自研的 IDC 使用騰訊云 DTS 遷移工具，把數據導到云的 MySQL。數據自動導入完成后，開發團隊只需要在云上切換服務就可以完成數據實例的遷移。這種方式適合一些數據體量不大的業務數據遷移。

　　主—備的模式

　　即在深圳自研有數據庫服務器的主和備，在云機房新部署幾臺備機。通過主備同步的方式，把所有數據都同步到云機房。然后將云機房的某臺備機切換成主機，將自研的主機降級為備機。這樣就切換為云機房主備，自研機房備的模式。

　　3. 數據同步中心

　　更復雜的是數據同步中心。它適合業務量大，有全國多地分布且對延遲不敏感的業務，譬如 QQ 空間的點贊、發表說說等。它有如下特性：

　　服務模塊寫數據時，統一寫到各地的接入代理，代理再統一寫入一地；

　　寫服務的轉發存儲會將新增記錄同時寫到各地自研或云機房，實現最終數據一致性；

　　用戶就近讀，比如華北的用戶，就讀華北云的這個數據存儲集群，華南就讀華南的數據存儲集群；

　　通過同步中心的方式完成大規模數據的混合云同步。當要增加一個成都云區域，只需在當地增加一套同步服務。增加路由服務規則后，同步服務就會自動把數據同步到成都的云機房。

一般從深圳自研同步到上海和天津時延遲達幾十毫秒，不適合金融行業等延時高敏感業務模式。

　　4. 云管平臺

　　之前騰訊內部的配置系統、監控系統、CMDB 等都是基于私有云的管理模式。業務上云之后，它們要改造成支持混合云、多云的管理模式。譬如業務模塊會有 50 個實例在騰訊云上，30 個實例在海外云上，30 個實例在內部私有云里，那么 CMDB 必須要支持多云的資源管理。

　　圖中可以看到，帳號體系、預核算、企業安全、監控等應用工具或平臺，都要改造以適應混合云模式。以帳號體系為例，QQ 的開發者們以公有云的帳號登錄云官網來購買、使用和運營公有云上的資源。但如何把帳號所使用的資源成本核算到對應的業務，員工離職或轉崗后資源怎么回收或轉移，帳號如何綁定給企業組織架構，云官網帳號登陸如何與內部 OA 鑒權等，都是必須提前解決的問題。

　　5. 云原生

　　在開發方法、業務交付、云原生服務等方面，騰訊內部的 TAPD 研發管理工具、工蜂代碼倉庫、藍盾、橘子 CI、QCI、coding 已集成為工具鏈，在云上打造了一個持續集成、持續部署的 DevOps 流水線閉環，QQ 上云也收益于此。QQ 以前是包交付，現已大量使用容器交付方式。

　　在微服務這塊（如 SF2、SPP、TAF 等），QQ 使用了大量的微服務框架，這些微服務框架還將進行迭代升級。

　　6. TKE 引擎

　　K8S 平臺上，QQ 用了騰訊的 TKE 引擎，這是一個跟 K8S 完全兼容的引擎。一個用戶在騰訊云上買了 K8S 服務，自己內部也部署了 K8S 集群。他們的容器可以隨時、同時交付到騰訊云和他們本身的 K8S 集群，而不用做任何改動。通過容器交付，可以不用考慮環境依賴等問題。

　　通過將 TKE 跟 QQ 的業務特性適配，騰訊做出了一些更能滿足業務場景的 K8S 應用功能：

　　(1) 跨地域

　　QQ 是三地分布，上云后又增加了自研和云的機房屬性。原生 K8S 不支持跨地域的，因此騰訊的 TKE 引擎增加了跨地域的特性。

　　(2) 彈性伸縮能力

　　TKE 有基于 CPU 負載等基礎容量的彈性伸縮能力。在 TKE 優秀的伸縮能力之上，騰訊還做了功能疊加。根據業務長期的趨勢和業務突發活動，通過算法來預估容量在什么時間窗會達到多少水位，以準備相應的容器資源來提前幾小時擴容，應對突發流量。

　　(3) 權限限制

　　某些業務對權限是基于 IP 鑒權的。比如內部的業務模塊訪問 MySQL 時，要授權 MySQL 給這些 IP 放行。容器是很難去做這種基于 IP 的權限管理，QQ 的做法是將容器固定 IP，交付時注冊到 CMDB 上，完成鑒權等自動化交付流程。

　　(4) 開發工具

　　騰訊內部有很多 CI/CD 的優秀工具，開發團隊可以在鏡像倉庫選到自己適合的工具，在 CI、CD、CO 都能保持自己的習慣。

　　(5)海量業務

　　在管理體系、安全、審計、服務監控、日志、告警等功能特性上，騰訊增加和優化了近百個特性，滿足 TKE 與海量業務的結合。

從騰訊自研業務上云以及一些合作伙伴的案例，可以得出上云的五大趨勢：

　　(1) 全面擁抱 DevOps，研發效率更高效；

　　(2) 內部的優秀工具上云，讓云能提供更好的服務；

　　(3) 徹底擁抱云原生，用云來滿足業務快速迭代，資源彈性伸縮的需求；

　　(4) 開發團隊心態更加開放，主動與開源社區協同，貢獻更多的功能特性；

　　(5) 在 QQ 全量上云的過程中，很多問題邊上云邊解決。整個公有云的基礎設施和服務已經被錘煉得更加成熟。

　　五、小結

　　QQ 上云，好比開著火車換引擎。

　　現在，QQ 已經把了華南、華東、華北三大區域的用戶全都遷到了云上，實現完整的 QQ 公有云上服務。是的，“開著火車換引擎”，我們做到了！

　　這次自研上云的成功，一方面為騰訊云的進一步壯大打下堅實的基礎，另一方面，也為 QQ 自身的技術重生埋下伏筆。

　　QQ 的未來，從此刻開始改變。

總結

以上是生活随笔為你收集整理的QQ全量上云，你想了解的技术细节都在这的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。