騰訊全面上雲背後:程式設計師的技術焦慮和技術理想

思否編輯部 發表於 2022-06-28
騰訊 程式設計師

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 在技術上領先的點。”