黃宏東：衝上雲霄-騰訊海量業務上雲實踐

• 2019 年 11 月 14 日
• 筆記

11月9日，雲+社區技術沙龍「高效智慧運維」圓滿落幕。本期沙龍圍繞運維展開了一場技術盛宴，從AIOps、Serverless DevOps、藍鯨PaaS平台、K8S等分享關於業務運維的技術實踐乾貨，同時帶來騰訊海量業務自研上雲實踐，推動傳統運維向雲運維轉型。下面是黃宏東老師關於騰訊海量自研業務上雲方案與實踐及過程中的問題解決方案的內容分享。

講師介紹：黃宏東，騰訊雲高級工程師，應用開發出生的運維，負責過多款業務的運維工作，目前主要參與騰訊自研業務上雲，推動業務從研發到運營體系的標準化、專業化，完善騰訊雲生態。

我會從四個方面進行分享。第一，主要講述騰訊業務為什麼要上雲；第二，業務上雲的價值；第三，如何上雲，上的過程是怎麼樣，過程中有哪些心得體會；第四，以QQ為案例和大家進行分享。

第一，為什麼要上雲？

在騰訊做開發既是幸福也有煩惱。騰訊的業務線非常廣泛，比如IEG做遊戲，PCG做資訊流，WXG做微信，每個BG都有自己的業務線。運維資源體系、研發體系，每個BG都會有自己訂製化的方案和架構。雖然也有公線部門來做基礎的解決方案，但每個業務都在快速成長，公線的支援就力不從心，對於個性化的需求，各個BG都有自己的實現方式。每個BG也都會有自己的支援體系，就像煙囪一樣，導致各個系統都不相通，開發人員、測試人員的工具也不一樣，導致跨部門合作也出現一些障礙。

平台與組件這麼多，對一個技術人員來說，並不是一個好事情。第一，選擇多但方案不通用；第二個，輪子在重複造，資源浪費。技術人員都容易患一個毛病，就是互相看不起，我看不起你的方案，你看不起我的方案，這樣對我們的成長是非常不利。缺乏統一的規範，技術支援也不足，造了很多輪子之後，輪子越來越舊，有一些老的服務還在用老的輪子，這些輪子，平時都用得挺好，也沒有什麼問題，越來越沒有人去關注它，當它出問題的時候，就很難解決。各部門間數據也不互通，程式碼封閉，跟業界缺乏交流。最重要的一點是我們沒有技術圖譜，在計算、框架、存儲、大數據應用等領域的技術圖譜。業務開發要選型組件，內部有什麼樣的可以選？它的功能是怎麼樣的？組件適合的業務場景？優缺點是怎麼樣的？我們很缺技術圖譜。

騰訊公司在2018年9月30日做組織架構變革，業務線和技術線都做了變革。業務線做了BG整合。我們不僅連接人、連接數據服務，在數據內容和服務上面還對產業和互聯網做了升級。另一條線是從技術上來進行調整，有兩大口號，也是兩大戰略方向，第一是開源協同，第二是自研上雲。開源協同就是將我們的源程式碼進行開源，然後互相協同來做一個事情。我們基準線是同一條，上面有不同的場景，業務線可以各自進行開發。騰訊有自己的雲，並且在中國也是第一梯隊，早期也有一小部分業務是在雲上成長。自研上雲成為主航向，同時我們也在對雲社區以及雲生態做出貢獻。

第二，業務上雲的價值

業務上雲的價值主要從三大方面。第一，對業務的價值，第二個，對工程師的價值，第三，對客戶的價值。

第一，業務的價值，其實是最重要的。上雲後研發效率會高很多。舉個例子，在國慶期間，互娛遊戲做了一個小活動，用了很多雲上組件，包括人臉識別、位置資訊等，用了很短的時間，兩三周就將它上線了。能夠支援這麼大體量、高可用的服務，雲功不可沒。還有豐富的公有雲海外資源，遊戲出海幫助很大。雲與自研的環境是一致的，運維體系、研發架構相互兼容，研發、測試、運維成本大大降低。

第二，工程師價值，上雲使用業界標準的雲原生服務，這對工程師非常有誘惑。運營環境和雲直接相通，開發、構建、測試、運維整個過程非常高效，一天做到好幾次發版。工程師輸出優秀的組件到雲上，成為標準服務，讓更多的人用，共建開源生態。

第三，客戶價值，為行業輸出公有雲遷移經驗，更豐富的雲服務和工具提供給客戶。這一塊我們也在沉澱，供給行業架構師做解決方案。

第三，如何上雲？

總結了兩點，第一，如何提升上雲的效率？第二，降低遷移風險，包括品質和成本。標準的三層的架構，包括接入、邏輯、存儲，存儲有數據存儲和文件存儲。公有雲和自研IDC之間專線打通，這樣就不存在IP無法訪問的問題。將雲原生的組件用好，能夠高效解決問題。有一些業務的改造成本比較高，先搬上雲，再跟著業務需求改造使用雲組件。

通過實踐與跟行業架構師交流，形成上雲五步曲，分為規劃設計、實施、驗證、維護五大階段。在資訊收集和評估這一塊我們會做大量的拆解工作，分析使用的服務、規模、框架、PAAS組件等，找出業務與雲不適配的地方，提出解決方案。風險分析，這裡有幾個方面：數據風險，架構風險，安全風險，特別是安全這一塊，對我們有很大挑戰。在騰訊IDC，是一個相對封閉的環境，只有自己的員工能夠登陸，但在雲上是相對開放的環境，通過VPC與安全組等策略進行隔離。方案設計，最重要的是資源、成本、規劃。

上雲計劃，將我們所有要做的事情羅列出來，根據輕重緩急、先後次序，制定一個整體的執行計劃。業務上雲碰到兩個主要問題，第一，業務本身對雲的適配，第二，雲對業務的兼容。舉個例子，遊戲上雲，遊戲的接入層多埠和多個客戶端通訊，CLB不支援多埠，也不支援連續埠段，這個就需要雲的改造適配。在業務層面，老的開發和運營框架，都不支援業務雲的體系，需要改造適配。

到實施階段，主要包括功能測試、性能測試、數據遷移和雲上部署等。雲CVM跟相同配置的物理機對比，性能損耗控制在5%之內，對成本沒有太大的提升，隨著硬體技術的發展，成本不會是大問題。數據遷移，數據上雲在上雲過程中是最重要的部分，數據沒有問題了，再將接入和邏輯進行上雲。

到驗證階段，逐漸將業務流量一點點導入到我們測試環境中，包括業務的驗證、效果評估。評估雲上雲下的品質，做問題的回歸和優化。

前面做完，就到真正上雲階段了。傳統的運維工作，上完雲之後，也是一個挑戰，當然也是一個很大的機會。原來的自動化、批量操作、自動擴縮容、彈性調度、系統監控等可以用雲原生的方案，例如用容器TKE的方案，就很好的解決了之前的痛點問題。

上雲各個環節的注意點。測試階段，會從功能、性能來進行對比，特別要對特殊的業務場景進行測試。基本上會做到，測一個上一個，當然越到後面上得越順，速度也會越來越快。方案階段，會對安全、容量、上雲的難度、數據的保障、數據的一致性、完整性做很多方案，同時也要做回滾方案。上雲最擔心的問題就是品質，這個決定了我們整個上雲是否成功。在服務和調度品質、用戶的訪問品質、服務可用率幾大方面進行評估，當然我們這裡也用到了前面分享智慧監控和告警系統，這一塊幫助我們做了很多事情，使異常能夠快速發現。

上雲一定是數據先行，有三大方案。第一，直接將IDC的數據dump下來，導到雲上的數據存儲組件里，增量數據繼續添加。第二，我們會將自研的存儲服務在雲上搭建起來，再將數據和服務遷到雲上，這種方式不好的是要自己維護與迭代，長期的成本很高。第三，比較推薦的方案，用公有雲的DTS工具，開發人員和運維人員都可以將它配置好，它可以實時同步數據導雲的存儲服務，數據可以高效、高品質地傳輸。

接入層和應用層上雲比數據層簡單很多，因為數據層會涉及到一致性和準確性校驗，而應用層和接入層只要將它測試通過就可以。使用騰訊的DNS服務GSLB將流量逐漸切到雲上。這個是灰度上雲的過程，最後都會在雲上。

再舉個例子，QQ是一個龐大的體系。騰訊公司已經有21年的歷程了，它是跟著騰訊一起成長起來的，也是我們第一款最大的產品。QQ的上雲挑戰非常大，現在QQ已經全部在雲上了。我們也用了很多雲原生的解決方案。QQ主要是三地部署，包括華北、華東和華南，還有海外是香港。按上面介紹的思路，將數據遷到雲上，再遷移接入層與邏輯層。在廣州雲和深圳自研之間有一個堡壘機進行數據傳輸，QQ和其他業務可以互聯互通。

前面反覆提的一個概念：雲原生，它是雲原生計算基金會CNCF發起的項目，2015年由Google牽頭成立，第一個畢業的項目叫Kubernetes，目前它是容器的事實標準。如何理解這個雲原生的概念呢？第一，它是在雲上生長的，不是一個產品，而是一套技術體系和一套方法論。包括Devops、持續集成（CI）、持續交付（CD）、微服務、雲基礎設施（laas）、容器（K8S）、12要素等幾大主題。結合雲原生的方法論我們給出了業務的最佳實踐，都融合到了我們自研上雲裡面。

TKE是騰訊雲容器服務的解決方案，它天生結合了騰訊雲的基礎架構，和底層網路做適配。TKE在業務管理、網路、路由、分批灰度升級，測試、預發布流程等都做了較大的優化。

CI/CD/CO是研發測試到運維、運營整個過程，藍盾，這個大家可以在雲上搜索一下相關的介紹。它是體系化的CI/CD/CO解決方案來提升研發運維效率。

總結，第一，擁抱雲原生，雲原生在近五年一定是個趨勢。第二，借上雲革新研發模式，全面Devops（CI/CD/CO）。第三，組件和工具的上雲，如何對業務和客戶更好的服務。工程師文化如何培養，如何將這種技術氛圍給調動起來。如何去用開源的東西，將自己的效率提升起來，這個過程是坎坷的，但成果也是斐然的。第四，開源生態、合作共享。第五，雲基礎設施經受海量業務的錘鍊也變得更加強大。

Q：您好，雲概念和數據中心比起來，優勢在哪裡？

A：從兩方面來看，第一，雲有很多組件來支援對數據的使用、例如校驗、備份、導入、導出等。第二，在數據保障方面，我認為它會比傳統數據中心更加強大，因為雲的基礎架構容災能力更強，並且雲技術是在演進的，未來會更強大。