石器時代–從十萬在線到百萬在線
石器時代是QQ空間1.0到3.0穩健上線的過程。
Qzone核心架構研發總監徐曉徐曉說："QQ空間在石器時代遇到的最大難題就是如何生存?如何讓這個襁褓中的產品活下來?如何積累第一批寶貴的用戶資源?"， 2005年QQ空間首發，最初是采用傳統的發放邀請碼的方式征集第一批用戶。第一款QQ空間是嵌在獨立的客戶端軟件中，看似是個客戶端，其實是一個瀏覽器內核，里面都是HTML頁面，以網站的方式存在。
當初的架構非常簡單，采用了Apache搭建Web Server，Mysql保存最終數據。用戶通過{uin}.qzone.qq.com(uin就是用戶的QQ號碼)這樣的方式訪問自己的空間。最開始上線時，僅邀請了電信用戶。但上線之后才發現很多北方網通用戶也非常希望來體驗。但如果讓北方網通用戶跨網來訪問電信的服務，那將是一個非常糟糕的體驗。因為當時的跨網之間的帶寬是非常有限的。
為了滿足網通用戶的需求，QQ空間團隊在網通搭建了一套與電信一模一樣的服務，電信的用戶數據只存在電信的服務器上，網通用戶數據只存在網通服務器上。看似異地分布，其實兩部分數據是互相獨立、不能冗余的。在用戶注冊開通空間時，就確定了他的數據存在于哪個服務器上。
用戶訪問空間的邏輯抽象來說是這樣的(如圖2)：用戶通過瀏覽器發起請求訪問我們的第一個CGI，這個CGI再串行的獲取用戶數據，比如：裝扮數據，日志數據等。等獲取到全部數據之后，這個CGI再將所有的數據拼裝成一個完整的HTML頁面輸出給用戶。

但同時，空間第一版的獨立客戶端也帶來了各種問題和煩惱：
第一：非常不利于定位問題。
一旦頁面元素填寫失敗，定位問題將是一件麻煩的事情。因為它不是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。

通過不斷的改進和優化，QQ空間3.0于2006年中穩健上線。
冷兵器時代——功能的磨礪
冷兵器時代是在線人數從百萬陣營向千萬陣營過渡的過程。這個階段做的更多的是功能的磨礪，提高可用性的過程。
但與此同時，QQ空間團隊又面臨了新的問題：
1、網通，教育網用戶體驗很差;
2、版本迭代快速，導致外網bug不斷;版本發布之后，所有開發必須留守2個小時;
3、后端服務質量不穩定，導致服務經常宕機。
之前有談到，空間的用戶數據是分布在電信與網通兩套體系中的。但由于公司在網通的服務設備有限，隨著用戶量的不斷增加，很快就達到了網通設備服務的上限。網通不能擴容設備，但用戶量還在不斷增加。面對這種情況，只好將網通和電信的數據合并為一套。當網通用戶訪問服務的時候，會通過一個代理將用戶的請求轉發到內網電信服務上。采用這種方式，提供了一套通用的解決方案，可以解決海外，網通，教育網，鐵通等運營商的問題。
但這種跨網訪問的靜態資源下載量非常大，靜態資源請求次數 : CGI請求數接近10：1，所以采用CDN提供靜態資源下載，來提高用戶訪問速度。具體邏輯是：根據用戶客戶端IP判斷用戶屬于哪一個ISP服務商，通過URL方式將用戶的靜態資源訪問定向到該ISP的服務設備上。
這樣，跳出CDN系統的拘束、優化思路，解決了大部分教育網用戶問題，同時多級支持的思路成為公共方案。
但同時還是有很多的故障：
1) 低ARPU、低成本、低價機器、大集群
2) 版本迭代快每周發布版本
3) 用戶對故障和低效的容忍度非常低
一般頁面在1s內打開，用戶會感覺體驗非常流暢。所以我們通過以下策略來保證服務質量：
1) 區分關鍵路徑,對關鍵路徑的服務質量我們要求4個9以上，非關鍵路徑的服務失敗之后做有損體驗;
2) 采用動態超時時間控制算法，保證整個程序在可控的時間內做出響應;
3) 多級容錯機制，從后端服務到CGI，到前臺JS腳本都對錯誤做了容錯處理;
4) 采用柔性可用策略,失敗接口采用默認數據。
為了保證版本的服務質量，空間采用了灰度發布策略。新特性可能按照用戶尾號發布,每次新特性只對一小部分人可見。一段時間內的用戶反饋后，不斷修復和改進問題，再逐步擴大用戶群對新特性的可見性，最后新特性才對全量用戶可見。同時，也通過控制JS版本號來達到了灰度發布的目的。
通過這些優化，QQ空間成功踏入千萬級在線的陣營，QQ空間5.0正式上線。其中主要變化：后端服務進行了重構，前端頁面也進行了優化。
現代戰爭時代–數千萬在線向億級在線
經過反復的改進和優化，QQ空間服務質量大幅提高，但是，新的問題還是隨之而來：
不滿足于發日志、傳照片的用戶，想要玩游戲、使用某些web工具。同時，公司其它團隊要在QQ空間上開發應用，但QQ空間的應用配置都寫死在QQ空間平臺邏輯里面。為配合其他團隊上線，發版本需要一周，工作不可并行，非常耗時，受到了很大挑戰。針對這種情況，我們采取了兩大措施：平臺和應用架構分離、簡單配置后上線。

如果某天深圳的IDC不可用了怎么辦?
為了解決這個問題，空間團隊做了全國IDC的異地部署，采用"一點寫，多點讀"模式的架構模型，將服務部署到深圳、上海、天津和西安。深圳是一個寫入點，通過QQ空間自己的一套同步系統同步到全國各個IDC。同時QQ空間提供了全方位的立體監控，7*24小時對服務做監控。
如何快速發現和解決用戶的問題?
定位用戶問題需要花很大的時間成本，這就要求團隊做很多的監控工作：服務器流量監控、接口調用監控、前端測速監控、前端調用錯誤監控。
同時，在千萬級到億級在線的過程中，團隊要有全國甚至全球的分布和匹配分布的運營能力;出問題可以快速切割，全方位的立體化監控能力;各個邏輯層持續優化能力。只有持續優化，用戶才能感知到性能的增加，用戶才會增加。
經過無數次的推敲和不斷優化，QQ空間的服務能力已經能夠支持千萬級別的用戶在線請求，并且能夠給用戶提供7*24小時的不間斷服務。向億級在線陣營沖刺也將指日可待!
總結：
百萬在線：
當時如何撐住服務，讓用戶進來，從而積累QQ空間第一批用戶，根據用戶模型進行優化，讓QQ空間架構有更好的接入能力，做到高性能。
千萬在線：
通過各層的柔性服務和灰度發布的策略，讓服務更加穩定，讓用戶數量級再上一個新臺階。
億級在線：
服務要有更靈活、更敏捷的變更手段。同時有更好的監控和可運營的能力。