QQ 空間作為騰訊海量互聯網服務產品，經過近七年的發展，實現了從十萬級到億級同時在線的飛躍。在這個過程中，QQ 空間團隊遇到了哪些技術挑戰?其站點前后臺架構隨著業務規模的變化又進行了怎樣的演進與變遷?成長背后有過怎樣的心酸和快樂……

　　4. 26 日晚間，騰訊大講堂·深圳首站《QQ 空間技術架構之崢嶸歲月》活動在騰訊總部騰訊大廈多功能廳舉辦，騰訊 Web 前端研發領域專家、騰訊最早的專職 Web 開發團隊核心成員、Qzone 核心架構研發總監徐曉在兩小時的演講中揭開了 QQ 空間技術架構背后的秘密。

　　正式分享之前，徐曉介紹了 QQ 空間目前的海量服務數據規模(圖1)：

　　1) 擁有5.5億的活躍用戶

　　2) 過萬臺的設備

　　3) 數千萬級別的同時在線

　　4) 數十億級別的全站 PV

　　5) P 級的 UGC 存儲量

　　6) 每天千億級別的服務請求

　　圖1——QQ 空間海量服務數據規模

　　接下來，徐曉把 QQ 空間成長和發展的歷程分成三個階段：石器時代、冷兵器時代和現代戰爭時代，分享了 QQ 空間從開始甚至難以生存，到逐步發展成國內最大的 SNS 社區產品背后的酸甜苦辣。

石器時代–從十萬在線到百萬在線

　　石器時代是 QQ 空間1.0到3.0穩健上線的過程。

　　徐曉說："QQ 空間在石器時代遇到的最大難題就是如何生存?如何讓這個襁褓中的產品活下來?如何積累第一批寶貴的用戶資源?"， 2005 年 QQ 空間首發，最初是采用傳統的發放邀請碼的方式征集第一批用戶。第一款 QQ 空間是嵌在獨立的客戶端軟件中，看似是個客戶端，其實是一個瀏覽器內核，里面都是 HTML 頁面，以網站的方式存在。

　　當初的架構非常簡單，采用了 Apache 搭建 Web Server，MySQL 保存最終數據。用戶通過{uin}.qzone.qq.com (uin 就是用戶的 QQ 號碼)這樣的方式訪問自己的空間。最開始上線時，僅邀請了電信用戶。但上線之后才發現很多北方網通用戶也非常希望來體驗。但如果讓北方網通用戶跨網來訪問電信的服務，那將是一個非常糟糕的體驗。因為當時的跨網之間的帶寬是非常有限的。

　　為了滿足網通用戶的需求，QQ 空間團隊在網通搭建了一套與電信一模一樣的服務，電信的用戶數據只存在電信的服務器上，網通用戶數據只存在網通服務器上?？此飘惖胤植迹鋵崈刹糠謹祿腔ハ嗒毩?、不能冗余的。在用戶注冊開通空間時，就確定了他的數據存在于哪個服務器上。

　　用戶訪問空間的邏輯抽象來說是這樣的(如圖2)：用戶通過瀏覽器發起請求訪問我們的第一個 CGI，這個 CGI 再串行的獲取用戶數據，比如：裝扮數據，日志數據等。等獲取到全部數據之后，這個 CGI 再將所有的數據拼裝成一個完整的 HTML 頁面輸出給用戶。

　　圖2——Qzone2.0典型載入邏輯

　　但同時，空間第一版的獨立客戶端也帶來了各種問題和煩惱：

　　第一：非常不利于定位問題。

　　一旦頁面元素填寫失敗，定位問題將是一件麻煩的事情。因為它不是 Web 頁面，所以只能用其他抓包軟件，比如 Ethereal (Wireshark 的前身)來抓取網絡包做分析。但那個時候網絡抓包工具的能力還比較弱，沒有高亮和 HTML 語法檢測等功能，所以整體環境比較受限。

　　第二：服務接入層壓力大。

　　由于不僅要接受用戶的請求，還要向后訪問不同的數據。當后端某一個接口超時嚴重的情況下，很多用戶的請求都會被掛起。這樣就會消耗更多的連接資源，對 Web 服務器 CPU 的消耗很大。

　　第三：服務集群沒有發揮出應有的服務能力

　　當時共用30~40臺服務器，也只能支持 50 萬左右的用戶。無奈之下，團隊想了一個沒辦法的辦法：有意限制超過五十萬用戶，提出了一個排隊等待機制，學習海底撈模式，當在線人數達到 50w 的時候，QQ 空間會給用戶展示一個 Flash 小游戲，讓用戶在等待的時候玩小游戲。

　　針對當時存在的種種問題，團隊做了以下改進來解決：

　　第一：采用 Web RIA。

　　當時大量使用了 Ajax 技術來減輕服務器的負載。其中一個極端的例子是：整個空間首頁都是采用 JS 繪制，這樣能夠將用戶訪問的 CGI 足夠輕量化。盡量簡化了 CGI 邏輯，讓 CGI 程序運行更加強壯、效率更高。同時，當服務異常時，還可以通過 JS 腳本繪制一個錯誤信息給予用戶提示。而且，采用 JS 開發效率更高，調試更方便。

　　Web RIA 化后，降低了服務器 CPU 消耗的 40%，節約了 DC 的輸出帶寬約 30%(部分 JS 腳本都可以被瀏覽器 Cache 住)。

　　第二：采用動靜分離策略。靜態資源都放在自研的 Web 服務器 qhttpd 上，它具備當時 ApacheSelect 模型的兩個數量級以上的接入能力。

　　第三：采用自研的 Web Server：Qzhttp，主要用于動態分離的動態服務的需要。由于 Qzhttp 是騰訊自研的、輕量的、更適合業務自己邏輯的 Web Server，從而保證了它的高性能，它的接入能力比 Apache (非 FastCGI 模式)提高了 3 倍。

石器時代做的最大的優化：

　　當用戶申請 QQ 空間多個服務時，每個服務都有獨立的存儲和處理邏輯。只有當所有的服務處理完成，才會由 QQ 空間框架服務器返回給用戶。這樣對于同時依賴日志、相冊、音樂、留言的服務就會產生兩大問題：

　　1) 短板效應一損俱損;

　　2) 具體業務容量無法差異化。

　　針對這兩個問題，做了首頁載入性能優化及首頁內容靜態化系統兩方面的優化：

　　研究用戶訪問模型。拉取展現與 UGC 內容的變更比例是7：1。用戶之間互訪頻繁，看他人與看自己的比例是5：1.。通過以上數據，可以看出用戶的 UGC 更新很少，但是用戶之間互相訪問很頻繁。根據用戶的這種訪問模型，空間團隊研發了一套靜態化系統(圖3)。這套系統會將用戶首頁的內容全部 Cache，然后根據用戶的訪問，以及用戶自己 UGC 內容的更改，采用一定策略更新靜態化系統的 Cache 數據。

　　通過增加首頁內容靜態化系統，首頁展現速度從 5s 提升到 3s，用戶也不用再玩小游戲進行等待。同時在設備沒有擴容的前提下，同時在線用戶訪問數突破 100w。

　　圖3—首頁內容靜態化系統

　　通過不斷的改進和優化，QQ 空間3.0于 2006 年中穩健上線。

冷兵器時代——功能的磨礪

　　冷兵器時代是在線人數從百萬陣營向千萬陣營過渡的過程。這個階段做的更多的是功能的磨礪，提高可用性的過程。

　　但與此同時，QQ 空間團隊又面臨了新的問題：

　　1、網通，教育網用戶體驗很差;

　　2、版本迭代快速，導致外網 bug 不斷;版本發布之后，所有開發必須留守 2 個小時;

　　3、后端服務質量不穩定，導致服務經常宕機。

　　之前有談到，空間的用戶數據是分布在電信與網通兩套體系中的。但由于公司在網通的服務設備有限，隨著用戶量的不斷增加，很快就達到了網通設備服務的上限。網通不能擴容設備，但用戶量還在不斷增加。面對這種情況，只好將網通和電信的數據合并為一套。當網通用戶訪問服務的時候，會通過一個代理將用戶的請求轉發到內網電信服務上。采用這種方式，提供了一套通用的解決方案，可以解決海外，網通，教育網，鐵通等運營商的問題。

　　但這種跨網訪問的靜態資源下載量非常大，靜態資源請求次數 : CGI 請求數接近 10：1，所以采用 CDN 提供靜態資源下載，來提高用戶訪問速度。具體邏輯是：根據用戶客戶端 IP 判斷用戶屬于哪一個 ISP 服務商，通過 URL 方式將用戶的靜態資源訪問定向到該 ISP 的服務設備上。

　　這樣，跳出 CDN 系統的拘束、優化思路，解決了大部分教育網用戶問題，同時多級支持的思路成為公共方案。

　　但同時還是有很多的故障：

　　1) 低 ARPU、低成本、低價機器、大集群

　　2) 版本迭代快每周發布版本

　　3) 用戶對故障和低效的容忍度非常低

　　通過調研，我們發現用戶對 Web 的容忍度是很低的(如圖4)：

　　圖4——用戶容忍度曲線

　　一般頁面在 1s 內打開，用戶會感覺體驗非常流暢。所以我們通過以下策略來保證服務質量：

　　1) 區分關鍵路徑，對關鍵路徑的服務質量我們要求 4 個 9 以上，非關鍵路徑的服務失敗之后做有損體驗;

　　2) 采用動態超時時間控制算法，保證整個程序在可控的時間內做出響應;

　　3) 多級容錯機制，從后端服務到 CGI，到前臺 JS 腳本都對錯誤做了容錯處理;

　　4) 采用柔性可用策略，失敗接口采用默認數據。

　　為了保證版本的服務質量，空間采用了灰度發布策略。新特性可能按照用戶尾號發布，每次新特性只對一小部分人可見。一段時間內的用戶反饋后，不斷修復和改進問題，再逐步擴大用戶群對新特性的可見性，最后新特性才對全量用戶可見。同時，也通過控制 JS 版本號來達到了灰度發布的目的。

　　通過這些優化，QQ 空間成功踏入千萬級在線的陣營，QQ 空間5.0正式上線。其中主要變化：后端服務進行了重構，前端頁面也進行了優化。

現代戰爭時代–數千萬在線向億級在線

　　經過反復的改進和優化，QQ 空間服務質量大幅提高，但是，新的問題還是隨之而來：

　　不滿足于發日志、傳照片的用戶，想要玩游戲、使用某些 web 工具。同時，公司其它團隊要在 QQ 空間上開發應用，但 QQ 空間的應用配置都寫死在 QQ 空間平臺邏輯里面。為配合其他團隊上線，發版本需要一周，工作不可并行，非常耗時，受到了很大挑戰。針對這種情況，我們采取了兩大措施：平臺和應用架構分離(如圖5)、簡單配置后上線(如圖6)。

　　圖5——平臺和應用架構分離

　　圖6——簡單配置后上線

　　如果某天深圳的 IDC 不可用了怎么辦?

　　為了解決這個問題，空間團隊做了全國 IDC 的異地部署，采用"一點寫，多點讀"模式的架構模型，將服務部署到深圳、上海、天津和西安。深圳是一個寫入點，通過 QQ 空間自己的一套同步系統同步到全國各個 IDC (如圖7)。同時 QQ 空間提供了全方位的立體監控，7*24小時對服務做監控。

　　圖7——IDC 分布

　　如何快速發現和解決用戶的問題?

　　定位用戶問題需要花很大的時間成本，這就要求團隊做很多的監控工作：服務器流量監控、接口調用監控、前端測速監控、前端調用錯誤監控。

　　同時，在千萬級到億級在線的過程中，團隊要有全國甚至全球的分布和匹配分布的運營能力;出問題可以快速切割，全方位的立體化監控能力;各個邏輯層持續優化能力。只有持續優化，用戶才能感知到性能的增加，用戶才會增加。

　　經過無數次的推敲和不斷優化，QQ 空間的服務能力已經能夠支持千萬級別的用戶在線請求，并且能夠給用戶提供7*24小時的不間斷服務。向億級在線陣營沖刺也將指日可待!

總結：

　　百萬在線：

　　當時如何撐住服務，讓用戶進來，從而積累 QQ 空間第一批用戶，根據用戶模型進行優化，讓 QQ 空間架構有更好的接入能力，做到高性能。

　　千萬在線：

　　通過各層的柔性服務和灰度發布的策略，讓服務更加穩定，讓用戶數量級再上一個新臺階。

　　億級在線：

　　服務要有更靈活、更敏捷的變更手段。同時有更好的監控和可運營的能力。

　　接下來是半個小時的Q&A環節，同學們踴躍提問，徐曉做出了詳細專業的解答。最后，徐曉和大家分享了"騰訊《海量服務之道》系列的優質課程和秉承的原則"：

　　Qzone 是全球第二大 SNS 社區，僅次于 Facebook。徐曉說："海量服務的價值觀和用戶對我們的厚愛造就了現在的 QQ 空間。我們會持續的發展，攻克各種難題，不斷前進。"

　　4月 26 日 21:00，兩個小時的 QQ 空間技術架構分享圓滿結束!

　　歡迎大家繼續期待 5 月 16 日晚舉辦的騰訊大講堂對外講座·第八期《云網絡能帶給我們什么》 。更多精彩，盡在騰訊大講堂：DJT.QQ.COM。