这些基于自研或开源组件的数据迁移到公有云上对应的数据服务-平潭新闻网
点击关闭

工具开源-这些基于自研或开源组件的数据迁移到公有云上对应的数据服务-平潭新闻网

  • 时间:

南朝石刻遭拓印

第一階段是從2017年開始直播類業務的上雲。直播業務上雲模式是一整套直播業務從自研機房搬遷到公有雲機房,在騰訊雲上提供服務,完成國內和海外幾十個節點的建設,服務於自研的直播業務和外部客戶。上雲時打通了內部的運營管理系統和監控系統,同時支持跨雲的管理。

第二、三種模式可以統稱為開源組件到公有雲。我們內部有一些業務,在開源組件之上做二次開發,譬如基於單機Redis實現自研分佈式Redis集群。這些基於自研或開源組件的數據遷移到公有雲上對應的數據服務,可通過DTS遷移工具來實現。

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

在上雲過程中,也必然會遭遇到一些比較大的挑戰,比如數據的遷移。在私有雲到公有雲的數據搬遷模式中,我們有四種模式給業務選擇。

第二階段是方案規劃和設計。要做好詳細的遷移方案,風險預案,回滾預案,混合雲預案,多雲預案等,譬如上雲過程中數據遷移有問題,出現丟數據,我該如何解決等等。

為什麼要上雲?2018年以前,騰訊的業務線是類似煙囪一樣的模式,每個業務事業群從邏輯層、數據層到後端的容器或虛機層,都是獨立一套技術框架和技術體系。每個事業群之間的框架多數是不通用的,一個騰訊的員工從IEG轉崗到微信事業群,發現他的開發框架可能都要重新熟悉。一個新人來到騰訊之後,面臨那麼多的服務框架,也不知道如何選擇合適的框架着手。

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

服務邏輯上,很多個業務直接使用雲PaaS服務,如長消息、加群邏輯等用了雲Redis存儲服務。更多的服務遷移到TKE之上。

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

根據騰訊自研業務上雲,團隊所積累的經驗之上,我們抽象出完整的上雲方案,也十分符合很多企業上雲的實際情況,方案分五個階段。

通過同步中心的方式完成大規模數據的混合雲同步。當要增加一個成都雲區域,我們只需在當地好一套同步服務,增加路由服務規則,同步服務就會自動把數據同步到成都的雲機房。

第一是測試,包括公有雲上的網絡、存儲、虛擬機、核心服務,以及單機性能、服務吞吐性能、存儲讀寫性能、業務模塊性能等等都經過測試。通過測試之後,我們和雲團隊一起優化了服務性能,對業務也相應做了改造適配。

第一個是很多工程師不斷抱怨為什麼騰訊內部有這麼多名詞,不同的工具、不同的框架、不同的平台、不同的數據庫和不同的存儲等等。

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

比如說我在深圳的自研有一台主兩台備,那麼我再把備3、備4放到廣州雲,數據同時同步到私有雲的兩個備和公有雲的兩個備機模式。所有的主備數據完全同步完成之後,我們再把公有雲的備變成主,自研雲的主變成備,就相當於是做了切換。

K8S平台上,我們用了騰訊的TKE引擎,這是一個跟K8S完全兼容的引擎。我幾天前跟一個業界公司聊,他們在騰訊雲、阿里雲上買了K8S服務,自己內部也部署了K8S集群。他們的容器可以隨時、同時交付到騰訊雲、阿里雲和他們本身的K8S集群,而不用做任何改動。通過容器交付,業務可以不用考慮環境依賴等問題,交付變得更敏捷和輕鬆。

業務上雲的三個階段騰訊自研業務上雲也並不是一蹴而就的,而是有三個階段。

內部的CI/CD,我們有很多的優秀工具,讓業務自行去選擇使用,開發團隊喜歡什麼樣的工具,從鏡像倉庫、到CI、CD、CO都能保持業務自己的習慣。

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

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

第三階段,是在騰訊「930」變革之前, 2018年6月我們就已經開始擁抱公有雲,啟動自研的整個業務從私有雲遷到公有雲,這是把整個業務連根拔起搬遷到雲上。

從測試、方案、遷移、混合到監控,這是我們上雲團隊所實施的上雲遷移整體流程。

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

首先是私有組件數據遷移到公有雲的模式。騰訊內部有很多自研的數據庫,像QQ的Grocery KV存儲使用的是內部私有協議,雲上沒有對應服務。業務需要將數據從私有組件遷移到Redis。

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

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

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

第三是客戶價值,可以給行業輸出非常多的公有雲的經驗。

這是藍盾支持雲上DevOps的範例,能夠實現計劃、需求管理、設計、研發、構建、測試、部署、搭建、監控到運營等一整套工具閉環。

上雲有哪些流程,如何規避風險?

還有更複雜的是數據同步中心。這種是適合業務量非常大,有全國多地分佈的業務。服務模塊寫數據的時候,統一寫到各地的接入代理,代理統一寫一地,譬如深圳自研的寫服務。

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

為了實現這一點,我們做了一些改造,在每個區域的公有雲和私有雲機房之間拉了專線,實現了公有雲私有網絡到私有雲機房的互通,保證業務能夠來回遷移及訪問內部服務能力。

第一階段:規劃。規劃中要對業務系統化的梳理,包括業務評估、容量評估、業務架構、組織體系。組織體系是指上雲后組織架構和職能的變化,包括運維職責的變化:例如不再有中間件的運維人員,研發流程的變化;研發、測試和生產環境如何在混合雲甚至多雲中共存;資源預核算的變化;以前是購買機架和服務器,現在是先充值再按量計費;故障處理流程的變化等。技術體系的組織都要準備跟着公有雲轉變。

那麼,上雲的價值是什麼?第一是業務價值,業務的研發效率更高,從0到1開發一個新產品短短一周就能完成,微服務框架、數據庫、容器資源、持續集成、持續交付、統一配置中心等等,雲上都有現成的服務,研發團隊不需要到處拼裝各種組件和工具,可以更專註業務研發。

傳統行業轉型的過程中,騰訊向來扮演的是數字化助手的角色,騰訊雲作為幫助企業數字化轉型的入口,也已經成為騰訊的「獨角獸」業務。

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

第三,內部的優秀工具上雲,給雲提供更好的服務。

最後是業務監控。上了雲之後使用立體化的監控體系,度量服務調用質量、用戶訪問質量和服務可用率等,譬如跟蹤用戶在私有雲和公有雲的訪問延遲有沒有變差,不能變壞,運營質量有沒有跟原來保持一致,甚至變得更好。

第一,徹底擁抱雲原生,用雲來滿足業務快速迭代,資源彈性伸縮的需求。

騰訊的業務量非常龐大,社交業務包括QQ和空間的體量有近二十萬台服務器,分佈在全國三地。要把如此龐大體積的業務搬到雲上,可以稱之為「把大象搬到雲端」。

第二個階段是沙箱雲,這個階段是在騰訊雲上建立一個邏輯隔離的私有網絡空間,利用騰訊雲的IaaS服務,使用雲的虛擬機、雲的網絡、雲的機房來支撐自研業務的服務。不過這類模式只屬於基礎平台上雲,並不是整體業務體系完整上雲。

兩大開放戰略并行基於以上問題,為了技術體系革新,930調整后,騰訊內部做了大變革,包括成立新的雲事業群,公司內部成立「技術委員會」,啟動「開源協同」和「自研業務上雲」的兩大戰略方向。

還有包括管理體系、安全、審計、服務監控、日誌、告警等功能特性,我們增加和優化了近百個特性,滿足TKE與海量業務結合。

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

還有一種是主備備的模式,即在深圳自研有數據庫服務器的主和備,在雲機房新部署幾台備機。通過主備同步的方式,把所有數據都同步到雲機房。然後將雲機房的某台備機切換成主機,將自研的主機降級為備機。這樣就切換為雲機房主備,自研機房備的模式。

如何把QQ的所有用戶搬上雲?

1、騰訊自研業務如何從私有雲的模式搬遷到公有雲;2、如何把這些大體量的業務搬到雲端;3、如何擁抱雲原生。

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

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

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

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

第二是工程師價值,工程師可以使用到整個業界最標準化的服務,基於公有雲的研發模式,能夠離開封閉的開發環境和組件,同時工程師還可以輸出非常優秀的組件到雲上成為服務,這也是大多數工程師的夢想。

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

第四,整個開發團隊心態更加開放、更加開源,主動與開源社區協同,貢獻更多的功能特性。

用戶就近讀,比如華北的用戶,就讀華北雲的這個數據存儲集群,華南就讀華南的數據存儲存儲。

第五,公有雲經受了QQ海量流量的錘鍊,我們在上雲過程中,經歷很多的經驗教訓,邊上雲邊解決問題,邊上雲邊優化,將整個公有雲的基礎設施和服務錘鍊成更加成熟。

目前在雲上的交付,業務每周都有幾百次的交付是通過容器來完成的,從以前的包交付變成容器交付。

上雲前後,上雲團隊對業務質量非常關注,不斷對比二個雲之間的可用率、客戶訪問質量、服務間調用延遲等質量數據。上雲前後, 經過各個架構層的優化,業務質量數據最終保持私有雲和公有雲一致,保證了用戶訪問體驗。

截至2019年初,騰訊正式發佈的對外開源項目將近70個,諸如騰訊雲T stack、藍鯨智雲BlueKing CMDB、微信開源系列和TARS等,都是騰訊開源的典型案例。

第三是業務遷移,遷移包括接入層、邏輯層、數據層及文件存儲等的遷移。

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

第二,全面擁抱DevOps,研發效率更高效。

第三階段是驗證。這個是非常核心的階段,上雲前,要有預測試、預驗證的過程。可以把一些核心模塊,譬如高併發,或延遲非常敏感的模塊,在雲上做好充分的壓測,並跟雲服務團隊一起優化解決各種問題。

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

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

在微服務這塊,像SF2、SPP、TAF等,我們內部不同業務已經使用了很多微服務框架,並計劃在公司內迭代升級更優秀的微服務框架。

根據用戶分佈情況,QQ上雲時,在華東、華南、華北三地,在騰訊雲建設的雲機房上,我們創建了業務的公有雲網絡,然後把QQ業務從各地的自研機房往雲上遷移。

於是,我們總結了八類的TKE業務應用適配,從業務管理、網絡、路由與服務發現、分批發佈、權限控制、鏡像倉庫、網絡存儲到遠程日誌。

其次是「自研業務上雲」。基於公有雲的研發模式,使用雲上豐富的組件、豐富的服務,把內部的一些優秀的工具和組件上雲,對外開放,在雲上做服務。在客戶的激勵驅動下,不斷迭代成為行業內的領先水平。

第二是業務上雲方案,包括安全方案、容量評估、服務遷移方案和數據遷移方案等。

根據業務體量不同,業務採用三種方式上雲,有改造後上雲,有邊改造邊上雲,有先上雲再改造。業務可以根據自己的人力資源和上雲計劃,選擇對應的上雲方式。

然而伴隨着雲業務的增長,騰訊內部業務如何上雲,對於外界來說一直是個秘密。近日,騰訊自研上雲項目負責人周小軍首次披露,騰訊如何把內部海量的自研業務搬上雲端的故事。以下是他的分享內容:

寫服務的轉發存儲會將新增記錄同時寫到各地自研、各地的雲機房,實現最終數據一致性。

一些內存存儲服務,譬如資料、關係鏈等數據存儲層做了鏈接數、數據副本擴展、混合雲單元分佈等架構層級的優化改造。

上雲不僅是為了上雲,我們更多要擁抱業界開源生態。要用雲上優秀成熟的產品和服務。在開發方法、業務交付、雲原生服務等方面,業務上雲前後已經是部分甚至全部擁抱雲原生的體系。我們已經把TAPD研發管理工具、工蜂代碼倉庫,還有藍盾、橘子CI、QCI、coding等集成為工具鏈,在雲上打造了一個持續集成、持續部署的DevOps流水線閉環。

首先,開源協同就是在騰訊內部,所有的開發團隊代碼都是開放的,騰訊內部有統一代碼庫,所有的團隊及個人的代碼都要在上面公開提交、公開發佈。團隊與團隊協作更好,隨時可以去創建個分支,或者提交更豐富的特性功能,形成公司內的開源代碼文化,創建更好的工程師氛圍。

第四階段是業務遷移。遷移就更複雜了,包括服務和數據怎麼遷、怎麼做好備份,遷移過程中對業務有沒有影響,我們用雲的通用遷移工具,還是我們自己開發的遷移工具。上雲過程中,做好對灰度模塊的觀察,通過客戶端服務質量,服務間調用延遲,全網撥測等監控指標觀察業有沒有問題。

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

甚至在騰訊的內部論壇上,經常有很多新人發帖問,我該選什麼樣的工具,我該選什麼樣的框架,這種情況就導致三種困惑。

在上雲過程中,QQ研發自身也對業務進行了優化,積極擁抱變化,做了很多處服務的改造,以能夠適應新一代的基礎設施。

前面講了業務上雲的思路和方法,QQ上雲是走了這樣一個經歷。上圖就是一張全國地圖,QQ業務有三大區域的數據中心,有華北自研,2015年這裏曾發生了一個很大的爆炸事件,當時我們還把天津的用戶調回了華南和華東區域。上海有華東自研機房,深圳有華南自研機房,在香港還有一些海外的出口。三大區域各有三成多的QQ在線用戶。

大家好,我今天分享的核心內容有三個:

所以,從騰訊自研業務上雲,再到一些合作夥伴的案例,對於上雲的的趨勢,我們總結了五點經驗:

第二個是很多部門都開發和使用自己的一套東西,跟其他部門缺乏分享和協作。

今日关键词:吴卓林新造型