👉 導讀

負責的閘道器日呼叫量從1千到億，具備獨立完成千萬 DAU 產品的技術能力，我用了整整 10 年。這個過程，我走了很多彎路，也學到了很多東西。這些東西，我想和大家分享。你缺少的不是道理，而是理解道理的機緣，靜水流深虛心沈澱，屬於你的時刻終會到來！

👉 目錄

1 前言

2 業務背景：技術選擇直接影響著我們的工作效率和產品品質

3 整體架構：如果存在一種捷徑，那就是難路

4 方案對比：不要在很差的基礎上，拼命做最佳化

5 核心難點：每一個細小問題的解決都是產品護城河的加深

我們缺的不是道理，畢竟最有用的東西都寫在常識裏了，我們缺的是理解道理的機緣。

所以，我希望這篇文章能成為一些人的機緣，如果你有所收獲，也不是我的功勞，而是你已經具備了悟透的條件，明白只是早晚的事。

從前端到全棧的心路歷程：

作為 10 年前端老兵，最近五年基本投身於全棧技術。記得剛開始接觸全棧時，我面對的不僅僅是一種技術棧的轉換，更是一種思維方式的變革。我曾參與開發一個月流水達千萬的廣告投放平台，那是我第一次從0到1實作了一個復雜系統的構建。這個經歷不僅鍛煉了我的技術能力，更讓我學會了如何在面對看似不可能的任務時找到解決之道。 現在，我負責的計畫是日活躍使用者數以千萬計的 ToC 套用 —— QQ 前端統一接入層。

這些經歷讓我深刻理解到，作為一個程式設計師不僅僅是在編寫程式碼，更是在用技術解決實際問題，創造價值。

在我的全棧開發之旅中，還探索了管理端低程式碼、H5 低程式碼和大數據服務領域。這些經歷不僅豐富了我的技術背景，也鍛煉了我在處理復雜數據和系統的能力。 而今天，我想重點分享個人技術實踐的一個高峰：QQ 前端統一接入層，這個計畫不僅對 QQ 業務有著重大價值，也是對我個人技術能力的一次重要驗收。

01

前言

我希望今天的分享不僅僅是關於技術的堆砌，更是一次深入背後故事的探索。

我們將一起走進計畫的業務背景，看看它是如何將業務和開發需求相結合的。從計畫出發深入到架構設計，與不同技術方案的對比，在眾多選擇中找到最適合業務的那一條路。這個過程中遇到的核心技術難題，匯聚成了本篇文章最有價值的技術認知。

02

業務背景：技術選擇直接影響著我們的工作效率和產品品質

讓我們來談談 QQ NT 的前進演化歷程。舊版 QQ 通訊鏈路的客戶端 SDK 並不支持跨平台，這意味著我們必須為每個平台分別開發一套 SDK。而 NT 的設計初衷，正是要打破這種局限，實作各平台 SDK 的整合和復用。這一轉變不僅促進了技術的進步，也推動了我們的後台系統進行相應的改造。然而 Web 版的 NT 尚未實作，對於 QQ 頻道這樣一個快速叠代且功能繁多的產品來說，例如貼文、榜單和 ark 等功能多透過 H5 和 QQ 小程式實作，這種缺失就變得尤為明顯。我們面臨的挑戰，是如何在不斷增長的功能需求和現有技術限制之間的矛盾。

讓我們來探究 Web 版 NT 缺失背後的影響。這一缺口不僅是技術上的空白，更是一系列問題的源頭。 我們不得不建立超過 100+ Node 服務來與後台服務互動，每個服務都重復建設鑒權和 RPC 呼叫。根據最近一次統計，如果把各前端小組的數量加起來，這個數位超過了300。

想象一下，整個前端團隊分散在 300 多個計畫中，重復勞作和資源浪費是顯而易見的。首先，維護成了一個巨大的負擔，隨著功能的增加，我們團隊的大部份時間都耗費在了這些 Node 服務的運維上。其次，在高效能需求場景下，如頻道榜單，我們發現效能和穩定性的不足直接影響了使用者體驗。最後，不完善的日誌和監控系統在開發和偵錯階段導致了效率低下。

這就是我們需要面對的現實： 技術選擇直接影響著我們的工作效率和產品品質。

03

整體架構：如果存在一種捷徑，那就是難路

前端接入層的整體架構。 這不僅僅是一系列技術元件的組合，而是一個精心設計的系統，旨在為 QQ NT+ 提供一個既穩定又高效的伺服端解決方案。

我們在設計時考慮了眾多因素，從系統效能到擴充套件性，從安全性到易維護性。每一個決定都是對當前需求的響應，同時也預留了空間以適應業務可能的發展方向，比如海外版。

整體架構的建設主要面臨兩大挑戰：其一，解決當前存在的技術難題，這要求深入了解各種技術方案的優勢與局限。其二，為未來可能的發展留出空間。這不僅是技術層面的挑戰，更是一次對現有系統架構深度理解的考驗， 如果存在一種捷徑，那就是難路，這一步萬不可偷懶。

04

方案對比：不要在很差的基礎上，拼命做最佳化

4.1 司內及開源方案對比

業務閘道器的特殊性，不存在一套適用所有業務的開源方案，所以這裏只橫向比較最上一層。

我研究過不少業務閘道器建設的案例，發現了一個常見的誤區： 在很差的基礎上，拼命做最佳化！ 前期針對核心模組的可量化分析必不可少。

我以 nginx 作為參照，結合業務場景，分效能、數據儲存、私有部署等幾個維度比較 apisix 在效能、靈活性及接入成本上取得最佳平衡。

4.2 部門內方案對比

回顧一年半前，http2rpc 只是我們考慮的四個方案之一。但今天，它已成為 QQ 前端接入的事實標準。這一轉變背後的故事頗為精彩。

首先，讓我們來看看接入成本。http2rpc 在這方面做到了前後端的完全配置化和與 CI 的無縫整合。其次，它的架構設計既分層又模組化，使得即便是海外業務接入也變得更加高效，叠代成本大大降低。在效能方面，http2rpc 顯著優於現有方案，提升了整體的服務響應和處理能力。更重要的是，它提供了全面的功能，包括監控、告警和全鏈路跟蹤，確保了服務的成熟度和可靠性。

這些因素共同作用，使得 http2rpc 能夠全面支撐起 QQ 的各種執行環境，成為我們技術演進的核心。

05

核心難點：每一個細小問題的解決都是產品護城河的加深

從協定轉換成長為功能完備的業務閘道器，從服務於營運系統到走出頻道業務，從日調幾千到上億，這個架構建設過程並非一蹴而就，其中的每一步都是對業務需求的深刻理解和對開發痛點的精準回應。

我把挑戰歸納為兩大類。

首先是普遍性挑戰，這些是幾乎所有業務閘道器建設計畫都會遇到的。其次，是特有的業務挑戰。以 QQ 為例，我們面臨的是歷史遺留問題，比如三種不同的通訊協定共存的情況。這種獨特的挑戰要求我們不僅要有技術上的廣度，還需要深度和創造性地思考。如何應對這些特殊挑戰，同時保持系統的整體協調和高效運轉，成了我們思考的重點。

5.1 可觀測性及告警：無反饋、不叠代，只有具備反饋機制，叠代才不是擺設

接入層的建設中，品質和效率的重要性不言而喻。因此，檢驗標準的制定尤為重要，其中最關鍵的兩點是：

舉個例子，透過撥測和基於日誌的告警，我成功地發現並修復了 tRPC 框架中一個極其隱蔽的問題 —— 空閑連線回收。這個改進不僅提高了我們接入層的可用性，還為其他使用 tRPC 的業務帶來了好處。

但是，技術改進也會帶來新的挑戰。

我們引入的基於日誌的告警系統雖然提高了告警的靈敏度，但也導致了告警轟炸的問題。面對這個挑戰，我們意識到解決之道在於 為告警系統引入反饋機制。 這也形成了我做很多功能的方法論： 無反饋、不叠代，只有具備反饋機制，叠代才不是擺設，才能真正服務於使用者。

5.2 效能：面向通用場景做到極致很難，但永遠可以在具體場景下做到更極致

效能不僅是技術挑戰，也直接關系到使用者體驗和業務成功。

對效能最佳化，我一直堅持一個原則： 盡管針對通用場景的最佳化有其挑戰性，但我們總能在特定場景中找到提速的空間。

這裏分享一個關於效能最佳化的相關案例。對於地圖類遊戲，即時性的要求遠高於數據完整性，且初始的數據下行量相對較大。我的最佳化策略是充分利用這些特點，實作基於時間偏移的分級推播，同時調整訊息確認機制為最少一次確認。這項最佳化帶來的成效超出預期：不僅顯著減少了低端裝置在執行遊戲時的發熱和卡頓問題，還提升了整體的遊戲體驗。

新版 QQ 體驗地址 QQ PC 版官方網站(https://im.qq.com/pcqq)歡迎試用。

對技術原理的理解與掌握，是程式設計師從普通邁向優秀的階梯。理解業務的復雜性，並能根據業務特點做出技術選型與架構設計，是分隔優秀與卓越的鴻溝。願這篇文章的一些思考與總結能幫助騰訊雲開發者社群的讀者朋友，跨越鴻溝！

-End-

原創作者｜付誌遠

關註 頂尖架構師棧，添加「星標」

獲取每天技術幹貨，突破自我，成為牛逼架構師

IT一線從業者抱團群

致力於幫助廣大開發者提供高效合適的工具，讓大家能夠騰出手做更多創造性的工作，也歡迎大家分享自己公司的內推資訊，相互幫助，一起進步！

組建了程式設計師，架構師，IT從業者交流群，以 交流技術 、 職位內推 、 行業探討 為主