騰訊云：QQ全量上云，你想了解的技術(shù)細節(jié)都在這

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

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

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

一、整體規(guī)劃

1.上云整體規(guī)劃

QQ上云規(guī)劃時進行了系統(tǒng)化的梳理，包括業(yè)務(wù)評估、容量評估、業(yè)務(wù)架構(gòu)、組織體系（比如運維職責的變化、研發(fā)流程的變化、資源預(yù)核算的變化、故障處理流程的變化）。

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

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

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

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

(3)架構(gòu)和存儲升級，全面融入云生態(tài)。

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

2.基礎(chǔ)設(shè)施上云規(guī)劃

基礎(chǔ)設(shè)施上云的規(guī)劃分為兩個階段。

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

(2)完成整體基礎(chǔ)設(shè)施上云，并做好云上的三地調(diào)度演習。

在計劃推行的過程中，騰訊內(nèi)部多個技術(shù)團隊精誠合作，共同應(yīng)對復(fù)雜挑戰(zhàn)。然而，隨著QQ逐步放量上云，面向海量服務(wù)的挑戰(zhàn)才剛剛開始。

二、方案執(zhí)行

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

1.QQ后臺服務(wù)搬遷上云主要挑戰(zhàn)

QQ后臺服務(wù)搬遷到云上部署，有這幾類主要挑戰(zhàn)：

01 安全問題

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

02 依賴問題

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

03 容災(zāi)問題

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

04 灰度問題

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

2.面臨挑戰(zhàn)，如何解決

01 應(yīng)對安全問題

結(jié)合云上的安全產(chǎn)品，以及原來自研的安全服務(wù)和安全策略，騰訊有一套混合云的安全通用體系。

首先在公有云的大網(wǎng)里，劃出獨立的私有網(wǎng)絡(luò)VPC-X

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

在此之上，使用網(wǎng)絡(luò)防護以及網(wǎng)絡(luò)安全的產(chǎn)品服務(wù)

云上有豐富的安全產(chǎn)品：主機上有主機防護，漏洞掃描；業(yè)務(wù)層有應(yīng)用防護；運維有運維安全。QQ內(nèi)部積累的一些安全方案，也已回饋到云上。

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

02 應(yīng)對依賴和容災(zāi)問題

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

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

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

03 應(yīng)對灰度問題

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

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

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

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

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

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

(1)用戶維度

簡單說，就是灰度的用戶量級。主要考慮用最少用戶量級來發(fā)現(xiàn)問題。

(2)后臺模塊維度

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

基本思路是：

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

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

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

(3)后臺Set維度

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

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

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

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

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

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

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

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

(5)500W+數(shù)據(jù)層讀

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

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

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

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

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

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

(12)深圳自研機房下架

灰度過程中，通過客戶端服務(wù)質(zhì)量、服務(wù)間調(diào)用延遲、全網(wǎng)撥測等監(jiān)控指標判斷業(yè)務(wù)是否有問題。另外，此時整個服務(wù)運營體系已經(jīng)轉(zhuǎn)變，QQ必須適應(yīng)相應(yīng)的調(diào)整：

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

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

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

三、里程碑中的挑戰(zhàn)

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

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

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

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

里程碑1：五百萬在線

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

01 丟包問題

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

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

case 1：網(wǎng)關(guān)問題。

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

case 2：VPC緩存會話問題。

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

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

02 獲取VIP問題

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

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

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

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

里程碑2：一千萬在線

從500萬到1千萬的階段，云設(shè)施的基礎(chǔ)能力已經(jīng)驗證沒有問題，但網(wǎng)絡(luò)質(zhì)量、時延的問題更為凸顯。

01 丟包問題

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

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

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

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

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

02 批量死機問題

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

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

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

四、找對方法，加速上云

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

1.數(shù)據(jù)庫的遷移模式

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

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

騰訊內(nèi)部有很多自研的數(shù)據(jù)庫，像QQ的Grocery KV存儲使用的是內(nèi)部私有協(xié)議，云上沒有對應(yīng)服務(wù)。業(yè)務(wù)需要將數(shù)據(jù)從私有組件遷移到Redis。

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

(2)開源組件到公有云

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

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

(3)私有組件直接上云

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

2.MySQL數(shù)據(jù)搬遷

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

主—從的模式

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

主—備的模式

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

3.數(shù)據(jù)同步中心

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

服務(wù)模塊寫數(shù)據(jù)時，統(tǒng)一寫到各地的接入代理，代理再統(tǒng)一寫入一地；

寫服務(wù)的轉(zhuǎn)發(fā)存儲會將新增記錄同時寫到各地自研或云機房，實現(xiàn)最終數(shù)據(jù)一致性；

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

通過同步中心的方式完成大規(guī)模數(shù)據(jù)的混合云同步。當要增加一個成都云區(qū)域，只需在當?shù)卦黾右惶淄椒?wù)。增加路由服務(wù)規(guī)則后，同步服務(wù)就會自動把數(shù)據(jù)同步到成都的云機房。

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

4.云管平臺

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

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

5.云原生

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

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

6.TKE引擎

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

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

(1)跨地域

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

(2)彈性伸縮能力

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

(3)權(quán)限限制

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

(4)開發(fā)工具

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

(5)海量業(yè)務(wù)

在管理體系、安全、審計、服務(wù)監(jiān)控、日志、告警等功能特性上，騰訊增加和優(yōu)化了近百個特性，滿足TKE與海量業(yè)務(wù)的結(jié)合。

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

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

(2)內(nèi)部的優(yōu)秀工具上云，讓云能提供更好的服務(wù)；

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

(4)開發(fā)團隊心態(tài)更加開放，主動與開源社區(qū)協(xié)同，貢獻更多的功能特性；

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

五、小結(jié)

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

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

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

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