2018 年，騰訊正式啟動“自研業務上雲”戰略，微信、QQ、騰訊遊戲等海量業務開始了浩浩蕩蕩的搬家之旅。
將本地部署的程式直接轉移到雲上，並不能完全享受到雲端計算的優勢，唯有依託雲技術棧重新部署、部分重構甚至全部重寫，才能由水土不服的“外來者”，成為土生土長的雲上“原住民”。
在這個過程中，騰訊的開發者們發揮了極其重要的作用，他們圍繞著雲原生進行自我技術迭代，通力合作，搭建了一條通往雲端的技術“天路”。
2022 年 6 月 16 日，騰訊正式宣佈，內部海量自研業務已實現全面上雲。
短短一句話的背後，是國內最大的雲原生實踐。據統計，騰訊的自研業務上雲規模已經突破 5000 萬核，累計節省成本超過 30 億。
騰訊自研業務上雲的四年，也是騰訊開發者成長和蛻變的四年。
上雲，讓技術水平脫胎換骨
上雲帶來的彈性伸縮能力，可以大幅提升資源利用率，降低財務成本，這足以成為大部分業務向雲上搬遷的理由，但對遊戲團隊來說，因為要持續進行高強度的內容研發，重構的成本和風險不容忽視。
“坦白講，我們做上雲這件事，初期的主要目標不是為了節約計算成本。遊戲是比較複雜的業務場景，與在原有架構下持續迭代相比，徹底做一次雲原生重構需要投入不小的額外技術成本，是不是划算的呢？”這是騰訊 IEG 歡樂工作室技術總監馬同星團隊，在雲原生重構啟動前最大的糾結。
“思來想去，雲原生重構是對流量的動態治理和排程能力的系統提升，提升容災和容錯能力，進而提升業務的可靠性。”馬同星說。
“通過重構上雲，我們把服務的動態伸縮變成了常態化、每時每刻都能進行的動作，這也就意味著任何節點或網路故障的時候，都能自動完成故障轉移。沒有這個能力，我們就得半夜從床上爬起來手動切換——這是完全不同的技術水平。”
類似情況還體現在故障管理上。傳統客戶端發生故障時，因為後端發生了一系列複雜呼叫，需要分析日誌才能找到問題源頭。但在雲原生架構下，呼叫鏈路清清楚楚，問題節點一目瞭然。
“這些治理能力下沉到基礎設施層面，前期業務架構重構的成本和挑戰雖大，但研發運營效率、質量的提升卻是長期受益的。”馬同星這樣勸說自己的團隊，“而且這是行業趨勢，是機會，雖然現在不做也可以運營得很好，那三年後呢？可能我們距離行業一流的團隊經差很遠了。”
就這樣，團隊達成了共識，投入到雲原生的實踐中。他們進行了大量研究與分享，甚至專門翻譯了一本 K8s 的書籍。經過幾年的雲原生重構實踐，團隊的專業能力顯著提升，多位同事也自然而然地獲得了專業晉升。
如果當初團隊沒有堅持走雲原生的技術路線，現在會怎麼樣？馬同星想象不出來，但他知道，有新技術出現，就一定會有革命，如果沒法保證自己不被別人革命，那不如主動投身到技術革命中。
投身雲原生實踐，打破技術焦慮
參與自研上雲專案前，哪怕是服務 QQ 這樣的明星業務，王昂依然有揮之不去的技術焦慮。同樣的焦慮感像低氣壓，籠罩在團隊每個人頭上。
2013 年，王昂畢業後進入騰訊，參與 QQ 後臺系統的開發。當時，QQ 作為一款上線十多年、月活超過 8 億的明星產品，擁有成熟穩定的自研架構。在外人眼裡，這絕對是一份讓人豔羨的工作。
但最初的興奮感過去之後，王昂卻陷入了自我懷疑：“如果只是基於 QQ 的自研技術棧修修補補、閉門造車，長期下來，自己的技術會不會和行業脫節，甚至落後？”
懷著難以排解的焦慮，王昂終於在幾年後等來了轉機。2018 年 930 變革後，CSIG 成立，他所在的團隊被整個劃入其中，開始做名為“騰訊課堂”的新產品。此時，一個需要抉擇的問題擺在團隊面前：是沿用 QQ 成熟穩定的老技術棧，還是使用騰訊雲持續完善中的新技術棧？
這是一個很難衡量的問題。從實用主義的角度來看，QQ 的技術棧服務過海量使用者，堪稱千錘百煉。如果向新技術棧靠攏，上雲初期會大幅增加工作量和學習成本，甚至可能因為元件不夠成熟而影響業務質量。
對新技術的渴望壓倒了顧慮，技術焦慮成為讓天平傾斜的最後一個籌碼：對業務而言，上雲與否短期來看或許沒有區別，長期則會帶來研效的巨大差距；對開發者個人來說，公有云的技術棧是先進的，更是與外界接軌的，他們早就不甘心只當個修補匠，誰又願意讓這個機會溜走呢？
“以前我沒得選，現在想試試新技術。”
王昂舉了個例子：“如果沿用 QQ 的技術棧，要實現業務邏輯必須吭哧吭哧寫上一堆程式碼，但業務上雲後，Redis 能直接解決很多複雜的資料結構問題，幾行程式碼就能實現相同效果。公有云上有大量優秀元件，對研效有脫胎換骨的提升。”
和預期一樣，更換技術棧並非一帆風順。有一天，部分使用者資料突然成了亂碼，研發團隊就原因定位了很久，發現是因為本地資料庫有一些特殊編碼，沒有和雲資料庫的元件對齊，這才導致問題出現。
踩過這次坑，王昂意識到，上雲流程一定要足夠紮實，包括初期的工具準備、遷移過程的監測、遷移完成後的資料對賬，都需要把細節摳得很細，才能保障業務的成功率。
為此，王昂和團隊就上雲元件的細節，與騰訊雲的產品部門進行了大量磨合，一年下來反饋了近 400 個問題，雙方就容器、運維、音視訊等元件進行了持續交流，既完善了騰訊雲的技術棧，也保障了騰訊課堂的上雲過程。
2020 年初，新冠疫情爆發，騰訊課堂的流量也隨著疫情反覆大幅度波動，高峰期訪問量可以達到平時的 100 倍。
如果沿用 QQ 的自研技術架構，需要提前幾天申請伺服器資源，然後手動擴容。騰訊課堂上雲後，在容器化部署與彈性擴縮容的支撐下，騰訊課堂實現了自動流暢擴容，既大幅緩解了運維壓力，穩定流暢的表現也得到了業務部門的認可。
這一刻，王昂覺得籠罩在團隊頭上的技術焦慮終於散去了。
如今，王昂已經是騰訊課堂的技術負責人。工作 9 年後晉升到這個位置，速度算得上很快，他認為這與參與自研上雲頗有關係。除了對晉升的幫助，他更感謝自研上雲讓他接觸了大量優秀的開源元件，技術視野變得更加開闊，並且能夠將前沿技術應用在業務當中，這極大緩解了他的技術焦慮。
“如果感到焦慮一定要行動起來，去做難而正確的事情，行動是緩解焦慮的最好辦法。”
追求技術理想，也要理解現實需求
技術極客於廣遊是國內最早投身K8s社群的先鋒之一，對容器有著深厚的理解和認知。他和容器團隊一同打造了國內最早的基於 K8s 容器化產品的平臺——騰訊雲容器服務（Tencent Kubernetes Engine，TKE）。
第一次聽到公司要自研上雲時，於廣遊的第一反應是“很爽”，“騰訊要跑在騰訊雲上了”。
但現實並沒有想象那麼爽。
於廣遊曾自認為是個技術原教旨主義者，對技術路線有嚴格的堅持，但在自研上雲的過程中，業務提出了一系列和雲原生背道而馳的需求，這一度讓他非常抓狂。
差異源於歷史，譬如微信原有的架構執行在物理機上，部分系統例如訪問控制，需要把 IP 寫死。十多年過去，微信支撐了十多億使用者的可靠與穩定使用，儘管架構不斷迭代，這個特性卻融入到整個系統，牽一髮而動全身。
圍繞技術進行大量討論後，為了不損害微信的原有設計架構，從而降低遷移成本，容器團隊最終開發了支援固定 IP 的特性。
開發出這個堪稱“行業獨家”的能力後，於廣遊一度為技術不夠純粹而鬱悶，但他很快發現，對固定 IP 的支援其實是個普遍需求，CSIG 和 IEG 的很多存量業務在遷到容器上時都需要固定 IP，這個功能甚至成為了吸引外部客戶的利器。
類似情況發生了不止一次，有業務團隊希望能指定TKE叢集的介面引數，也有業務團隊希望 TKE 能實現 Pod 原地變更，這些都和於廣遊理解的雲原生存在差異，然而就結果來看，業務團隊提出的需求，往往也是行業共性的需求。
“雲原生技術不只要支援新業務上雲，存量業務也有需求，但純粹的雲原生技術並不能完全支援。”為了支援大量存量業務上雲，TKE 開發出了很多不那麼“原教旨”的能力，但實實在在降低了業務的上雲成本。
經過技術理想與現實需求的磨合，於廣遊拋下了對原教旨雲原生的矜持，變得更加靈活務實。他和團隊開發的容器技術除了支援微服務，也開始支援資料庫、大資料等有狀態服務……如今，他已經不把這些視為定製化服務，而是基於雲原生核心的創新，不僅能幫助業務降低遷移成本，更能讓雲原生從專用場景向泛用場景擴充
“定製和創新的區別是什麼呢？雲原生的核心是宣告式的 API，是不可變基礎設施，只要定製化的需求不影響本質，它依然是雲原生，甚至會成為創新的契機，進一步豐富 TKE 能力。”
“原本我認為技術應該義無反顧地向前瞻的方向邁進，但後來發現，任何一項技術演進，首先要在最適合的場景落地，隨後進行技術強化和普適化，也就是能夠相容舊架構去持續演進。”
“不僅要追求區域性最優，也要追求全域性最優”，於廣遊說，“誰能想到原先虐我的那些東西，如今都變成了 TKE 在技術上領先的點。”