傳統行業轉型的過程中，騰訊向來扮演的是數字化助手的角色，騰訊雲作爲幫助企業數字化轉型的入口，也已經成爲騰訊的“獨角獸”業務。然而伴隨着雲業務的增長，騰訊內部業務如何上雲，對於外界來說一直是個祕密。近日，騰訊自研上雲項目負責人周小軍首次披露，騰訊如何把內部海量的自研業務搬上雲端的故事。以下是他的分享內容。
大家好，我今天分享的核心內容有三個：
- 騰訊自研業務如何從私有云的模式搬遷到公有云；
- 如何把這些大體量的業務搬到雲端；
- 如何擁抱雲原生。
騰訊的業務量非常龐大，社交業務包括 QQ 和空間的體量有近二十萬臺服務器，分佈在全國三地。要把如此龐大體積的業務搬到雲上，可以稱之爲“把大象搬到雲端”。
今天我就分四個方面向大家介紹騰訊自研業務上雲的故事。第一是騰訊業務爲什麼要上公有云；第二個是業務上雲的價值；第三個是如何上雲；第四個是以 QQ 上雲的案例分享業務上雲的過程。
2018 年以前，騰訊業務的煙囪模式
爲什麼要上雲？
2018 年以前，騰訊的業務線是類似煙囪一樣的模式，每個業務事業羣從邏輯層、數據層到後端的容器或虛機層，都是獨立一套技術框架和技術體系。每個事業羣之間的框架多數是不通用的，一個騰訊的員工從 IEG 轉崗到微信事業羣，發現他的開發框架可能都要重新熟悉。一個新人來到騰訊之後，面臨那麼多的服務框架，也不知道如何選擇合適的框架着手。
甚至在騰訊的內部論壇上，經常有很多新人發帖問，我該選什麼樣的工具，我該選什麼樣的框架，這種情況就導致三種困惑：
- 第一個是很多工程師不斷抱怨爲什麼騰訊內部有這麼多名詞，不同的工具、不同的框架、不同的平臺、不同的數據庫和不同的存儲等等；
- 第二個是很多部門都開發和使用自己的一套東西，跟其他部門缺乏分享和協作；
- 第三個是開源文化氛圍不強。很多部門的代碼不開放，或者缺乏文檔。我們知道成爲一個優秀的組件，組件的文檔、支持、社區都是非常重要的，沒有這些支持的話，你很難把一個組件做到最優，但是在騰訊內部很多組件是缺少文檔，支持力度不足，甚至出現很多無人維護的孤兒組件。
兩大開放戰略並行
基於以上問題，爲了技術體系革新，“930”調整後，騰訊內部做了大變革，包括成立新的雲事業羣，公司內部成立“技術委員會”，啓動“開源協同”和“自研業務上雲”的兩大戰略方向。
首先，開源協同就是在騰訊內部，所有的開發團隊代碼都是開放的，騰訊內部有統一代碼庫，所有的團隊及個人的代碼都要在上面公開提交、公開發布。團隊與團隊協作更好，隨時可以去創建個分支，或者提交更豐富的特性功能，形成公司內的開源代碼文化，創建更好的工程師氛圍。
其次是“自研業務上雲”。基於公有云的研發模式，使用雲上豐富的組件、豐富的服務，把內部的一些優秀的工具和組件上雲，對外開放，在雲上做服務。在客戶的激勵驅動下，不斷迭代成爲行業內的領先水平。
這是騰訊技術領域一個很大的變革。
那麼，上雲的價值是什麼？
第一是業務價值，業務的研發效率更高，從 0 到 1 開發一個新產品短短一週就能完成，微服務框架、數據庫、容器資源、持續集成、持續交付、統一配置中心等等，雲上都有現成的服務，研發團隊不需要到處拼裝各種組件和工具，可以更專注業務研發。
第二是工程師價值，工程師可以使用到整個業界最標準化的服務，基於公有云的研發模式，能夠離開封閉的開發環境和組件，同時工程師還可以輸出非常優秀的組件到雲上成爲服務，這也是大多數工程師的夢想。
第三是客戶價值，可以給行業輸出非常多的公有云的經驗。
截至 2019 年初，騰訊正式發佈的對外開源項目將近 70 個，諸如騰訊雲 T stack、藍鯨智雲 BlueKing CMDB、微信開源系列和 TARS 等，都是騰訊開源的典型案例。
業務上雲的三個階段
騰訊自研業務上雲也並不是一蹴而就的，而是有三個階段。
第一階段是從 2017 年開始直播類業務的上雲。直播業務上雲模式是一整套直播業務從自研機房搬遷到公有云機房，在騰訊雲上提供服務，完成國內和海外幾十個節點的建設，服務於自研的直播業務和外部客戶。上雲時打通了內部的運營管理系統和監控系統，同時支持跨雲的管理。
第二個階段是沙箱雲，這個階段是在騰訊雲上建立一個邏輯隔離的私有網絡空間，利用騰訊雲的 IaaS 服務，使用雲的虛擬機、雲的網絡、雲的機房來支撐自研業務的服務。不過這類模式只屬於基礎平臺上雲，並不是整體業務體系完整上雲。
第三階段，是在騰訊“930”變革之前， 2018 年 6 月我們就已經開始擁抱公有云，啓動自研的整個業務從私有云遷到公有云，這是把整個業務連根拔起搬遷到雲上。
上雲之前，2017 年，我們所有 QQ 用戶還在私有云上，到了 2018 年年底，就已經把一成半的 QQ 用戶從華南區遷到廣州雲。到了 2019 年的 6 月，已經有三成的 QQ 用戶在雲上，每 6 個 QQ 用戶就有 2 個是在雲上。我們計劃到 2019 年年底，QQ 實現華南、華東和華北三大區域的所有用戶全部都遷到雲上，實現完整的 QQ 公有云上服務。
上雲有哪些流程，如何規避風險？
在上雲的過程中，我們可以直觀的感知到，跟之前煙囪式的架構不同，上雲後像 IEG、PCG、WXG 等事業羣等，都將在公有云上運行各自的業務。業務會使用公有云的 CLB、接入服務、服務框架，雲 PaaS 服務，包括 Redis 、 MySQL 、 Kafka 、ES、CBS、COS 等等，還有像 K8s 這些公有云上的原生服務。
爲了實現這一點，我們做了一些改造，在每個區域的公有云和私有云機房之間拉了專線，實現了公有云私有網絡到私有云機房的互通，保證業務能夠來回遷移及訪問內部服務能力。
根據業務體量不同，業務採用三種方式上雲，有改造後上雲，有邊改造邊上雲，有先上雲再改造。業務可以根據自己的人力資源和上雲計劃，選擇對應的上雲方式。
上圖是整個業務團隊在上雲的過程中所做的幾個流程。
第一是測試，包括公有云上的網絡、存儲、虛擬機、核心服務，以及單機性能、服務吞吐性能、存儲讀寫性能、業務模塊性能等等都經過測試。通過測試之後，我們和雲團隊一起優化了服務性能，對業務也相應做了改造適配。
第二是業務上雲方案，包括安全方案、容量評估、服務遷移方案和數據遷移方案等。
第三是業務遷移，遷移包括接入層、邏輯層、數據層及文件存儲等的遷移。
第四是混合雲共存，業務會逐漸灰度遷移到雲上，比如在線用戶從 5%、10%、20%、30% 到 100% 等，是一個灰度遷移過程。在灰度過程中可以及早發現各種問題，逐一解決，避免大規模上量時出現災難性後果。這個過程中就存在公有云和私有云的混合部署模式，就要重點關注專線使用容量，做好專線在業務高峯期的預案，以及業務跨混合雲訪問的服務延遲，及時做好用戶在不同雲之間調度的策略和方法。
最後是業務監控。上了雲之後使用立體化的監控體系，度量服務調用質量、用戶訪問質量和服務可用率等，譬如跟蹤用戶在私有云和公有云的訪問延遲有沒有變差，不能變壞，運營質量有沒有跟原來保持一致，甚至變得更好。
從測試、方案、遷移、混合到監控，這是我們上雲團隊所實施的上雲遷移整體流程。
根據騰訊自研業務上雲，團隊所積累的經驗之上，我們抽象出完整的上雲方案，也十分符合很多企業上雲的實際情況，方案分五個階段。
第一階段：規劃。規劃中要對業務系統化的梳理，包括業務評估、容量評估、業務架構、組織體系。組織體系是指上雲後組織架構和職能的變化，包括運維職責的變化：例如不再有中間件的運維人員，研發流程的變化；研發、測試和生產環境如何在混合雲甚至多雲中共存；資源預覈算的變化；以前是購買機架和服務器，現在是先充值再按量計費；故障處理流程的變化等。技術體系的組織都要準備跟着公有云轉變。
第二階段，方案規劃和設計。要做好詳細的遷移方案，風險預案，回滾預案，混合雲預案，多雲預案等，譬如上雲過程中數據遷移有問題，出現丟數據，我該如何解決等等。
第三階段，驗證。這個是非常核心的階段，上雲前，要有預測試、預驗證的過程。可以把一些核心模塊，譬如高併發，或延遲非常敏感的模塊，在雲上做好充分的壓測，並跟雲服務團隊一起優化解決各種問題。
第四階段，業務遷移。遷移就更復雜了，包括服務和數據怎麼遷、怎麼做好備份，遷移過程中對業務有沒有影響，我們用雲的通用遷移工具，還是我們自己開發的遷移工具。上雲過程中，做好對灰度模塊的觀察，通過客戶端服務質量，服務間調用延遲，全網撥測等監控指標觀察業有沒有問題。
第五階段，持續運營。整個服務運營體系都變了，基礎運維和公共運維團隊變成由公有云的運維團隊來支持。內部使用的開源監控工具，或者改造成支持公有云的資源監控，或者使用雲上成熟的監控 SaaS 服務。CMDB 要支持多雲管理。運營流程也發生很大的變化，服務 SLA 要跟公有云服務商一起制定。
當然，上雲的過程中，安全是不可或缺且關鍵的一環，騰訊是一個非常注重安全的公司，特別是用戶數據安全。我們在上雲安全這塊做了很多安全方案。自研內部、企業內部我們有一整套自研的安全體系。上雲後，我們結合雲上的一些安全產品，以及原來自研的安全服務和安全策略，制定混合雲的安全通用體系。
首先在公有云的大網裏，我們會劃出一個獨立的私有網絡 VPC，業務分別去部署。之上有網絡防護以及網絡安全的產品服務。主機上有主機防護，漏洞掃描等。業務層有應用防護，運維有運維安全，雲上有豐富的產品可以去使用。然後我們也打造了一些內部積累的安全方案，並回饋到雲上。形成了公有云安全產品和自研安全產品兩者相互匹配融合的上雲案例解決方案。
事實上，整個公有云的安全策略和私有云是一樣的，沒有什麼根本性的差別。
在上雲過程中，也必然會遭遇到一些比較大的挑戰，比如數據的遷移。在私有云到公有云的數據搬遷模式中，我們有四種模式給業務選擇。
首先是私有組件數據遷移到公有云的模式。騰訊內部有很多自研的數據庫，像 QQ 的 Grocery KV 存儲使用的是內部私有協議，雲上沒有對應服務。業務需要將數據從私有組件遷移到 Redis。
我們採取冷遷移的方式，先將數據全備，然後把數據導到雲上 Redis 集羣，導完後開始做新增數據追加。怎麼追加呢？我們用數據同步中心來實現。後面會有同步中心實現的架構。數據同步完之後，我們通知業務可以切割，留一個業務低峯期時間，比如晚上凌晨 2 點，花 1 分鐘把數據路由服務從自研 IDC 切到公有云 Redis 集羣上。
第二、三種模式可以統稱爲開源組件到公有云。我們內部有一些業務，在開源組件之上做二次開發，譬如基於單機 Redis 實現自研分佈式 Redis 集羣。這些基於自研或開源組件的數據遷移到公有云上對應的數據服務，可通過 DTS 遷移工具來實現。
這個非常簡單，也是業界非常通用的做法，我們直接用雲上的 DTS 來做自助遷移。這個工具甚至不需要運維操作，開發團隊自己在 DTS 窗口上輸入幾個參數，點個搬遷按紐後就可以自助搬遷。搬遷完成後自助切換或自動切換。
第四種模式是私有組件直接上雲。因爲有一些組件雲上沒有，業務也沒有資源將私有組件改造成雲的標準服務，這個時候業務就將組件集羣直接在雲上部署一套，數據通過同步中心或主備備等方式搬遷到公有云上。
比如說我在深圳的自研有一臺主兩臺備，那麼我再把備 3、備 4 放到廣州雲，數據同時同步到私有云的兩個備和公有云的兩個備機模式。所有的主備數據完全同步完成之後，我們再把公有云的備變成主，自研雲的主變成備，就相當於是做了切換。
還有一點非常核心的就是雲管平臺。之前內部的配置系統、監控系統、CMDB 等等，都是基於私有云的管理模式。業務上雲之後，我們很多運營系統要改造成支持混合雲，支持多雲的管理模式。譬如業務模塊會有 50 個實例在騰訊雲上，30 個實例在海外亞馬遜雲上，30 個實例在內部私有云裏，那麼我們的 CMDB 必須要支持多雲的資源管理。
從圖中可以看到，底下是我們的整個業務線，下面這些帳號體系、預覈算、企業安全、監控等等其他的應用工具或平臺，都要改造以適應混合雲模式。就拿帳號體系來說，內部員工以公有云的帳號登錄雲官網來購買、使用和運營公有云上的資源。但內部如何把帳號所使用的資源成本覈算到對應的業務，員工離職或轉崗後資源怎麼回收或轉移，如何把帳號綁定給企業組織架構，雲官網帳號登陸如何與內部 OA 鑑權等，都是必須要考慮和解決的問題。
如何把 QQ 的所有用戶搬上雲？
前面講了業務上雲的思路和方法，QQ 上雲是走了這樣一個經歷。上圖就是一張全國地圖， QQ 業務有三大區域的數據中心，有華北自研，2015 年這裏曾發生了一個很大的爆炸事件，當時我們還把天津的用戶調回了華南和華東區域。上海有華東自研機房，深圳有華南自研機房，在香港還有一些海外的出口。三大區域各有三成多的 QQ 在線用戶。
根據用戶分佈情況，QQ 上雲時，在華東、華南、華北三地，在騰訊雲建設的雲機房上，我們創建了業務的公有云網絡，然後把 QQ 業務從各地的自研機房往雲上遷移。
QQ 上雲中業務架構圖分成了三大區域，分別是華北、華東、華南，而華南分成了廣州雲和深圳自研機房兩大機房。目前是“三雲一地”。每個區域都是完全獨立的存儲和業務邏輯服務。可以把華南的整個用戶全部都調度到華北和華東區。業務隨時將用戶從不同的雲區域和自研區域來回調度。
我們接着看下業務的 MySQL 數據搬遷案例，詳細見上圖，它有主—從的模式。我們沒有通過 IP 和 PORT 來尋址，而是通過內部的 DNS 類名字服務來尋址。先分配業務一個實例的名稱，然後通過 DNS 拿到這個實例的 IP 端口，再去訪問具體的實例。從自研的 IDC 使用騰訊雲 DTS 遷移工具，把數據導到雲的 MySQL。數據自動導入完成後，開發團隊只需要在雲上切換服務就可以完成數據實例的遷移。這種適合一些數據體量不大的業務數據遷移。
還有一種是主備備的模式，即在深圳自研有數據庫服務器的主和備，在雲機房新部署幾臺備機。通過主備同步的方式，把所有數據都同步到雲機房。然後將雲機房的某臺備機切換成主機，將自研的主機降級爲備機。這樣就切換爲雲機房主備，自研機房備的模式。
還有更復雜的是數據同步中心。這種是適合業務量非常大，有全國多地分佈的業務。服務模塊寫數據的時候，統一寫到各地的接入代理，代理統一寫一地，譬如深圳自研的寫服務。
寫服務的轉發存儲會將新增記錄同時寫到各地自研、各地的雲機房，實現最終數據一致性。
用戶就近讀，比如華北的用戶，就讀華北雲的這個數據存儲集羣，華南就讀華南的數據存儲存儲。
通過同步中心的方式完成大規模數據的混合雲同步。當要增加一個成都雲區域，我們只需在當地好一套同步服務，增加路由服務規則，同步服務就會自動把數據同步到成都的雲機房。
這種方式適合對延遲不敏感的業務，譬如社交業務的點贊、發表說說等。一般從深圳自研同步到上海和天津的時候延遲達到幾十毫秒，延遲非常高，不適合金融行業等延時高敏感業務模式。
這是混合雲紅包的架構。
從 2014 年開始，每年春節騰訊都有春節紅包活動，今年春節我們首次在公有云和私有云之間做了紅包的兩地混合。我們在廣州雲部署了與自研相同規模的紅包服務模塊，包括數據集羣，在春節前演練及預熱階段，充分對廣州雲服務做了各種測試和驗證，包括跨城專線延遲對業務的影響程度。
紅包活動期間，用戶在接入的時候根據用戶的 ID 分片或用戶來源，通過路由策略分流到廣州雲機房和深圳自研機房。春節期間，混合雲扛住了整個紅包活動的用戶流量。驗證了跨地域的混合雲完全能支持億級的業務大併發流量。當然我們也做了很多方案，比如萬一公有云的紅包模塊沒有扛住，我們怎麼辦？如果我們發現用戶在雲上有大量失敗，我們就把用戶在幾分鐘以內切回到深圳雲，甚至把整個業務從雲上切回本地，我們有信心去扛雲機房的壓力。
在上雲過程中，QQ 研發自身也對業務進行了優化，積極擁抱變化，做了很多處服務的改造，以能夠適應新一代的基礎設施。
服務邏輯上，很多個業務直接使用雲 PaaS 服務，如長消息、加羣邏輯等用了雲 Redis 存儲服務。更多的服務遷移到 TKE 之上。
一些內存存儲服務，譬如資料、關係鏈等數據存儲層做了鏈接數、數據副本擴展、混合雲單元分佈等架構層級的優化改造。
上雲前後，上雲團隊對業務質量非常關注，不斷對比二個雲之間的可用率、客戶訪問質量、服務間調用延遲等質量數據。上雲前後， 經過各個架構層的優化，業務質量數據最終保持私有云和公有云一致，保證了用戶訪問體驗。
上雲不僅是爲了上雲，我們更多要擁抱業界開源生態。要用雲上優秀成熟的產品和服務。在開發方法、業務交付、雲原生服務等方面，業務上雲前後已經是部分甚至全部擁抱雲原生的體系。我們已經把 TAPD 研發管理工具、工蜂代碼倉庫，還有藍盾、橘子 CI、QCI、coding 等集成爲工具鏈，在雲上打造了一個持續集成、持續部署的 DevOps 流水線閉環。
目前在雲上的交付，業務每週都有幾百次的交付是通過容器來完成的，從以前的包交付變成容器交付。
在微服務這塊，像 SF2、SPP、TAF 等，我們內部不同業務已經使用了很多微服務框架，並計劃在公司內迭代升級更優秀的微服務框架。
K8s 平臺上，我們用了騰訊的 TKE 引擎，這是一個跟 K8s 完全兼容的引擎。我幾天前跟一個業界公司聊，他們在騰訊雲、阿里雲上買了 K8s 服務，自己內部也部署了 K8s 集羣。他們的容器可以隨時、同時交付到騰訊雲、阿里雲和他們本身的 K8s 集羣，而不用做任何改動。通過容器交付，業務可以不用考慮環境依賴等問題，交付變得更敏捷和輕鬆。
我們基於 TKE 之上做了功能定製和優化。TKE 有基於 CPU 負載等基礎容量的彈性伸縮能力。在 TKE 優秀的伸縮能力之上，我們還做了功能疊加，包括業務畫像，就是根據業務長期的趨勢和業務突發活動，去做趨勢預測和活動預測，通過算法來預估容量在什麼時間窗會達到多少水位，以準備相應的容器資源來提前幾小時擴容，應對突發流量。
上雲團隊、業務研發跟雲的 TKE 團隊合作，我們把業務特性跟 TKE 相融合，來做出一個特性更加豐富、滿足業務場景的 K8s 應用功能。譬如 QQ 是三地分佈，特別是上雲後又增加了自研和雲的機房屬性。原生 K8s 不支持跨地域的，因此我們做了跨地域的特性。
除此之外還有權限限制，業務對權限要求非常嚴格，是基於 IP 鑑權的。比如內部的業務模塊訪問 MySQL 時，要授權 MySQL 要給這些 IP 放行。容器是很難去做這種基於 IP 的權限管理，我們的容器都是用了固定 IP，每個容器都有自己的 IP，交付時註冊到 CMDB 上，並完成鑑權等自動化交付流程。
內部的 CI/CD，我們有很多的優秀工具，讓業務自行去選擇使用，開發團隊喜歡什麼樣的工具，從鏡像倉庫、到 CI、CD、CO 都能保持業務自己的習慣。
還有包括管理體系、安全、審計、服務監控、日誌、告警等功能特性，我們增加和優化了近百個特性，滿足 TKE 與海量業務結合。
於是，我們總結了八類的 TKE 業務應用適配，從業務管理、網絡、路由與服務發現、分批發布、權限控制、鏡像倉庫、網絡存儲到遠程日誌。
這是藍盾支持雲上 DevOps 的範例，能夠實現計劃、需求管理、設計、研發、構建、測試、部署、搭建、監控到運營等一整套工具閉環。
所以，從騰訊自研業務上雲，再到一些合作伙伴的案例，對於上雲的的趨勢，我們總結了五點經驗：
- 第一，徹底擁抱雲原生，用雲來滿足業務快速迭代，資源彈性伸縮的需求。
- 第二，全面擁抱 DevOps，研發效率更高效。
- 第三，內部的優秀工具上雲，給雲提供更好的服務。
- 第四，整個開發團隊心態更加開放、更加開源，主動與開源社區協同，貢獻更多的功能特性。
- 第五，公有云經受了 QQ 海量流量的錘鍊，我們在上雲過程中，經歷很多的經驗教訓，邊上雲邊解決問題，邊上雲邊優化，將整個公有云的基礎設施和服務錘鍊成更加成熟。
作者介紹：
周小軍，騰訊雲資深運維專家。加入騰訊以來先後負責騰訊社交事業羣數據存儲運維、接入架構運維、社交業務運維等運營工作。擁有十幾年互聯網 IT 運維經驗，精通互聯網海量業務規模技術架構、雲計算基礎架構、自動化運營系統、監控系統等領域。帶領團隊維護亞洲最大的數據庫集羣，以及春節 QQ 紅包、天津大調度等海量規模業務的運營保障項目。所負責社交業務在線用戶 3 億 ，月活 8 億，20 多萬臺服務器集羣，全國三地三活數據中心。