但馬同星不這么認為，他覺得一定要做“難而正確的事情”。馬同星下面講述的這個“上云”故事，希望能給大家一些啟發(fā)：
“如果我們不做，三年后就會差的很遠”
事實上，在上云前的兩三年我們就在討論重構(gòu)這個事兒了。
大概2018年下半年，我們開始做服務(wù)發(fā)現(xiàn)、流量治理的一些預(yù)研，調(diào)研社區(qū)的各種方案并因此關(guān)注到Istio。到19年初，也就是春節(jié)前2月份的時候，我們開始做技術(shù)驗證。當(dāng)時剛發(fā)布的Istio 1.1，是它的第一個Enterprise Ready版本，業(yè)界還鮮有大規(guī)模應(yīng)用，騰訊內(nèi)部也還沒有這樣的服務(wù)。
我們團隊一起看一些技術(shù)資料，就開始研究這個。一開始我以為，微服務(wù)架構(gòu)和服務(wù)網(wǎng)格的治理，是“新瓶裝舊酒”——我以為進程多、把每個功能變小就是微服務(wù)，后來發(fā)現(xiàn)真不是，它這里說的微服務(wù)治理是指系統(tǒng)調(diào)度治理的能力細致入微。
如何理解這個治理能力呢？我舉個例子，你有100個服務(wù)在做不同的事，這時A服務(wù)要訪問其中的30個，B服務(wù)又訪問其他的20個，C服務(wù)訪問其他的15個，這15個里面的某個又要訪問A服務(wù)…你把它想象成100個人的合作就知道——交互是星羅棋布的，牽一發(fā)動全身。
而真正的微服務(wù)治理能力，不管你的服務(wù)劃分多細、結(jié)構(gòu)多復(fù)雜，這些服務(wù)調(diào)度、容災(zāi)容錯擴縮的細節(jié)都不需要額外關(guān)注了。它的治理難度不會隨著你的系統(tǒng)變龐大而變復(fù)雜，不需要付出顯著的額外成本。
總之，它是把服務(wù)和治理能力重構(gòu)、下沉到基礎(chǔ)設(shè)施層、避免侵入業(yè)務(wù)架構(gòu)去做流量治理和調(diào)度的方案。在我看來這個設(shè)計思路的先進性超過以往傳統(tǒng)分布式架構(gòu)非常多。
這個開源方案所代表的微服務(wù)治理架構(gòu)，就是我說的要做的“正確的事情”。
我們初期主要目標其實并不是為了省成本，大家上云一開始就是奔著提高流量治理能力的目標去的。
我們從大的技術(shù)趨勢和機會一點點推演，當(dāng)時想要實現(xiàn)某些業(yè)務(wù)模塊的自動服務(wù)發(fā)現(xiàn)，其實也有其他低成本的方式可以做，但如果對照這個服務(wù)網(wǎng)格乃至云原生整個社區(qū)的技術(shù)架構(gòu)能力，那就差很遠了。
比如，大扇出系統(tǒng)出一個故障，以前你得通過分析日志來看哪個環(huán)節(jié)出了問題，但對于云原生來講，整個調(diào)用鏈路非常清楚，自動生成調(diào)用鏈路拓撲給你，很快就能看到出問題的根源節(jié)點，對整個研運效能都是質(zhì)的提升。
我個人覺得這一定是大的方向，甚至是對云業(yè)務(wù)利潤率的提升是很重要的。這些能力都是行業(yè)大的機會和趨勢，如果我們不做，現(xiàn)在也可以運營的很好，但三年以后，你可能就差很遠。
“對技術(shù)的掌控和認知，是消除恐懼和擔(dān)憂的有力武器”
在啟動這件事情的時候，團隊里不少同事是猶豫的。
我們工作室的負責(zé)人非常重視并不遺余力的投入技術(shù)創(chuàng)新，工作室專門設(shè)有公共技術(shù)團隊負責(zé)技術(shù)預(yù)研類的工作，同時還有各個業(yè)務(wù)項目組內(nèi)的技術(shù)團隊，如果要去做這樣一個大的架構(gòu)調(diào)整，除了老板的支持還需要所有核心骨干發(fā)自內(nèi)心愿意去做這件事情，才能走得下去。在項目組的同學(xué)，他會更多地去考慮項目迭代以及對版本穩(wěn)定性的要求，會下意識焦慮：一下子切到我經(jīng)驗之外的一個技術(shù)方案，會不會出很多問題，在原有架構(gòu)下小步快跑是不是也挺好？
當(dāng)時其實花了很多時間和各個項目組的技術(shù)骨干們談心：為什么要基于開源來做，做這個對團隊和個人的發(fā)展有什么好處，技術(shù)架構(gòu)調(diào)整的風(fēng)險和挑戰(zhàn)如何由組織而不是個人承受。
有一些同事是很熱衷技術(shù)的，給的響應(yīng)比較積極。另一些傾向于保障業(yè)務(wù)優(yōu)先的同事還是會猶豫，我就接著提議說，我們用小體量項目先來試點，就這樣把團隊的信心初步聚攏了起來。
第二件事就是統(tǒng)一團隊的目標。當(dāng)時我們團隊做了很多輪分享和研究，甚至翻譯了一本K8S的書，最終統(tǒng)一了目標：基于開源的一整套開源的技術(shù)棧來重構(gòu)，包括從最底層的協(xié)議，到開源遠程過程調(diào)用系統(tǒng)GRPC，到服務(wù)網(wǎng)格以及K8S的服務(wù)編排。原因也十分簡單：這套東西已經(jīng)逐漸成為了行業(yè)的事實標準，不去跟上它，我們就會慢慢落伍，想自己搞一套打過人家已然是不可能的了。
大概到2019年6月份，試點項目驗證的結(jié)果評估出來了：方案可行。這個時候團隊的氣氛與最開始時已經(jīng)完全不一樣了，變得信心滿滿了，因為我們已經(jīng)把這個技術(shù)吃透了。對技術(shù)的掌控和認知，是消除恐懼和擔(dān)憂的最有力的一個武器。等到了后面大規(guī)模上云重構(gòu)的時候，大家已經(jīng)駕輕就熟了。
五十萬人游樂場的“乾坤大挪移”
技術(shù)驗證這是第一個節(jié)點，到了第二個節(jié)點，我們要做的就是把業(yè)務(wù)平滑地過渡到云原生環(huán)境。
但這個上云不是說把我們的服務(wù)搬到自研云就叫上云，假設(shè)我們只是把IDC的生產(chǎn)環(huán)境搬到騰訊云的自研云里面，卻還是用原來的架構(gòu)，在我看來它的意義就大打折扣了。
公司大力推動自研上云營造了一個非常好的技術(shù)變革的氛圍，而且到了2019年6月左右，TKE團隊也開始做mesh了，還跟我們專門成立了聯(lián)合的保障團隊。在這個基礎(chǔ)上，我們開始把原有的業(yè)務(wù)逐個地重構(gòu)，放到云原生的環(huán)境里面去。
重構(gòu)的技術(shù)難度沒那么高，但服務(wù)平滑遷移是個問題。我們當(dāng)時一部分業(yè)務(wù)在云原生架構(gòu)上，另一部分則在云下。在這種異構(gòu)架構(gòu)下，要保證遷移過程平滑、用戶無感知，對于業(yè)務(wù)來說是一件很有挑戰(zhàn)的事。
因為游戲和普通互聯(lián)網(wǎng)服務(wù)不一樣，比方說你買個東西，失敗了大不了重試一次，但游戲是實時交互的，掉線再回來游戲過程已經(jīng)到新的局面了，其它玩家不會陪你重來錯失的游戲過程。這就好比說，你要把幾十萬人從一個游樂場乾坤大挪移到另一個地方，還不能讓他們有感知一樣。
其實在上云過程中，業(yè)務(wù)端也是有疑惑聲音的。2021年春節(jié)的時候，我們與手機QQ合作了一個運營活動，當(dāng)時瞬間涌進來大量的用戶，于是出現(xiàn)了過載，也就是大量用戶排隊的情況。
當(dāng)時運營的同學(xué)沒有把這個活動提前告知研發(fā)團隊，我們那時有一部分業(yè)務(wù)還在云下，還沒有動態(tài)彈性計算的能力，所以出了這個故障。后面我們跟運營同學(xué)一起來總結(jié)這個事情的原因，他們不太理解，說我們的系統(tǒng)不是能支持一兩百萬在線嗎，怎么來了五十萬人就不行了呢？
我當(dāng)時就給他們舉例子解釋說：某辦公樓能支持五千人辦公，但每天早上電梯排隊非常長，咱們的情況和這個同理。一個是容量，一個是登入并發(fā)負載，容量可以很大，但不代表咱們短時間的處理能力很強。目前這部分業(yè)務(wù)沒有動態(tài)彈性計算的能力，所以會這樣。我們現(xiàn)在正在做一個大的技術(shù)重構(gòu)叫云原生重構(gòu)，它最核心的能力之一就是解決這個問題：如果只有一個人走，這個電梯就會變得很小，節(jié)省資源；如果突然來了五萬人，它會自動變得很寬，讓那五萬個人很快地過去。
講了這個運營同學(xué)們就明白了，在后續(xù)的協(xié)作就方便了很多。所以這個事之后我總結(jié)說，技術(shù)管理者要去給到團隊三個信心：
第一，有充分的基礎(chǔ)驗證，證明方向靠譜；
第二，重大重構(gòu)必然充滿技術(shù)風(fēng)險，既然選擇去做，對團隊要有兜底承諾，做為技術(shù)管理者就要首先承擔(dān)風(fēng)險責(zé)任。出了問題不盲目責(zé)怪團隊，因為啥也不干風(fēng)險最低；
第三，以非技術(shù)人士能夠理解的方式，把技術(shù)的影響力擴大至協(xié)作上下游的其他團隊，獲取他人的信任與支持，來推進技術(shù)建設(shè)。
記得2020年11月17日上午11時我們第一次跨集群網(wǎng)格全量在線升級，升級后部分跨集群的路由信息丟失，導(dǎo)致一個重要游戲功能的大量失敗。研發(fā)同學(xué)全力投入故障業(yè)務(wù)恢復(fù)，項目組的策劃、運營同學(xué)出公告、用戶補償方案，聯(lián)系客服安撫玩家。大家都在無條件支持，沒有人抱怨。研發(fā)同學(xué)恢復(fù)服務(wù)并完成玩家數(shù)據(jù)補償后，與TKE團隊一起徹查了問題根源。終于下午17：44，后臺同學(xué)在項目組大群周知服務(wù)已經(jīng)恢復(fù)并已經(jīng)重新上架客戶端功能入口，不但沒有任何責(zé)怪和質(zhì)疑。我們GM反而關(guān)心大家，“好多后臺同學(xué)忙著處理問題，到現(xiàn)在午飯都還沒吃上，辛苦了?！?nbsp; 工作室對技術(shù)創(chuàng)新的期望、寬容和耐心是大前提，穩(wěn)健運營的項目是重構(gòu)演進得以落地的場景，更難能可貴的是不同專業(yè)背景歡樂的小伙伴們的通力協(xié)作支持，這些都是歡樂云原生重構(gòu)能順利落地的重要保障。
早在2020年的6月，歡樂所有的游戲?qū)址?wù)就已經(jīng)全部部署到了云原生環(huán)境下，復(fù)雜且強狀態(tài)實時交互的游戲?qū)址?wù)也首次具備了彈性計算能力。據(jù)我們了解，這應(yīng)該是在游戲領(lǐng)域里第一家做到這個水平的團隊。
更高的目標：從峰值60% 到全時70%
事實上，我們這三個階段，包括技術(shù)驗證，包括去做核心服務(wù)的遷移，再到最后做存量服務(wù)的遷移，我們都有一個大的原則：不趕時間，不拼核時數(shù)，只看一個東西：云原生的彈性計算能力是否有充分發(fā)揮，這個評判標準是忙時至少能到60%的負載。
其實任何一個游戲產(chǎn)品都有生命周期，在云下的時候，大家都是猛堆機器，去完成高峰期的承載，但過了高峰期，那些機器的實際利用率是非常低的。我們做過測算，許多項目在沒有彈性計算的架構(gòu)下，高峰期有效負載只有30%不到，低峰期負載率更低。
如果你的業(yè)務(wù)上了云，利用率和在云下是一樣的，我覺得是一個非常差的成績。我們不能把上云當(dāng)作公司下派的被動任務(wù)一樣完成，只完成基礎(chǔ)的上云量指標是遠遠不夠的。
所以我們強調(diào)，不要去拼上云的速度和核的數(shù)量，而是拼上云的質(zhì)量，我們一定要按照云原生的能力重構(gòu)業(yè)務(wù)系統(tǒng)，上去了它就有真正的彈性計算，服務(wù)調(diào)度、流量治理這樣能力。
等老業(yè)務(wù)也完成重構(gòu)上云、異構(gòu)系統(tǒng)裁撤掉后，我相信整體的資源利用率會再上一個大臺階。我的期望是未來能做到全時70%+，不僅僅高峰期70%利用率，而是低峰期也能做到70%，消峰填谷，把空閑計算資源用于離線計算業(yè)務(wù)，這是一個長期的目標。
如果真正做到的話，我們用到的核時數(shù)可能會降到現(xiàn)在的1/3甚至更低，當(dāng)然，這不是一個容易的事情。
有個事我也特別感動：去年夏天我們項目組組織了一次去江西武功山的團建，花了幾個小時徒步爬上去，最后人真的是站在那個云上面，云就在腳下五六十米、一百米的地方，大家非常激動，開始拍照片發(fā)朋友圈。
“我們這才是真‘上云’的團隊?！痹S多人發(fā)朋友圈這么寫，這個時候我知道，我們這件“正確的事情”是真的做對了。
人們常說，船大難掉頭，以騰訊公司龐大的體量，自研上云的困難不言而喻。但是，正如上面所講述的故事，在騰訊公司有許許多多像馬同星一樣的人，靠著自己的技術(shù)經(jīng)驗和想法勇敢嘗試，最終完成了一個個不可能完成的任務(wù)，使得騰訊內(nèi)部諸多的老項目在云端煥發(fā)青春。
IT人大部分時間從事著瑣碎的業(yè)務(wù)工作，能趕上這樣一個轉(zhuǎn)型云原生的浩大工程，既是挑戰(zhàn)也是機會。當(dāng)他們通過不斷學(xué)習(xí)和嘗試，通力合作克服各種困難，最終完成上云的那一刻，相信每一個參與者的個人能力都會得到巨大的提升。
這就是騰訊的技術(shù)人，這就是騰訊的精神，希望騰訊云能夠在這樣一群可愛的技術(shù)人的支持之下，越走越遠，越飛越高。
