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