導(dǎo)語：傳統(tǒng)行業(yè)轉(zhuǎn)型的過程中，騰訊向來扮演的是數(shù)字化助手的角色，騰訊云作為幫助企業(yè)數(shù)字化轉(zhuǎn)型的入口，也已經(jīng)成為騰訊的“獨(dú)角獸”業(yè)務(wù)。 然而伴隨著云業(yè)務(wù)的增長(zhǎng)，騰訊內(nèi)部業(yè)務(wù)如何上云，對(duì)于外界來說一直是個(gè)秘密。近日，騰訊自研上云項(xiàng)目負(fù)責(zé)人周小軍首次披露，騰訊如何把內(nèi)部海量的自研業(yè)務(wù)搬上云端的故事。以下是他的分享內(nèi)容。

大家好，我今天分享的核心內(nèi)容有三個(gè)：

騰訊自研業(yè)務(wù)如何從私有云的模式搬遷到公有云；

如何把這些大體量的業(yè)務(wù)搬到云端；

如何擁抱云原生。

騰訊的業(yè)務(wù)量非常龐大，社交業(yè)務(wù)包括QQ和空間的體量有近二十萬臺(tái)服務(wù)器，分布在全國(guó)三地。要把如此龐大體積的業(yè)務(wù)搬到云上，可以稱之為“把大象搬到云端”。

今天我就分四個(gè)方面向大家介紹騰訊自研業(yè)務(wù)上云的故事。第一是騰訊業(yè)務(wù)為什么要上公有云，第二個(gè)是業(yè)務(wù)上云的價(jià)值，第三個(gè)是如何上云，第四個(gè)是以QQ上云的案例分享業(yè)務(wù)上云的過程。

為什么要上云？

1.騰訊業(yè)務(wù)的煙囪模式2018年以前，騰訊的業(yè)務(wù)線是類似煙囪一樣的模式，每個(gè)業(yè)務(wù)事業(yè)群從邏輯層、數(shù)據(jù)層到后端的容器或虛機(jī)層，都是獨(dú)立一套技術(shù)框架和技術(shù)體系。每個(gè)事業(yè)群之間的框架多數(shù)是不通用的，一個(gè)騰訊的員工從IEG轉(zhuǎn)崗到微信事業(yè)群，發(fā)現(xiàn)他的開發(fā)框架可能都要重新熟悉。一個(gè)新人來到騰訊之后，面臨那么多的服務(wù)框架，也不知道如何選擇合適的框架著手。

甚至在騰訊的內(nèi)部論壇上，經(jīng)常有很多新人發(fā)帖問，我該選什么樣的工具，我該選什么樣的框架，這種情況就導(dǎo)致三種困惑：

第一個(gè)是很多工程師不斷抱怨為什么騰訊內(nèi)部有這么多名詞，不同的工具、不同的框架、不同的平臺(tái)、不同的數(shù)據(jù)庫(kù)和不同的存儲(chǔ)等等。

第二個(gè)是很多部門都開發(fā)和使用自己的一套東西，跟其他部門缺乏分享和協(xié)作。

第三個(gè)是開源文化氛圍不強(qiáng)。很多部門的代碼不開放，或者缺乏文檔。我們知道成為一個(gè)優(yōu)秀的組件，組件的文檔、支持、社區(qū)都是非常重要的，沒有這些支持的話，你很難把一個(gè)組件做到最優(yōu)，但是在騰訊內(nèi)部很多組件是缺少文檔，支持力度不足，甚至出現(xiàn)很多無人維護(hù)的孤兒組件。

2. 兩大開放戰(zhàn)略并行基于以上問題，為了技術(shù)體系革新，930調(diào)整后，騰訊內(nèi)部做了大變革，包括成立新的云事業(yè)群，公司內(nèi)部成立“技術(shù)委員會(huì)”，啟動(dòng)“開源協(xié)同”和“自研業(yè)務(wù)上云”的兩大戰(zhàn)略方向。

首先，開源協(xié)同就是在騰訊內(nèi)部，所有的開發(fā)團(tuán)隊(duì)代碼都是開放的，騰訊內(nèi)部有統(tǒng)一代碼庫(kù)，所有的團(tuán)隊(duì)及個(gè)人的代碼都要在上面公開提交、公開發(fā)布。團(tuán)隊(duì)與團(tuán)隊(duì)協(xié)作更好，隨時(shí)可以去創(chuàng)建個(gè)分支，或者提交更豐富的特性功能，形成公司內(nèi)的開源代碼文化，創(chuàng)建更好的工程師氛圍。

其次是“自研業(yè)務(wù)上云”。基于公有云的研發(fā)模式，使用云上豐富的組件、豐富的服務(wù)，把內(nèi)部的一些優(yōu)秀的工具和組件上云，對(duì)外開放，在云上做服務(wù)。在客戶的激勵(lì)驅(qū)動(dòng)下，不斷迭代成為行業(yè)內(nèi)的領(lǐng)先水平。

這是騰訊技術(shù)領(lǐng)域一個(gè)很大的變革。

上云的價(jià)值是什么？

第一是業(yè)務(wù)價(jià)值，業(yè)務(wù)的研發(fā)效率更高，從0到1開發(fā)一個(gè)新產(chǎn)品短短一周就能完成，微服務(wù)框架、數(shù)據(jù)庫(kù)、容器資源、持續(xù)集成、持續(xù)交付、統(tǒng)一配置中心等等，云上都有現(xiàn)成的服務(wù)，研發(fā)團(tuán)隊(duì)不需要到處拼裝各種組件和工具，可以更專注業(yè)務(wù)研發(fā)。

第二是工程師價(jià)值，工程師可以使用到整個(gè)業(yè)界最標(biāo)準(zhǔn)化的服務(wù)，基于公有云的研發(fā)模式，能夠離開封閉的開發(fā)環(huán)境和組件，同時(shí)工程師還可以輸出非常優(yōu)秀的組件到云上成為服務(wù)，這也是大多數(shù)工程師的夢(mèng)想。

第三是客戶價(jià)值，可以給行業(yè)輸出非常多的公有云的經(jīng)驗(yàn)。截至2019年初，騰訊正式發(fā)布的對(duì)外開源項(xiàng)目將近70個(gè)，諸如騰訊云T stack、藍(lán)鯨智云BlueKing CMDB、微信開源系列和TARS等，都是騰訊開源的典型案例。

如何上云？

1.業(yè)務(wù)上云的三個(gè)階段

騰訊自研業(yè)務(wù)上云也并不是一蹴而就的，而是有三個(gè)階段：

第一階段是從2017年開始直播類業(yè)務(wù)的上云。直播業(yè)務(wù)上云模式是一整套直播業(yè)務(wù)從自研機(jī)房搬遷到公有云機(jī)房，在騰訊云上提供服務(wù)，完成國(guó)內(nèi)和海外幾十個(gè)節(jié)點(diǎn)的建設(shè)，服務(wù)于自研的直播業(yè)務(wù)和外部客戶。上云時(shí)打通了內(nèi)部的運(yùn)營(yíng)管理系統(tǒng)和監(jiān)控系統(tǒng)，同時(shí)支持跨云的管理。

第二個(gè)階段是沙箱云，這個(gè)階段是在騰訊云上建立一個(gè)邏輯隔離的私有網(wǎng)絡(luò)空間，利用騰訊云的IaaS服務(wù)，使用云的虛擬機(jī)、云的網(wǎng)絡(luò)、云的機(jī)房來支撐自研業(yè)務(wù)的服務(wù)。不過這類模式只屬于基礎(chǔ)平臺(tái)上云，并不是整體業(yè)務(wù)體系完整上云。

第三階段，是在騰訊“930”變革之前， 2018年6月我們就已經(jīng)開始擁抱公有云，啟動(dòng)自研的整個(gè)業(yè)務(wù)從私有云遷到公有云，這是把整個(gè)業(yè)務(wù)連根拔起搬遷到云上。

上云之前，2017年，我們所有QQ用戶還在私有云上，到了2018年年底，就已經(jīng)把一成半的QQ用戶從華南區(qū)遷到廣州云。到了2019年的6月，已經(jīng)有三成的QQ用戶在云上，每6個(gè)QQ用戶就有2個(gè)是在云上。我們計(jì)劃到2019年年底，QQ實(shí)現(xiàn)華南、華東和華北三大區(qū)域的所有用戶全部都遷到云上，實(shí)現(xiàn)完整的QQ公有云上服務(wù)。

2. 上云有哪些流程？

在上云的過程中，我們可以直觀的感知到，跟之前煙囪式的架構(gòu)不同，上云后像IEG、PCG、WXG等事業(yè)群等，都將在公有云上運(yùn)行各自的業(yè)務(wù)。業(yè)務(wù)會(huì)使用公有云的CLB、接入服務(wù)、服務(wù)框架，云PaaS服務(wù)，包括Redis、MySQL、Kafka、ES、CBS、COS等等，還有像K8S這些公有云上的原生服務(wù)。

為了實(shí)現(xiàn)這一點(diǎn)，我們做了一些改造，在每個(gè)區(qū)域的公有云和私有云機(jī)房之間拉了專線，實(shí)現(xiàn)了公有云私有網(wǎng)絡(luò)到私有云機(jī)房的互通，保證業(yè)務(wù)能夠來回遷移及訪問內(nèi)部服務(wù)能力。

根據(jù)業(yè)務(wù)體量不同，業(yè)務(wù)采用三種方式上云，有改造后上云，有邊改造邊上云，有先上云再改造。業(yè)務(wù)可以根據(jù)自己的人力資源和上云計(jì)劃，選擇對(duì)應(yīng)的上云方式。

下圖是整個(gè)業(yè)務(wù)團(tuán)隊(duì)在上云的過程中所做的幾個(gè)流程：

第一是測(cè)試，包括公有云上的網(wǎng)絡(luò)、存儲(chǔ)、虛擬機(jī)、核心服務(wù)，以及單機(jī)性能、服務(wù)吞吐性能、存儲(chǔ)讀寫性能、業(yè)務(wù)模塊性能等等都經(jīng)過測(cè)試。通過測(cè)試之后，我們和云團(tuán)隊(duì)一起優(yōu)化了服務(wù)性能，對(duì)業(yè)務(wù)也相應(yīng)做了改造適配。

第二是業(yè)務(wù)上云方案，包括安全方案、容量評(píng)估、服務(wù)遷移方案和數(shù)據(jù)遷移方案等。

第三是業(yè)務(wù)遷移，遷移包括接入層、邏輯層、數(shù)據(jù)層及文件存儲(chǔ)等的遷移。

第四是混合云共存，業(yè)務(wù)會(huì)逐漸灰度遷移到云上，比如在線用戶從5%、10%、20%、30%到100%等，是一個(gè)灰度遷移過程。在灰度過程中可以及早發(fā)現(xiàn)各種問題，逐一解決，避免大規(guī)模上量時(shí)出現(xiàn)災(zāi)難性后果。這個(gè)過程中就存在公有云和私有云的混合部署模式，就要重點(diǎn)關(guān)注專線使用容量，做好專線在業(yè)務(wù)高峰期的預(yù)案，以及業(yè)務(wù)跨混合云訪問的服務(wù)延遲，及時(shí)做好用戶在不同云之間調(diào)度的策略和方法。

最后是業(yè)務(wù)監(jiān)控。上了云之后使用立體化的監(jiān)控體系，度量服務(wù)調(diào)用質(zhì)量、用戶訪問質(zhì)量和服務(wù)可用率等，譬如跟蹤用戶在私有云和公有云的訪問延遲有沒有變差，不能變壞，運(yùn)營(yíng)質(zhì)量有沒有跟原來保持一致，甚至變得更好。

從測(cè)試、方案、遷移、混合到監(jiān)控，這是我們上云團(tuán)隊(duì)所實(shí)施的上云遷移整體流程。

3.企業(yè)上云方案

根據(jù)騰訊自研業(yè)務(wù)上云，團(tuán)隊(duì)所積累的經(jīng)驗(yàn)之上，我們抽象出完整的上云方案，也十分符合很多企業(yè)上云的實(shí)際情況，方案分五個(gè)階段：

第一階段：規(guī)劃。規(guī)劃中要對(duì)業(yè)務(wù)系統(tǒng)化的梳理，包括業(yè)務(wù)評(píng)估、容量評(píng)估、業(yè)務(wù)架構(gòu)、組織體系。組織體系是指上云后組織架構(gòu)和職能的變化，包括運(yùn)維職責(zé)的變化：例如不再有中間件的運(yùn)維人員，研發(fā)流程的變化；研發(fā)、測(cè)試和生產(chǎn)環(huán)境如何在混合云甚至多云中共存；資源預(yù)核算的變化；以前是購(gòu)買機(jī)架和服務(wù)器，現(xiàn)在是先充值再按量計(jì)費(fèi)；故障處理流程的變化等。技術(shù)體系的組織都要準(zhǔn)備跟著公有云轉(zhuǎn)變。

第二階段是方案規(guī)劃和設(shè)計(jì)。要做好詳細(xì)的遷移方案，風(fēng)險(xiǎn)預(yù)案，回滾預(yù)案，混合云預(yù)案，多云預(yù)案等，譬如上云過程中數(shù)據(jù)遷移有問題，出現(xiàn)丟數(shù)據(jù)，我該如何解決等等。

第三階段是驗(yàn)證。這個(gè)是非常核心的階段，上云前，要有預(yù)測(cè)試、預(yù)驗(yàn)證的過程。可以把一些核心模塊，譬如高并發(fā)，或延遲非常敏感的模塊，在云上做好充分的壓測(cè)，并跟云服務(wù)團(tuán)隊(duì)一起優(yōu)化解決各種問題。

第四階段是業(yè)務(wù)遷移。遷移就更復(fù)雜了，包括服務(wù)和數(shù)據(jù)怎么遷、怎么做好備份，遷移過程中對(duì)業(yè)務(wù)有沒有影響，我們用云的通用遷移工具，還是我們自己開發(fā)的遷移工具。上云過程中，做好對(duì)灰度模塊的觀察，通過客戶端服務(wù)質(zhì)量，服務(wù)間調(diào)用延遲，全網(wǎng)撥測(cè)等監(jiān)控指標(biāo)觀察業(yè)務(wù)有沒有問題。

第五階段是持續(xù)運(yùn)營(yíng)。整個(gè)服務(wù)運(yùn)營(yíng)體系都變了，基礎(chǔ)運(yùn)維和公共運(yùn)維團(tuán)隊(duì)變成由公有云的運(yùn)維團(tuán)隊(duì)來支持。內(nèi)部使用的開源監(jiān)控工具，或者改造成支持公有云的資源監(jiān)控，或者使用云上成熟的監(jiān)控SaaS服務(wù)。CMDB要支持多云管理。運(yùn)營(yíng)流程也發(fā)生很大的變化，服務(wù)SLA要跟公有云服務(wù)商一起制定。

4.上云過程中的安全

當(dāng)然，上云的過程中，安全是不可或缺且關(guān)鍵的一環(huán)，騰訊是一個(gè)非常注重安全的公司，特別是用戶數(shù)據(jù)安全。我們?cè)谏显瓢踩@塊做了很多安全方案。自研內(nèi)部、企業(yè)內(nèi)部我們有一整套自研的安全體系。上云后，我們結(jié)合云上的一些安全產(chǎn)品，以及原來自研的安全服務(wù)和安全策略，制定混合云的安全通用體系。

首先在公有云的大網(wǎng)里，我們會(huì)劃出一個(gè)獨(dú)立的私有網(wǎng)絡(luò)VPC，業(yè)務(wù)分別去部署。之上有網(wǎng)絡(luò)防護(hù)以及網(wǎng)絡(luò)安全的產(chǎn)品服務(wù)。主機(jī)上有主機(jī)防護(hù)，漏洞掃描等。業(yè)務(wù)層有應(yīng)用防護(hù)，運(yùn)維有運(yùn)維安全，云上有豐富的產(chǎn)品可以去使用。然后我們也打造了一些內(nèi)部積累的安全方案，并回饋到云上。形成了公有云安全產(chǎn)品和自研安全產(chǎn)品兩者相互匹配融合的上云案例解決方案。

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

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

在上云過程中，也必然會(huì)遭遇到一些比較大的挑戰(zhàn)，比如數(shù)據(jù)的遷移。在私有云到公有云的數(shù)據(jù)搬遷模式中，我們有四種模式給業(yè)務(wù)選擇。

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

我們采取冷遷移的方式，先將數(shù)據(jù)全備，然后把數(shù)據(jù)導(dǎo)到云上Redis集群，導(dǎo)完后開始做新增數(shù)據(jù)追加。怎么追加呢？我們用數(shù)據(jù)同步中心來實(shí)現(xiàn)。后面會(huì)有同步中心實(shí)現(xiàn)的架構(gòu)。數(shù)據(jù)同步完之后，我們通知業(yè)務(wù)可以切割，留一個(gè)業(yè)務(wù)低峰期時(shí)間，比如晚上凌晨2點(diǎn)，花1分鐘把數(shù)據(jù)路由服務(wù)從自研IDC切到公有云Redis集群上。

第二、三種模式可以統(tǒng)稱為開源組件到公有云。我們內(nèi)部有一些業(yè)務(wù)，在開源組件之上做二次開發(fā)，譬如基于單機(jī)Redis實(shí)現(xiàn)自研分布式Redis集群。這些基于自研或開源組件的數(shù)據(jù)遷移到公有云上對(duì)應(yīng)的數(shù)據(jù)服務(wù)，可通過DTS遷移工具來實(shí)現(xiàn)。

這個(gè)非常簡(jiǎn)單，也是業(yè)界非常通用的做法，我們直接用云上的DTS來做自助遷移。這個(gè)工具甚至不需要運(yùn)維操作，開發(fā)團(tuán)隊(duì)自己在DTS窗口上輸入幾個(gè)參數(shù)，點(diǎn)個(gè)搬遷按紐后就可以自助搬遷。搬遷完成后自助切換或自動(dòng)切換。

第四種模式是私有組件直接上云。因?yàn)橛幸恍┙M件云上沒有，業(yè)務(wù)也沒有資源將私有組件改造成云的標(biāo)準(zhǔn)服務(wù)，這個(gè)時(shí)候業(yè)務(wù)就將組件集群直接在云上部署一套，數(shù)據(jù)通過同步中心或主備備等方式搬遷到公有云上。

比如說我在深圳的自研有一臺(tái)主兩臺(tái)備，那么我再把備3、備4放到廣州云，數(shù)據(jù)同時(shí)同步到私有云的兩個(gè)備和公有云的兩個(gè)備機(jī)模式。所有的主備數(shù)據(jù)完全同步完成之后，我們?cè)侔压性频膫渥兂芍鳎匝性频闹髯兂蓚洌拖喈?dāng)于是做了切換。

6.云管平臺(tái)還有一點(diǎn)非常核心的就是云管平臺(tái)。之前內(nèi)部的配置系統(tǒng)、監(jiān)控系統(tǒng)、CMDB等等，都是基于私有云的管理模式。業(yè)務(wù)上云之后，我們很多運(yùn)營(yíng)系統(tǒng)要改造成支持混合云，支持多云的管理模式。譬如業(yè)務(wù)模塊會(huì)有50個(gè)實(shí)例在騰訊云上，30個(gè)實(shí)例在海外亞馬遜云上，30個(gè)實(shí)例在內(nèi)部私有云里，那么我們的CMDB必須要支持多云的資源管理。從圖中可以看到，底下是我們的整個(gè)業(yè)務(wù)線，下面這些帳號(hào)體系、預(yù)核算、企業(yè)安全、監(jiān)控等等其他的應(yīng)用工具或平臺(tái)，都要改造以適應(yīng)混合云模式。就拿帳號(hào)體系來說，內(nèi)部員工以公有云的帳號(hào)登錄云官網(wǎng)來購(gòu)買、使用和運(yùn)營(yíng)公有云上的資源。但內(nèi)部如何把帳號(hào)所使用的資源成本核算到對(duì)應(yīng)的業(yè)務(wù)，員工離職或轉(zhuǎn)崗后資源怎么回收或轉(zhuǎn)移，如何把帳號(hào)綁定給企業(yè)組織架構(gòu)，云官網(wǎng)帳號(hào)登陸如何與內(nèi)部OA鑒權(quán)等，都是必須要考慮和解決的問題。

如何把QQ的所有用戶搬上云？

前面講了業(yè)務(wù)上云的思路和方法，QQ上云是走了這樣一個(gè)經(jīng)歷。下圖就是一張全國(guó)地圖， QQ業(yè)務(wù)有三大區(qū)域的數(shù)據(jù)中心，有華北自研，2015年這里曾發(fā)生了一個(gè)很大的爆炸事件，當(dāng)時(shí)我們還把天津的用戶調(diào)回了華南和華東區(qū)域。上海有華東自研機(jī)房，深圳有華南自研機(jī)房，在香港還有一些海外的出口。三大區(qū)域各有三成多的QQ在線用戶。

根據(jù)用戶分布情況，QQ上云時(shí)，在華東、華南、華北三地，在騰訊云建設(shè)的云機(jī)房上，我們創(chuàng)建了業(yè)務(wù)的公有云網(wǎng)絡(luò)，然后把QQ業(yè)務(wù)從各地的自研機(jī)房往云上遷移。

QQ上云中業(yè)務(wù)架構(gòu)圖分成了三大區(qū)域，分別是華北、華東、華南，而華南分成了廣州云和深圳自研機(jī)房?jī)纱髾C(jī)房。目前是“三云一地”。每個(gè)區(qū)域都是完全獨(dú)立的存儲(chǔ)和業(yè)務(wù)邏輯服務(wù)。可以把華南的整個(gè)用戶全部都調(diào)度到華北和華東區(qū)。業(yè)務(wù)隨時(shí)將用戶從不同的云區(qū)域和自研區(qū)域來回調(diào)度。

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

我們接著看下業(yè)務(wù)的MySQL數(shù)據(jù)搬遷案例，詳細(xì)見下圖，它有主—從的模式。我們沒有通過IP和PORT來尋址，而是通過內(nèi)部的DNS類名字服務(wù)來尋址。先分配業(yè)務(wù)一個(gè)實(shí)例的名稱，然后通過DNS拿到這個(gè)實(shí)例的IP端口，再去訪問具體的實(shí)例。從自研的IDC使用騰訊云DTS遷移工具，把數(shù)據(jù)導(dǎo)到云的MySQL。數(shù)據(jù)自動(dòng)導(dǎo)入完成后，開發(fā)團(tuán)隊(duì)只需要在云上切換服務(wù)就可以完成數(shù)據(jù)實(shí)例的遷移。這種適合一些數(shù)據(jù)體量不大的業(yè)務(wù)數(shù)據(jù)遷移。

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

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

還有更復(fù)雜的是數(shù)據(jù)同步中心。這種是適合業(yè)務(wù)量非常大，有全國(guó)多地分布的業(yè)務(wù)。服務(wù)模塊寫數(shù)據(jù)的時(shí)候，統(tǒng)一寫到各地的接入代理，代理統(tǒng)一寫一地，譬如深圳自研的寫服務(wù)。

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

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

通過同步中心的方式完成大規(guī)模數(shù)據(jù)的混合云同步。當(dāng)要增加一個(gè)成都云區(qū)域，我們只需在當(dāng)?shù)夭渴鸷靡惶淄椒?wù)，增加路由服務(wù)規(guī)則，同步服務(wù)就會(huì)自動(dòng)把數(shù)據(jù)同步到成都的云機(jī)房。

這種方式適合對(duì)延遲不敏感的業(yè)務(wù)，譬如社交業(yè)務(wù)的點(diǎn)贊、發(fā)表說說等。一般從深圳自研同步到上海和天津的時(shí)候延遲達(dá)到幾十毫秒，延遲非常高，不適合金融行業(yè)等延時(shí)高敏感業(yè)務(wù)模式。

3. 混合云紅包的架構(gòu)

從2014年開始，每年春節(jié)騰訊都有春節(jié)紅包活動(dòng)，今年春節(jié)我們首次在公有云和私有云之間做了紅包的兩地混合。我們?cè)趶V州云部署了與自研相同規(guī)模的紅包服務(wù)模塊，包括數(shù)據(jù)集群，在春節(jié)前演練及預(yù)熱階段，充分對(duì)廣州云服務(wù)做了各種測(cè)試和驗(yàn)證，包括跨城專線延遲對(duì)業(yè)務(wù)的影響程度。

紅包活動(dòng)期間，用戶在接入的時(shí)候根據(jù)用戶的ID分片或用戶來源，通過路由策略分流到廣州云機(jī)房和深圳自研機(jī)房。春節(jié)期間，混合云扛住了整個(gè)紅包活動(dòng)的用戶流量。驗(yàn)證了跨地域的混合云完全能支持億級(jí)的業(yè)務(wù)大并發(fā)流量。當(dāng)然我們也做了很多方案，比如萬一公有云的紅包模塊沒有扛住，我們?cè)趺崔k？如果我們發(fā)現(xiàn)用戶在云上有大量失敗，我們就把用戶在幾分鐘以內(nèi)切回到深圳云，甚至把整個(gè)業(yè)務(wù)從云上切回本地，我們有信心去扛云機(jī)房的壓力。

在上云過程中，QQ研發(fā)自身也對(duì)業(yè)務(wù)進(jìn)行了優(yōu)化，積極擁抱變化，做了很多處服務(wù)的改造，以能夠適應(yīng)新一代的基礎(chǔ)設(shè)施。

服務(wù)邏輯上，很多個(gè)業(yè)務(wù)直接使用云PaaS服務(wù)，如長(zhǎng)消息、加群邏輯等用了云Redis存儲(chǔ)服務(wù)。更多的服務(wù)遷移到TKE之上，一些內(nèi)存存儲(chǔ)服務(wù)，譬如資料、關(guān)系鏈等數(shù)據(jù)存儲(chǔ)層做了鏈接數(shù)、數(shù)據(jù)副本擴(kuò)展、混合云單元分布等架構(gòu)層級(jí)的優(yōu)化改造。

上云前后，上云團(tuán)隊(duì)對(duì)業(yè)務(wù)質(zhì)量非常關(guān)注，不斷對(duì)比二個(gè)云之間的可用率、客戶訪問質(zhì)量、服務(wù)間調(diào)用延遲等質(zhì)量數(shù)據(jù)。上云前后， 經(jīng)過各個(gè)架構(gòu)層的優(yōu)化，業(yè)務(wù)質(zhì)量數(shù)據(jù)最終保持私有云和公有云一致，保證了用戶訪問體驗(yàn)。

4.云原生

上云不僅是為了上云，我們更多要擁抱業(yè)界開源生態(tài)。要用云上優(yōu)秀成熟的產(chǎn)品和服務(wù)。在開發(fā)方法、業(yè)務(wù)交付、云原生服務(wù)等方面，業(yè)務(wù)上云前后已經(jīng)是部分甚至全部擁抱云原生的體系。我們已經(jīng)把TAPD研發(fā)管理工具、工蜂代碼倉(cāng)庫(kù)，還有藍(lán)盾、橘子CI、QCI、coding等集成為工具鏈，在云上打造了一個(gè)持續(xù)集成、持續(xù)部署的DevOps流水線閉環(huán)。

目前在云上的交付，業(yè)務(wù)每周都有幾百次的交付是通過容器來完成的，從以前的包交付變成容器交付。

在微服務(wù)這塊，像SF2、SPP、TAF等，我們內(nèi)部不同業(yè)務(wù)已經(jīng)使用了很多微服務(wù)框架，并計(jì)劃在公司內(nèi)迭代升級(jí)更優(yōu)秀的微服務(wù)框架。

5.TKE引擎

K8S平臺(tái)上，我們用了騰訊的TKE引擎，這是一個(gè)跟K8S完全兼容的引擎。我?guī)滋烨案粋€(gè)業(yè)界公司聊，他們?cè)隍v訊云、阿里云上買了K8S服務(wù)，自己內(nèi)部也部署了K8S集群。他們的容器可以隨時(shí)、同時(shí)交付到騰訊云、阿里云和他們本身的K8S集群，而不用做任何改動(dòng)。通過容器交付，業(yè)務(wù)可以不用考慮環(huán)境依賴等問題，交付變得更敏捷和輕松。

我們基于TKE之上做了功能定制和優(yōu)化。TKE有基于CPU負(fù)載等基礎(chǔ)容量的彈性伸縮能力。在TKE優(yōu)秀的伸縮能力之上，我們還做了功能疊加，包括業(yè)務(wù)畫像，就是根據(jù)業(yè)務(wù)長(zhǎng)期的趨勢(shì)和業(yè)務(wù)突發(fā)活動(dòng)，去做趨勢(shì)預(yù)測(cè)和活動(dòng)預(yù)測(cè)，通過算法來預(yù)估容量在什么時(shí)間窗會(huì)達(dá)到多少水位，以準(zhǔn)備相應(yīng)的容器資源來提前幾小時(shí)擴(kuò)容，應(yīng)對(duì)突發(fā)流量。

上云團(tuán)隊(duì)、業(yè)務(wù)研發(fā)跟云的TKE團(tuán)隊(duì)合作，我們把業(yè)務(wù)特性跟TKE相融合，來做出一個(gè)特性更加豐富、滿足業(yè)務(wù)場(chǎng)景的K8S應(yīng)用功能。譬如QQ是三地分布，特別是上云后又增加了自研和云的機(jī)房屬性。原生K8S不支持跨地域的，因此我們做了跨地域的特性。

除此之外還有權(quán)限限制，業(yè)務(wù)對(duì)權(quán)限要求非常嚴(yán)格，是基于IP鑒權(quán)的。比如內(nèi)部的業(yè)務(wù)模塊訪問MySQL時(shí)，要授權(quán)MySQL要給這些IP放行。容器是很難去做這種基于IP的權(quán)限管理，我們的容器都是用了固定IP，每個(gè)容器都有自己的IP，交付時(shí)注冊(cè)到CMDB上，并完成鑒權(quán)等自動(dòng)化交付流程。

內(nèi)部的CI/CD，我們有很多的優(yōu)秀工具，讓業(yè)務(wù)自行去選擇使用，開發(fā)團(tuán)隊(duì)喜歡什么樣的工具，從鏡像倉(cāng)庫(kù)、到CI、CD、CO都能保持業(yè)務(wù)自己的習(xí)慣。還有包括管理體系、安全、審計(jì)、服務(wù)監(jiān)控、日志、告警等功能特性，我們?cè)黾雍蛢?yōu)化了近百個(gè)特性，滿足TKE與海量業(yè)務(wù)結(jié)合。

于是，我們總結(jié)了八類的TKE業(yè)務(wù)應(yīng)用適配，從業(yè)務(wù)管理、網(wǎng)絡(luò)、路由與服務(wù)發(fā)現(xiàn)、分批發(fā)布、權(quán)限控制、鏡像倉(cāng)庫(kù)、網(wǎng)絡(luò)存儲(chǔ)到遠(yuǎn)程日志。

6.藍(lán)盾支持云上DevOps的范例

這是藍(lán)盾支持云上DevOps的范例，能夠?qū)崿F(xiàn)計(jì)劃、需求管理、設(shè)計(jì)、研發(fā)、構(gòu)建、測(cè)試、部署、搭建、監(jiān)控到運(yùn)營(yíng)等一整套工具閉環(huán)。

所以，從騰訊自研業(yè)務(wù)上云，再到一些合作伙伴的案例，對(duì)于上云的的趨勢(shì)，我們總結(jié)了五點(diǎn)經(jīng)驗(yàn)：

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

第二，全面擁抱DevOps，研發(fā)效率更高效。

第三，內(nèi)部的優(yōu)秀工具上云，給云提供更好的服務(wù)。

第四，整個(gè)開發(fā)團(tuán)隊(duì)心態(tài)更加開放、更加開源，主動(dòng)與開源社區(qū)協(xié)同，貢獻(xiàn)更多的功能特性。

第五，公有云經(jīng)受了QQ海量流量的錘煉，我們?cè)谏显七^程中，經(jīng)歷很多的經(jīng)驗(yàn)教訓(xùn)，邊上云邊解決問題，邊上云邊優(yōu)化，將整個(gè)公有云的基礎(chǔ)設(shè)施和服務(wù)錘煉成更加成熟。