騰訊業(yè)務上云實踐分析

1、 騰訊業(yè)務上云實踐分析目 錄 TOC o 1-3 h z u HYPERLINK l _Toc17666648 1.導語 PAGEREF _Toc17666648 h 3 HYPERLINK l _Toc17666649 2.上云的原因分析 PAGEREF _Toc17666649 h 3 HYPERLINK l _Toc17666650 2.1.騰訊業(yè)務的煙囪模式 PAGEREF _Toc17666650 h 3 HYPERLINK l _Toc17666651 2.2.兩大開放戰(zhàn)略并行 PAGEREF _Toc17666651 h 5 HYPERLINK l _Toc17666652 3.

2、上云的主要價值 PAGEREF _Toc17666652 h 7 HYPERLINK l _Toc17666653 4.上云方案 PAGEREF _Toc17666653 h 8 HYPERLINK l _Toc17666654 4.1.業(yè)務上云的三個階段 PAGEREF _Toc17666654 h 8 HYPERLINK l _Toc17666655 4.2.上云有哪些流程？ PAGEREF _Toc17666655 h 10 HYPERLINK l _Toc17666656 4.3.企業(yè)上云方案 PAGEREF _Toc17666656 h 12 HYPERLINK l _Toc1766

3、6657 4.4.上云過程中的安全 PAGEREF _Toc17666657 h 15 HYPERLINK l _Toc17666658 4.5.數(shù)據(jù)庫的遷移模式 PAGEREF _Toc17666658 h 16 HYPERLINK l _Toc17666659 4.6.云管平臺 PAGEREF _Toc17666659 h 18 HYPERLINK l _Toc17666660 5.QQ的所有用戶上云遷移 PAGEREF _Toc17666660 h 19 HYPERLINK l _Toc17666661 5.1.MySQL數(shù)據(jù)搬遷 PAGEREF _Toc17666661 h 20 HY

4、PERLINK l _Toc17666662 5.2.數(shù)據(jù)同步中心 PAGEREF _Toc17666662 h 21 HYPERLINK l _Toc17666663 5.3.混合云紅包的架構 PAGEREF _Toc17666663 h 23 HYPERLINK l _Toc17666664 5.4.云原生 PAGEREF _Toc17666664 h 25 HYPERLINK l _Toc17666665 5.5.TKE引擎 PAGEREF _Toc17666665 h 26 HYPERLINK l _Toc17666666 5.6.藍盾支持云上DevOps的范例 PAGEREF _To

5、c17666666 h 29導語傳統(tǒng)行業(yè)轉型的過程中，騰訊向來扮演的是數(shù)字化助手的角色，騰訊云作為幫助企業(yè)數(shù)字化轉型的入口，也已經成為騰訊的“獨角獸”業(yè)務。然而伴隨著云業(yè)務的增長，騰訊內部業(yè)務如何上云，對于外界來說一直是個秘密。騰訊的業(yè)務量非常龐大，社交業(yè)務包括QQ和空間的體量有近二十萬臺服務器，分布在全國三地。要把如此龐大體積的業(yè)務搬到云上，可以稱之為“把大象搬到云端”。本文分四個方面向大家介紹騰訊自研業(yè)務上云的故事。第一是騰訊業(yè)務為什么要上公有云，第二是業(yè)務上云的價值，第三是如何上云，第四是以QQ上云的案例分享業(yè)務上云的過程。上云的原因分析騰訊業(yè)務的煙囪模式2018年以前，騰訊的業(yè)務線是類

6、似煙囪一樣的模式，每個業(yè)務事業(yè)群從邏輯層、數(shù)據(jù)層到后端的容器或虛機層，都是獨立一套技術框架和技術體系。每個事業(yè)群之間的框架多數(shù)是不通用的，一個騰訊的員工從IEG轉崗到微信事業(yè)群，發(fā)現(xiàn)他的開發(fā)框架可能都要重新熟悉。一個新人來到騰訊之后，面臨那么多的服務框架，也不知道如何選擇合適的框架著手。甚至在騰訊的內部論壇上，經常有很多新人發(fā)帖問，我該選什么樣的工具，我該選什么樣的框架，這種情況就導致三種困惑：第一個是很多工程師不斷抱怨為什么騰訊內部有這么多名詞，不同的工具、不同的框架、不同的平臺、不同的數(shù)據(jù)庫和不同的存儲等等。第二個是很多部門都開發(fā)和使用自己的一套東西，跟其他部門缺乏分享和協(xié)作。第三個是開源

7、文化氛圍不強。很多部門的代碼不開放，或者缺乏文檔。我們知道成為一個優(yōu)秀的組件，組件的文檔、支持、社區(qū)都是非常重要的，沒有這些支持的話，你很難把一個組件做到最優(yōu)，但是在騰訊內部很多組件是缺少文檔，支持力度不足，甚至出現(xiàn)很多無人維護的孤兒組件。兩大開放戰(zhàn)略并行基于以上問題，為了技術體系革新，930調整后，騰訊內部做了大變革，包括成立新的云事業(yè)群，公司內部成立“技術委員會”，啟動“開源協(xié)同”和“自研業(yè)務上云”的兩大戰(zhàn)略方向。首先，開源協(xié)同就是在騰訊內部，所有的開發(fā)團隊代碼都是開放的，騰訊內部有統(tǒng)一代碼庫，所有的團隊及個人的代碼都要在上面公開提交、公開發(fā)布。團隊與團隊協(xié)作更好，隨時可以去創(chuàng)建個分支，或

8、者提交更豐富的特性功能，形成公司內的開源代碼文化，創(chuàng)建更好的工程師氛圍。其次是“自研業(yè)務上云”?；诠性频难邪l(fā)模式，使用云上豐富的組件、豐富的服務，把內部的一些優(yōu)秀的工具和組件上云，對外開放，在云上做服務。在客戶的激勵驅動下，不斷迭代成為行業(yè)內的領先水平。這是騰訊技術領域一個很大的變革。上云的主要價值第一是業(yè)務價值，業(yè)務的研發(fā)效率更高，從0到1開發(fā)一個新產品短短一周就能完成，微服務框架、數(shù)據(jù)庫、容器資源、持續(xù)集成、持續(xù)交付、統(tǒng)一配置中心等等，云上都有現(xiàn)成的服務，研發(fā)團隊不需要到處拼裝各種組件和工具，可以更專注業(yè)務研發(fā)。第二是工程師價值，工程師可以使用到整個業(yè)界最標準化的服務，基于公有云的研發(fā)

9、模式，能夠離開封閉的開發(fā)環(huán)境和組件，同時工程師還可以輸出非常優(yōu)秀的組件到云上成為服務，這也是大多數(shù)工程師的夢想。第三是客戶價值，可以給行業(yè)輸出非常多的公有云的經驗。截至2019年初，騰訊正式發(fā)布的對外開源項目將近70個，諸如騰訊云T stack、藍鯨智云BlueKing CMDB、微信開源系列和TARS等，都是騰訊開源的典型案例。上云方案業(yè)務上云的三個階段騰訊自研業(yè)務上云也并不是一蹴而就的，而是有三個階段：第一階段是從2017年開始直播類業(yè)務的上云。直播業(yè)務上云模式是一整套直播業(yè)務從自研機房搬遷到公有云機房，在騰訊云上提供服務，完成國內和海外幾十個節(jié)點的建設，服務于自研的直播業(yè)務和外部客戶。上

10、云時打通了內部的運營管理系統(tǒng)和監(jiān)控系統(tǒng)，同時支持跨云的管理。第二個階段是沙箱云，這個階段是在騰訊云上建立一個邏輯隔離的私有網絡空間，利用騰訊云的IaaS服務，使用云的虛擬機、云的網絡、云的機房來支撐自研業(yè)務的服務。不過這類模式只屬于基礎平臺上云，并不是整體業(yè)務體系完整上云。第三階段，是在騰訊“930”變革之前， 2018年6月我們就已經開始擁抱公有云，啟動自研的整個業(yè)務從私有云遷到公有云，這是把整個業(yè)務連根拔起搬遷到云上。上云之前，2017年，我們所有QQ用戶還在私有云上，到了2018年年底，就已經把一成半的QQ用戶從華南區(qū)遷到廣州云。到了2019年的6月，已經有三成的QQ用戶在云上，每6個Q

11、Q用戶就有2個是在云上。我們計劃到2019年年底，QQ實現(xiàn)華南、華東和華北三大區(qū)域的所有用戶全部都遷到云上，實現(xiàn)完整的QQ公有云上服務。上云有哪些流程？在上云的過程中，我們可以直觀地感知到，跟之前煙囪式的架構不同，上云后像IEG、PCG、WXG等事業(yè)群等，都將在公有云上運行各自的業(yè)務。業(yè)務會使用公有云的CLB、接入服務、服務框架，云PaaS服務，包括Redis、MySQL、Kafka、ES、CBS、COS等等，還有像K8S這些公有云上的原生服務。為了實現(xiàn)這一點，我們做了一些改造，在每個區(qū)域的公有云和私有云機房之間拉了專線，實現(xiàn)了公有云私有網絡到私有云機房的互通，保證業(yè)務能夠來回遷移及訪問內部服

12、務能力。根據(jù)業(yè)務體量不同，業(yè)務采用三種方式上云，有改造后上云，有邊改造邊上云，有先上云再改造。業(yè)務可以根據(jù)自己的人力資源和上云計劃，選擇對應的上云方式。下圖是整個業(yè)務團隊在上云的過程中所做的幾個流程：第一是測試，包括公有云上的網絡、存儲、虛擬機、核心服務，以及單機性能、服務吞吐性能、存儲讀寫性能、業(yè)務模塊性能等等都經過測試。通過測試之后，我們和云團隊一起優(yōu)化了服務性能，對業(yè)務也相應做了改造適配。第二是業(yè)務上云方案，包括安全方案、容量評估、服務遷移方案和數(shù)據(jù)遷移方案等。第三是業(yè)務遷移，遷移包括接入層、邏輯層、數(shù)據(jù)層及文件存儲等的遷移。第四是混合云共存，業(yè)務會逐漸灰度遷移到云上，比如在線用戶從5%

13、、10%、20%、30%到100%等，是一個灰度遷移過程。在灰度過程中可以及早發(fā)現(xiàn)各種問題，逐一解決，避免大規(guī)模上量時出現(xiàn)災難性后果。這個過程中就存在公有云和私有云的混合部署模式，就要重點關注專線使用容量，做好專線在業(yè)務高峰期的預案，以及業(yè)務跨混合云訪問的服務延遲，及時做好用戶在不同云之間調度的策略和方法。最后是業(yè)務監(jiān)控。上了云之后使用立體化的監(jiān)控體系，度量服務調用質量、用戶訪問質量和服務可用率等，譬如跟蹤用戶在私有云和公有云的訪問延遲有沒有變差，不能變壞，運營質量有沒有跟原來保持一致，甚至變得更好。從測試、方案、遷移、混合到監(jiān)控，這是我們上云團隊所實施的上云遷移整體流程。企業(yè)上云方案根據(jù)騰訊

14、自研業(yè)務上云，團隊所積累的經驗之上，我們抽象出完整的上云方案，也十分符合很多企業(yè)上云的實際情況，方案分五個階段：1）第一階段：規(guī)劃規(guī)劃中要對業(yè)務進行系統(tǒng)化的梳理，包括業(yè)務評估、容量評估、業(yè)務架構、組織體系。組織體系是指上云后組織架構和職能的變化，包括運維職責的變化：例如不再有中間件的運維人員，研發(fā)流程的變化；研發(fā)、測試和生產環(huán)境如何在混合云甚至多云中共存；資源預核算的變化；以前是購買機架和服務器，現(xiàn)在是先充值再按量計費；故障處理流程的變化等。技術體系的組織都要準備跟著公有云轉變。2）第二階段：方案規(guī)劃和設計要做好詳細的遷移方案，風險預案，回滾預案，混合云預案，多云預案等，譬如上云過程中數(shù)據(jù)遷移

15、有問題，出現(xiàn)丟數(shù)據(jù)，我該如何解決等等。3）第三階段：驗證這個是非常核心的階段，上云前，要有預測試、預驗證的過程?？梢园岩恍┖诵哪K，譬如高并發(fā)，或延遲非常敏感的模塊，在云上做好充分的壓測，并跟云服務團隊一起優(yōu)化解決各種問題。4）第四階段：業(yè)務遷移遷移就更復雜了，包括服務和數(shù)據(jù)怎么遷、怎么做好備份，遷移過程中對業(yè)務有沒有影響，我們用云的通用遷移工具，還是我們自己開發(fā)的遷移工具。上云過程中，做好對灰度模塊的觀察，通過客戶端服務質量，服務間調用延遲，全網撥測等監(jiān)控指標觀察業(yè)務有沒有問題。5）第五階段：持續(xù)運營整個服務運營體系都變了，基礎運維和公共運維團隊變成由公有云的運維團隊來支持。內部使用的開源監(jiān)

16、控工具，或者改造成支持公有云的資源監(jiān)控，或者使用云上成熟的監(jiān)控SaaS服務。CMDB要支持多云管理。運營流程也發(fā)生很大的變化，服務SLA要跟公有云服務商一起制定。上云過程中的安全當然，上云的過程中，安全是不可或缺且關鍵的一環(huán)，騰訊是一個非常注重安全的公司，特別是用戶數(shù)據(jù)安全。我們在上云安全這塊做了很多安全方案。自研內部、企業(yè)內部我們有一整套自研的安全體系。上云后，我們結合云上的一些安全產品，以及原來自研的安全服務和安全策略，制定混合云的安全通用體系。首先在公有云的大網里，我們會劃出一個獨立的私有網絡VPC，業(yè)務分別去部署。之上有網絡防護以及網絡安全的產品服務。主機上有主機防護，漏洞掃描等。業(yè)務

17、層有應用防護，運維有運維安全，云上有豐富的產品可以去使用。然后我們也打造了一些內部積累的安全方案，并回饋到云上。形成了公有云安全產品和自研安全產品兩者相互匹配融合的上云案例解決方案。事實上，整個公有云的安全策略和私有云是一樣的，沒有什么根本性的差別。數(shù)據(jù)庫的遷移模式在上云過程中，也必然會遭遇到一些比較大的挑戰(zhàn)，比如數(shù)據(jù)的遷移。在私有云到公有云的數(shù)據(jù)搬遷模式中，我們有四種模式給業(yè)務選擇。首先是私有組件數(shù)據(jù)遷移到公有云的模式。騰訊內部有很多自研的數(shù)據(jù)庫，像QQ的Grocery KV存儲使用的是內部私有協(xié)議，云上沒有對應服務。業(yè)務需要將數(shù)據(jù)從私有組件遷移到Redis。我們采取冷遷移的方式，先將數(shù)據(jù)全

18、備，然后把數(shù)據(jù)導到云上Redis集群，導完后開始做新增數(shù)據(jù)追加。怎么追加呢？我們用數(shù)據(jù)同步中心來實現(xiàn)。后面會有同步中心實現(xiàn)的架構。數(shù)據(jù)同步完之后，我們通知業(yè)務可以切割，留一個業(yè)務低峰期時間，比如晚上凌晨2點，花1分鐘把數(shù)據(jù)路由服務從自研IDC切到公有云Redis集群上。第二、三種模式可以統(tǒng)稱為開源組件到公有云。我們內部有一些業(yè)務，在開源組件之上做二次開發(fā)，譬如基于單機Redis實現(xiàn)自研分布式Redis集群。這些基于自研或開源組件的數(shù)據(jù)遷移到公有云上對應的數(shù)據(jù)服務，可通過DTS遷移工具來實現(xiàn)。這個非常簡單，也是業(yè)界非常通用的做法，我們直接用云上的DTS來做自助遷移。這個工具甚至不需要運維操作，開

19、發(fā)團隊自己在DTS窗口上輸入幾個參數(shù)，點個搬遷按紐后就可以自助搬遷。搬遷完成后自助切換或自動切換。第四種模式是私有組件直接上云。因為有一些組件云上沒有，業(yè)務也沒有資源將私有組件改造成云的標準服務，這個時候業(yè)務就將組件集群直接在云上部署一套，數(shù)據(jù)通過同步中心或主備備等方式搬遷到公有云上。比如說我在深圳的自研有一臺主兩臺備，那么我再把備3、備4放到廣州云，數(shù)據(jù)同時同步到私有云的兩個備和公有云的兩個備機模式。所有的主備數(shù)據(jù)完全同步完成之后，我們再把公有云的備變成主，自研云的主變成備，就相當于是做了切換。云管平臺還有一點非常核心的就是云管平臺。之前內部的配置系統(tǒng)、監(jiān)控系統(tǒng)、CMDB等等，都是基于私有云

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

21、和解決的問題。QQ的所有用戶上云遷移前面講了業(yè)務上云的思路和方法，QQ上云是走了這樣一個經歷。下圖就是一張全國地圖， QQ業(yè)務有三大區(qū)域的數(shù)據(jù)中心，有華北自研，2015年這里曾發(fā)生了一個很大的爆炸事件，當時我們還把天津的用戶調回了華南和華東區(qū)域。上海有華東自研機房，深圳有華南自研機房，在香港還有一些海外的出口。三大區(qū)域各有三成多的QQ在線用戶。根據(jù)用戶分布情況，QQ上云時，在華東、華南、華北三地，在騰訊云建設的云機房上，我們創(chuàng)建了業(yè)務的公有云網絡，然后把QQ業(yè)務從各地的自研機房往云上遷移。QQ上云中業(yè)務架構圖分成了三大區(qū)域，分別是華北、華東、華南，而華南分成了廣州云和深圳自研機房兩大機房。目前

22、是“三云一地”。每個區(qū)域都是完全獨立的存儲和業(yè)務邏輯服務。可以把華南的整個用戶全部都調度到華北和華東區(qū)。業(yè)務隨時將用戶從不同的云區(qū)域和自研區(qū)域來回調度。MySQL數(shù)據(jù)搬遷我們接著看下業(yè)務的MySQL數(shù)據(jù)搬遷案例，詳細見下圖，它有主從的模式。我們沒有通過IP和PORT來尋址，而是通過內部的DNS類名字服務來尋址。先分配業(yè)務一個實例的名稱，然后通過DNS拿到這個實例的IP端口，再去訪問具體的實例。從自研的IDC使用騰訊云DTS遷移工具，把數(shù)據(jù)導到云的MySQL。數(shù)據(jù)自動導入完成后，開發(fā)團隊只需要在云上切換服務就可以完成數(shù)據(jù)實例的遷移。這種適合一些數(shù)據(jù)體量不大的業(yè)務數(shù)據(jù)遷移。還有一種是主備的模式，即

23、在深圳自研有數(shù)據(jù)庫服務器的主和備，在云機房新部署幾臺備機。通過主備同步的方式，把所有數(shù)據(jù)都同步到云機房。然后將云機房的某臺備機切換成主機，將自研的主機降級為備機。這樣就切換為云機房主備，自研機房備的模式。數(shù)據(jù)同步中心還有更復雜的是數(shù)據(jù)同步中心。這種是適合業(yè)務量非常大，有全國多地分布的業(yè)務。服務模塊寫數(shù)據(jù)的時候，統(tǒng)一寫到各地的接入代理，代理統(tǒng)一寫一地，譬如深圳自研的寫服務。寫服務的轉發(fā)存儲會將新增記錄同時寫到各地自研、各地的云機房，實現(xiàn)最終數(shù)據(jù)一致性；用戶就近讀，比如華北的用戶，就讀華北云的這個數(shù)據(jù)存儲集群，華南就讀華南的數(shù)據(jù)存儲存儲；通過同步中心的方式完成大規(guī)模數(shù)據(jù)的混合云同步。當要增加一個成

24、都云區(qū)域，我們只需在當?shù)卦黾右惶淄椒?，增加路由服務?guī)則，同步服務就會自動把數(shù)據(jù)同步到成都的云機房。這種方式適合對延遲不敏感的業(yè)務，譬如社交業(yè)務的點贊、發(fā)表說說等。一般從深圳自研同步到上海和天津的時候延遲達到幾十毫秒，延遲非常高，不適合金融行業(yè)等延時高敏感業(yè)務模式?；旌显萍t包的架構從2014年開始，每年春節(jié)騰訊都有春節(jié)紅包活動，今年春節(jié)我們首次在公有云和私有云之間做了紅包的兩地混合。我們在廣州云部署了與自研相同規(guī)模的紅包服務模塊，包括數(shù)據(jù)集群，在春節(jié)前演練及預熱階段，充分對廣州云服務做了各種測試和驗證，包括跨城專線延遲對業(yè)務的影響程度。紅包活動期間，用戶在接入的時候根據(jù)用戶的ID分片或用戶來

25、源，通過路由策略分流到廣州云機房和深圳自研機房。春節(jié)期間，混合云扛住了整個紅包活動的用戶流量。驗證了跨地域的混合云完全能支持億級的業(yè)務大并發(fā)流量。當然我們也做了很多方案，比如萬一公有云的紅包模塊沒有扛住，我們怎么辦？如果我們發(fā)現(xiàn)用戶在云上有大量失敗，我們就把用戶在幾分鐘以內切回到深圳云，甚至把整個業(yè)務從云上切回本地，我們有信心去扛云機房的壓力。在上云過程中，QQ研發(fā)自身也對業(yè)務進行了優(yōu)化，積極擁抱變化，做了很多處服務的改造，以能夠適應新一代的基礎設施。服務邏輯上，很多個業(yè)務直接使用云PaaS服務，如長消息、加群邏輯等用了云Redis存儲服務。更多的服務遷移到TKE之上，一些內存存儲服務，譬如資

26、料、關系鏈等數(shù)據(jù)存儲層做了鏈接數(shù)、數(shù)據(jù)副本擴展、混合云單元分布等架構層級的優(yōu)化改造。上云前后，上云團隊對業(yè)務質量非常關注，不斷對比二個云之間的可用率、客戶訪問質量、服務間調用延遲等質量數(shù)據(jù)。上云前后， 經過各個架構層的優(yōu)化，業(yè)務質量數(shù)據(jù)最終保持私有云和公有云一致，保證了用戶訪問體驗。云原生上云不僅是為了上云，我們更多要擁抱業(yè)界開源生態(tài)。要用云上優(yōu)秀成熟的產品和服務。在開發(fā)方法、業(yè)務交付、云原生服務等方面，業(yè)務上云前后已經是部分甚至全部擁抱云原生的體系。我們已經把TAPD研發(fā)管理工具、工蜂代碼倉庫，還有藍盾、橘子CI、QCI、coding等集成為工具鏈，在云上打造了一個持續(xù)集成、持續(xù)部署的Dev

27、Ops流水線閉環(huán)。目前在云上的交付，業(yè)務每周都有幾百次的交付是通過容器來完成的，從以前的包交付變成容器交付。在微服務這塊，像SF2、SPP、TAF等，我們內部不同業(yè)務已經使用了很多微服務框架，并計劃在公司內迭代升級更優(yōu)秀的微服務框架。TKE引擎K8S平臺上，我們用了騰訊的TKE引擎，這是一個跟K8S完全兼容的引擎。我?guī)滋烨案粋€業(yè)界公司聊，他們在騰訊云、阿里云上買了K8S服務，自己內部也部署了K8S集群。他們的容器可以隨時、同時交付到騰訊云、阿里云和他們本身的K8S集群，而不用做任何改動。通過容器交付，業(yè)務可以不用考慮環(huán)境依賴等問題，交付變得更敏捷和輕松。我們基于TKE之上做了功能定制和優(yōu)化。