QQ全量上雲的技術解析

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

把QQ這頭大象搬到雲上並不是易事。做爲騰訊最龐大、最悠久、最複雜的業務之一，QQ各系統間存在強耦合。上雲過程當中須要確保對用戶零影響，其難度可想而知。

面對重重挑戰，QQ是如何迎難而上的呢？本文即將從總體規劃、方案執行、里程碑中的挑戰等方面介紹其中的技術細節，但願能爲你們提供借鑑。

1、總體規劃

1.上雲總體規劃

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

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

以過程劃分，QQ上雲總體規劃包含如下三個階段。

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

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

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

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

2.基礎設施上雲規劃

基礎設施上雲的規劃分爲兩個階段。

(1)完成全部核心功能模塊在雲上的搭建，並調度1000萬在線用戶到雲上。

(2)完成總體基礎設施上雲，並作好雲上的三地調度演習。

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

2、方案執行

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條主線：

a/用戶維度

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

b/後臺模塊維度

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

基本思路是：

(1)先上接入層，驗證雲上的連接能力；

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

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

c/後臺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服務。

3、里程碑中的挑戰

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

(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來搭建的，到了雲環境，採用相同內存大小的虛擬機來搭建。運維在部署的時候，若把主備本應該分開部署的機器放到同一臺實體機上了，這對業務來講簡直是災難。

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

4、找對方法，加速上雲

在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之前是包交付，現已大量使用容器交付方式。

在微服務這塊（如SF二、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全量上雲的過程當中，不少問題邊上雲邊解決。整個公有云的基礎設施和服務已經被錘鍊得更加成熟。

5、小結

QQ上雲，比如開着火車換引擎。

如今，QQ已經把了華南、華東、華北三大區域的用戶全都遷到了雲上，實現完整的QQ公有云上服務。是的，「開着火車換引擎」，咱們作到了！

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

QQ的將來，今後刻開始改變。

關注騰訊開發者，專業的開發都關注了。