給飛奔中的騰訊更換引擎 媒體揭秘騰訊上云背后故事
明敏 魚羊 發自 凹非寺
量子位 | 公眾號 QbitAI原標題《站在風暴中心：如何給飛奔中的騰訊更換引擎》
2016年的一次改變，轉動了科技大廠向前奔馳的方向盤。
其時，一種興起于谷歌、名為“Kubernetes”的集群管理技術開始在全球范圍內“野蠻生長”——
這種被簡稱為K8S的技術，此后幾乎被外界視作云原生技術的代名詞。
身處國內的技術弄潮兒們，自然也嗅到了這股技術熱浪的氣息。一個新的容器項目就此在騰訊云內部悄然啟動。
只是，打從事情一開始，爭執和分歧其實已經在技術團隊內部爆發……
項目主力于廣游，便身處風暴眼中。
作為國內最早接觸到K8S的一批人，于廣游和他的同事們很快敏銳地察覺到：這種新的云計算調度系統，一定是個“大事情”，代表著未來技術發展的方向。
但就是這么個“大事情”，攤子剛剛鋪開，“往何處去”就成了大問題。
底層復雜的技術應該被包裝成一個簡化的服務，把K8S幾十個復雜的API都“藏”起來，做成一個只暴露一個接口的、封裝好的“黑盒子”，還是有別的選擇，成為團隊技術人員的爭議點。
出于對K8S更深入的理解，于廣游這樣的“技術原教旨派”認為，“K8S不應該是一種面向終端用戶的產品啊。這個產品的更多是企業平臺用戶。與其把精力花在對K8S概念的包裝上，還不如做好開放、完整的K8S生態。”
盡管這樣的觀點在今天看來具有前瞻性，但在當時，要打破多年以來團隊已然驗證過的成熟“經驗”，去走一條看上去更復雜的路線，多少讓人感覺有些風險不可控。
怎么辦？
現在看來有些幸運的是，盡管團隊中有不少更為資深的技術人員，但在K8S這股剛吹入國內的新風面前，大家都算是從零開始，對新觀點的接受度也更高。
在于廣游等人的堅持和反復游說之下，越來越多人意識到，面對K8S這樣火花越燃越旺的技術，做正確的事或許比穩妥更重要。
這個新容器項目的發展思路，也逐漸明確下來：
一個完全開放原生K8S API的騰訊云“引擎”。
而這，后來也成為了更大規模技術變革的契機。
路線最終按照于廣游的設想推進，但正確與否，在當時恐怕并沒有人能100%確定。甚至連驗證本身進行得都沒有那么順利。
轉機在2018年出現。
2018年9月30日，騰訊進行成立后第三次重大組織架構調整。也就是在這次內部變革之中，“自研上云”成為了騰訊技術發展的一大方向。
所謂自研上云，就是把騰訊內部各自跑在不同數據中心的業務全部搬到騰訊云上。
包括于廣游團隊所提供的騰訊版K8S在內，騰訊云打造一系列云上開發環境和功能組件，開始成為所有騰訊工程師能夠共同使用的“武器”。
對于開發者們而言，這也就意味著，無需再重復造輪子，開發流程也從手工時代進入到自動化時代：不需要自己去部署物理機、虛擬機，擴縮容也不需要再折騰機器的事，全部變成面向API的自動化工作。
對于騰訊云團隊而言，這樣的變化用一個詞來形容，就是“很爽”。
但上云這件事，觸動的顯然不僅僅只有騰訊云。
具體業務開發者，事情或許就沒有那么“爽”了。
光子歡樂游戲工作室技術總監馬同星的團隊，就在上云之初倍感壓力。
彼時，歡樂游戲工作室內部打算對原有架構進行重構，以實現服務的彈性化和可拓展。
恰逢服務網格istio 1.1版本發布，兩套技術方案就這樣擺到了這個團隊面前：
其一，是在原有架構的基礎之上去增加功能，來實現自動化的流量治理和服務發現。
其二，就是完全切換到云原生方案上，對原有架構進行云原生改造。
一開始，對于徹底重構團隊里不少同學憂心忡忡。原因很簡單，對于開發人員來說，項目運營多年，原有的架構是經過檢驗成熟穩定的，開發者對其掌握的程度也比較高。
而云原生，并不是簡簡單單把舊的本地部署遷移到云端即可，相反，這個方案意味著一切都要遵循云上的技術標準從頭來過。
其中的業務風險，不言自明。
這樣的技術疑慮，也非止一例。
同樣的情況，也令騰訊課堂研發中心負責人王昂和他的同事們心頭一緊。
王昂的團隊脫胎于QQ，而QQ本身上線十多年、月活超過8億，早已具備成熟穩定的技術架構。
因此在2019年，面對騰訊課堂新的業務需求時，是否自研上云就成為了技術團隊需要艱難抉擇的問題。
從實用主義的角度來說，QQ那套老的技術棧依然能用，而且足夠穩定，能保證新業務順利推進。
相反，走自研上云的路線，不僅意味著開發人員需要學習新的技術棧、初期工作量大大提升，各種云上組件也尚未經過充分的驗證，很有可能給業務質量帶來未知的影響。
只是在這樣的“不爽”之中，這些團隊最終仍然選擇了攀登那條看上去更為艱難的路線。
原因也非常相似：
誠然，在高速狂奔的騰訊內部，去做更換技術引擎這樣的事，組織上必然要承擔風險和挑戰。但是長遠而言，無論是對技術人員個人的發展，還是對于團隊業務的突破，都有非常大的價值。
王昂坦言：
“作為開發者，如果只把眼光聚焦在內部自研的組件上，不僅有重復造輪子的問題，而且會越來越跟行業領先技術拉開差距。上云與否，短期來看或許沒有區別，但長期則會帶來研發效率的巨大差距。”
不過，與小說里那些英雄主義的橋段不同，克服抵觸的心境下定決心，還只是翻過了困境的序章。
上云的過程，正如開發人員們起初所預料的那般，遠不能一帆風順……
如果說最初決定上云，是基于對行業技術趨勢的洞察。
那么，在經歷過種種困境后仍不放棄，則因為是上云帶來的切實好處，已經開始在日常運營中顯現。
歡樂游戲雖從2019年開始云原生重構和平滑遷移，到2020年底仍有不少老舊模塊跑在云下。2021年春節前夕，歡樂游戲工作室與手機QQ聯動做了一個活動，在春節零點時刻向用戶推送游戲的tips。
隨著大量用戶瞬間涌入游戲，讓活動團隊始料不及的事情發生了——
用戶排隊。
出現這樣的故障，運營、非研發團隊的同事其實很不理解。
“不是說系統能支持100、200萬人數在線嗎？怎么涌入50萬就不行了？”
馬同星用一個直白的例子作了解釋。
比如騰訊的辦公樓能夠支持5000人辦公，但是每天早晨電梯口還是會排很長的隊。為什么會這樣呢？
因為5000人指的是容量，但電梯能運載多少人上樓指的是登入并發負載。
容量很大，并不能代表短時間內處理能力可以很強。
回到業務本身來看。
假設某個業務每秒的部署能力是處理5萬請求，結果1秒鐘涌來了50001個用戶。
這意味著，1秒之后還有一個請求沒處理，可是到了下一秒又來了50001個用戶……以此類推，用戶的請求就會積累。
這種積累可能會導致有幾十萬用戶在排隊，最終結果就是大量用戶的請求都會超時或者被系統丟棄。
因為等排到他的時候可能已經過去了5秒、10秒，這在專業上被稱為過載。
而出現這一問題更加深層的原因，是當時還有部分業務沒有上云，沒有動態彈性計算的能力。
要知道，用戶從登錄到進入游戲這個流程，只要有一個卡點不能動態伸縮，就會導致排隊。
怎么解決這一問題？
云原生重構，是馬同星向運營團隊給出的答案。
“我和運營的小伙伴說，我們現在正在做一個大的技術重構。”
“它的核心能力之一就是，如果一條路上只有1個人走，它能夠讓路變得很窄、節省資源；如果突然來了5萬人，它又可以把路變得很寬，讓這些人快速通過。”
在淺顯通俗的解釋下，運營團隊也很快理解了馬同星他們在做的事情，并切實感受到了云原生能為實際業務帶來哪些好處。
這個過程中，內部團隊之間的信任也悄然建立。
后續，當版本中有部分業務需要技術團隊來做重構時，運營團隊能夠給予更多的理解，同時也很開心業務能夠上云。
而這樣的故事還只是上云過程中的一隅。
透過它也顯示出了上云時面臨的許多棘手問題。
比如涉及到的業務往往是大體量、高營收的，無法不管業務死活去“一刀切”做遷移。
再比如需要運營、策劃團隊也要懂研發團隊在做什么事，建立團隊之間的技術信任。
簡而言之，無論是馬同星還是王昂團隊的經歷，都說明了同一件事：上云不是一蹴而就。
回顧騰訊上云幾年來的經歷，大致可以歸結出3方面經驗。
第一、研發團隊通過試點項目做技術驗證，建立團隊信心；
第二、將不同業務逐步遷移上云，云上云下兩步走，保證在出現故障時能夠回滾；
第三、騰訊云團隊與業務團隊之間耐心磨合。
首先來看技術團隊如何建立信心。
比如馬同星所在的歡樂游戲團隊。
在最初決定遷移上云時，他們就開始自己去搭設服務網格做技術驗證，成功之后再把技術慢慢鋪開。
為此，馬同星團隊用一個用戶體量較小的業務作為“試驗田”。
驗證期間，技術團隊一邊趟平了大大小小的坑，另一方面還加深了對云原生的認識和掌控，最初對上云的恐懼和顧慮也隨之消散不少。
其次，如何平滑上云是重中之重。
馬同星表示，我們期望的上云并不只是把業務直接搬到自研云里，而是從架構層面的改變。
他們采用的遷移策略是先從相對不重要的服務入手，等出現的故障逐漸減少時，再遷移核心服務。
同時，為了保證“用戶無感知”，在新業務上云后，相應的云下環境不會立刻裁撤，流量保留了自動切回的能力，由此平穩度過了波動期。
最后，團隊之間磨合也十分重要。
除了如上歡樂游戲研發團隊和運營團隊之間信任建立的故事。
在騰訊課堂這邊，王昂也提到上云過程中一直和容器化、運維等團隊在密切溝通。
這主要是因為云技術方案更為領先，技術棧還沒有十分穩定，所以不可避免需要更為耐心的磨合。
“基本上云的組件，我們提了三四百個issue和反饋。”
這樣大量的反饋溝通，是王昂此前從未經歷過的。
在投入大量人力、物力上云的另一面，成果也已開始顯現。
截至目前，QQ產品、騰訊課堂已經實現100%遷移上云。
今年，他們計劃將其余老業務也全部重構上云，存量業務進行遷移。
今年，是“騰訊跑在騰訊云上”的第4個年頭。
業務發展愈加成熟，親歷上云的工程師、開發者們心態上也發生了不少變化。
比如于廣游，在親眼見證自己團隊的產品成為騰訊重大技術變革的基底之后，開心的同時，也慢慢“從技術原教旨主義者變成了一個更加務實的人”。
在自研上云前期，他對遇到的一些需求非常不能理解。比如要求自研上云需要原地重啟、需要指定POD去更新、需要做固定IP。
作為國內最早一批接觸K8S的人，于廣游覺得這些要求都很“不云原生”。
畢竟K8S的理念是讓部署容器化的應用簡單、高效，結果騰訊自研上云卻提出了一堆“亂七八糟”的需求。
但隨著自研上云的腳步往前邁進1-2年后，于廣游慢慢發現在接觸外部客戶時，他們也在提類似的需求。
由此他開始意識到，一些兼容特性的出現是有必要的。在此，他用VPC舉了個例子。
“比如VPC，它其實是為了讓云模擬IDC的網絡環境，是為了兼容企業上云之前傳統的網絡管理模式，所以VPC的出現本身就是為了降低企業遷移成本。”
而這正是云產品更為核心的演進方向。
在直接使用價值之上，進一步去降低企業遷移成本，才會吸引更多企業來上云。把云原生從一個小眾的前沿領域，逐漸變成一個覆蓋大眾需求的領域。
基于這樣的思考，于廣游表示自己之后看待技術問題開始從更加宏觀的角度出發，并在自研上云中發現有更多創新可做。
馬同星團隊有位專業能力強悍的資深工程師，甚至是因為自研上云這件事，才選擇繼續留在騰訊。
在負責工作室上云的開發和架構設計之前，他一度覺得工作少了很多新鮮感。
但云原生架構這一技術，重新吸引了他的目光。
因為這將會改變騰訊原本的開發模式，各個團隊不再自己重復“造輪子”，這個開發后臺也會更加開放。
全新的技術架構，打破了團隊同學們的職業發展瓶頸。
而透過自研上云這件事，更讓大家感受到開源社區的意義所在。
現在，他希望隨著云原生的大潮，他和團隊能夠對技術不斷迭代，為開源社區做出更多貢獻。
騰訊課堂研發中心的負責人王昂，則表示在上云過程中，“團隊的技術焦慮得以緩解”。
作為從QQ團隊一路走來的開發人員，他此前深刻意識到，騰訊內部老技術棧穩定、成熟的另一面，往往是與外界技術潮流的脫節。
這套技術棧會不會過時？研發人員僅在成熟技術上添磚加瓦，個人能力會不會掉隊？
這些問題在過去一段時間里，令王昂感到十分焦慮。
直到自研上云的變革到來，各個業務部門原本各自封閉的的“煙囪模式”被打破，他和團隊成員才紛紛感到技術視野大大拓寬，在面對外部挑戰之時，也更具技術自信。
盡管在自研上云最初，王昂對是否使用新技術棧，仍抱有過猶疑。但從結果來看，這一決定是正確的。
現在，王昂和同事們還有了新的“興趣愛好”：在騰訊內網連載上云的技術經驗。據說追更的人還不少。
2021年五一前后，在核心業務基本上云后，歡樂斗地主項目組把團建去處定在了江西武功山。
當所有人徒步爬到山頂后，大家發現云是真的在腳下的。
后臺同學們紛紛激動地發朋友圈：我們這才是真·上云的團隊！
而這種情緒的自然流露，或許正是團隊自身對于自研上云這件事，最發自內心的認同。
— 完 —
本文來自微信公眾號 “量子位”（ID：QbitAI），36氪經授權發布。
