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

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

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

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

如何擁抱云原生。

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

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

為什么要上云？

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

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

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

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

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

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

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

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

這是騰訊技術領域一個很大的變革。

上云的價值是什么？

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

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

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

如何上云？

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

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

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

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

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

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

2. 上云有哪些流程？

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

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

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

下圖是整個業(yè)務團隊在上云的過程中所做的幾個流程：

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

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

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

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

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

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

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

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

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

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

第三階段是驗證。這個是非常核心的階段，上云前，要有預測試、預驗證的過程?？梢园岩恍┖诵哪K，譬如高并發(fā)，或延遲非常敏感的模塊，在云上做好充分的壓測，并跟云服務團隊一起優(yōu)化解決各種問題。

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

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

4.上云過程中的安全

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

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

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

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

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

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

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

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

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

第四種模式是私有組件直接上云。因為有一些組件云上沒有，業(yè)務也沒有資源將私有組件改造成云的標準服務，這個時候業(yè)務就將組件集群直接在云上部署一套，數(shù)據(jù)通過同步中心或主備備等方式搬遷到公有云上。

比如說我在深圳的自研有一臺主兩臺備，那么我再把備3、備4放到廣州云，數(shù)據(jù)同時同步到私有云的兩個備和公有云的兩個備機模式。所有的主備數(shù)據(jù)完全同步完成之后，我們再把公有云的備變成主，自研云的主變成備，就相當于是做了切換。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3. 混合云紅包的架構

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

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

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

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

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

4.云原生

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

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

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

5.TKE引擎

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

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

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

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

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

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

6.藍盾支持云上DevOps的范例

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

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

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

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

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

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

第五，公有云經(jīng)受了QQ海量流量的錘煉，我們在上云過程中，經(jīng)歷很多的經(jīng)驗教訓，邊上云邊解決問題，邊上云邊優(yōu)化，將整個公有云的基礎設施和服務錘煉成更加成熟。