在《從 0 開始學架構》專欄的第 8 期，我介紹了架構設計的三條核心原則：合適原則、簡單原則和演化原則。我們在架構設計實踐中，應該時刻謹記這三條設計原則，指導我們設計出合適的架構。即使是代表中國互聯網技術最頂尖水平的 BAT，其架構的發展歷程也同樣遵循這三條原則。今天我就以大家耳熟能詳的手機 QQ 作爲案例，來簡單分析一下。
注：以下內容部分摘自《QQ 1.4 億在線背後的故事》。
手機 QQ 的發展歷程按照用戶規模可以粗略劃分爲 4 個階段：十萬級、百萬級、千萬級、億級，不同的用戶規模，IM 後臺的架構也不同，而且基本上都是用戶規模先上去，然後產生各種問題，倒逼技術架構升級。
1. 十萬級 IM 1.X
最開始的手機 QQ 後臺是這樣的，可以說是簡單得不能再簡單、普通得不能再普通的一個架構了，因爲當時業務剛開始，架構設計遵循的是“合適原則”和“簡單原則”。
2. 百萬級 IM 2.X
隨着業務發展到 2001 年，QQ 同時在線人數也突破了一百萬。第一代架構很簡單，明顯不可能支撐百萬級的用戶規模，主要的問題有：
- 以接入服務器的內存爲例，單個在線用戶的存儲量約爲 2KB，索引和在線狀態爲 50 字節，好友表 400 個好友 × 5 字節 / 好友 = 2000 字節，大致來說，2GB 內存只能支持一百萬在線用戶。
- CPU/ 網卡包量和流量 / 交換機流量等瓶頸。
- 單臺服務器支撐不下所有在線用戶 / 註冊用戶。
於是針對這些問題做架構改造，按照“演化原則”的指導進行了重構，重構的方案相比現在來說也還是簡單得多，因此當時做架構設計時也遵循了“合適原則”和“簡單原則”。IM 2.X 的最終架構如圖所示。
3. 千萬級 IM 3.X
業務發展到 2005 年，QQ 同時在線人數突破了一千萬。第二代架構支撐百萬級用戶是沒問題的，但支撐千萬級用戶又會產生新問題，表現有：
- 同步流量太大，狀態同步服務器遇到單機瓶頸。
- 所有在線用戶的在線狀態信息量太大，單臺接入服務器存不下，如果在線數進一步增加，甚至單臺狀態同步服務器也存不下。
- 單臺狀態同步服務器支撐不下所有在線用戶。
- 單臺接入服務器支撐不下所有在線用戶的在線狀態信息。
針對這些問題，架構需要繼續改造升級，再一次“演化”。IM 3.X 的最終架構如下圖，可以看到這次的方案相比之前的方案來說並不簡單了，這是業務特性決定的。
4. 億級 IM 4.X
業務發展到 2010 年 3 月，QQ 同時在線人數過億。第三代架構此時也不適應了，主要問題有：
- 靈活性很差，比如“暱稱”長度增加一半，需要兩個月；增加“故鄉”字段，需要兩個月；最大好友數從 500 變成 1000，需要三個月。
- 無法支撐某些關鍵功能，比如好友數上萬、隱私權限控制、PC QQ 與手機 QQ 不可互踢、微信與 QQ 互通、異地容災。
除了不適應，還有一個更嚴重的問題：
IM 後臺從 1.0 到 3.5 都是在原來基礎上做改造升級的，但是持續打補丁已經難以支撐億級在線，IM 後臺 4.0 必須從頭開始，重新設計實現！
這裏再次遵循了“演化原則”，決定重新打造一個這麼複雜的系統，不得不佩服當時決策人的勇氣和魄力！
重新設計的 IM 4.0 架構如圖所示，和之前的架構相比，架構本身都拆分爲兩個主要的架構：存儲架構和通信架構。
- 存儲架構
- 通信架構
作者寄語：
每個程序員都有成爲架構師的夢想，程序員成長也繞不開架構設計。在專欄中，我從架構基礎、三大架構模式和實戰的角度分享一整套架構設計方法論。照着做，你也能成爲架構師。專欄共 50 期，已更新完畢。目前有超過 3 萬人加入學習，互動留言字數超過 20 萬。期待你的加入！
作者簡介：
《從 0 開始學架構》專欄作者，資深技術專家李運華，目前帶領多個研發團隊，承擔架構設計、架構重構、技術團隊管理、技術培訓等職責，曾就職於華爲和 UCWeb，寫過《面向對象葵花寶典》一書。
內容選自極客時間《從 0 開始學架構》專欄