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

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

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

一、整體規劃

1.上云整體規劃

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

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

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

(1)基礎設施上云，簡單說就是把基于物理網絡的自研IDC設備搬到云上，使用基于虛擬網絡的云CVM來搭建。

(2)微服務和容器化改造，支持自動擴縮容。

(3)架構和存儲升級，全面融入云生態。

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

2.基礎設施上云規劃

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

(1)完成所有核心功能模塊在云上的搭建，并調度1000萬在線用戶到云上。

(2)完成整體基礎設施上云，并做好云上的三地調度演習。

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

二、方案執行

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

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

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

01

安全問題

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

02

依賴問題

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

03

容災問題

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

04

灰度問題

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

2.面臨挑戰，如何解決

01

應對安全問題

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

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

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

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

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

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

02

應對依賴和容災問題

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

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

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

03

應對灰度問題

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

01

丟包問題

丟包問題一般只是表象，真實的丟包原因隱藏著各種環境的適配問題、穩定性問題、質量問題。在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還包括“專線被挖斷、機器故障、機器性能問題”等，不過大多不是大面積問題，其影響范圍較小，相關技術負責人能及時地解決大部分問題。

02

獲取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千萬的階段，云設施的基礎能力已經驗證沒有問題，但網絡質量、時延的問題更為凸顯。

01

丟包問題

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

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

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

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

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

02

批量死機問題

這是群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的未來，從此刻開始改變。

責任編輯：王超