淘寶技術發(fā)展主要經(jīng)歷了“個人網(wǎng)站”→“Oracle/ 支付寶 / 旺旺”→“Java 時代 1.0”→“Java 時代 2.0”→“Java 時代 3.0”→“分布式時代”祸憋。每個階段的主要驅動力是什么御滩。

1. 個人網(wǎng)站

淘寶當時在初創(chuàng)時概说，沒有過多考慮技術是否優(yōu)越、性能是否海量以及穩(wěn)定性如何，主要的考慮因素就是：快！

買一個什么樣的網(wǎng)站？方便地擴展和二次開發(fā)胸囱。答案是：輕量一點的，簡單一點的妹卿。

買一個系統(tǒng)是為了“快速可用”旺矾，而買一個輕量級的系統(tǒng)是為了“快速開發(fā)”。主要遵循的是“合適原則”和“簡單原則”夺克。第一代的技術架構如圖所示箕宙。

2.Oracle/ 支付寶 / 旺旺

在 2003 年底，MySQL 已經(jīng)撐不住了铺纽。

一般人或者團隊在這個時候柬帕，可能就開始優(yōu)化系統(tǒng)、優(yōu)化架構狡门、分拆業(yè)務了陷寝，因為這些是大家耳熟能詳也很拿手的動作。淘寶這個時候：換 Oracle 的原因除了它容量大其馏、穩(wěn)定凤跑、安全、性能高叛复，還有人才方面的原因仔引。

除了購買 Oracle，后來為了優(yōu)化褐奥，又買了更強大的存儲：

后來數(shù)據(jù)量變大了咖耘，本地存儲不行了。買了 NAS（Network Attached Storage撬码，網(wǎng)絡附屬存儲）儿倒，NetApp 的 NAS 存儲作為了數(shù)據(jù)庫的存儲設備，加上 Oracle RAC（Real Application Clusters呜笑，實時應用集群）來實現(xiàn)負載均衡夫否。

第一階段買的是“方案”，這個階段買的就是“性能”叫胁，這里架構設計和選擇主要遵循的還是“合適原則”和“簡單原則”慷吊。

3. 脫胎換骨的 Java 時代 1.0

淘寶切換到 Java 的原因很有趣，主要因為找了一個 PHP 的開源連接池 SQL Relay 連接到 Oracle曹抬，而這個代理經(jīng)常死鎖，死鎖了就必須重啟，而數(shù)據(jù)庫又必須用 Oracle谤民，于是決定換個開發(fā)語言堰酿。最后淘寶挑選了 Java，而且當時挑選 Java张足，也是請 Sun 公司的人触创，這幫人很歷害，先是將淘寶網(wǎng)站從 PHP 熱切換到了 Java为牍，后來又做了支付寶哼绑。

頻繁的死鎖和重啟對用戶業(yè)務產(chǎn)生了嚴重的影響，從業(yè)務的角度來看這是不得不解決的技術問題碉咆。

但這次淘寶為什么沒有去“買”呢抖韩？我們看最初選擇 SQL Relay 的原因：

但對于 PHP 語言來說，它是放在 Apache 上的疫铜，每一個請求都會對數(shù)據(jù)庫產(chǎn)生一個連接茂浮，它沒有連接池這種功能（Java 語言有 Servlet 容器，可以存放連接池）壳咕。那如何是好呢席揽？這幫人打探到 eBay 在 PHP 下面用了一個連接池的工具，是 BEA 賣給他們的谓厘。我們知道 BEA 的東西都很貴幌羞，我們買不起，于是多隆在網(wǎng)上尋尋覓覓竟稳，找到一個開源的連接池代理服務 SQL Relay属桦。

不清楚當時到底有多貴，Oracle 都可以買住练，連接池買不起 地啰？所以我個人感覺這次切換語言，更多是為以后業(yè)務發(fā)展做鋪墊讲逛，畢竟當時 PHP 語言遠遠沒有 Java 那么火亏吝、那么好招人。淘寶選擇 Java 語言的理由可以從側面驗證這點：

Java 是當時最成熟的網(wǎng)站開發(fā)語言盏混，它有比較良好的企業(yè)開發(fā)框架蔚鸥，被世界上主流的大規(guī)模網(wǎng)站普遍采用，另外有 Java 開發(fā)經(jīng)驗的人才也比較多许赃，后續(xù)維護成本會比較低止喷。

綜合來看，這次架構的變化沒有再簡單通過“買”來解決混聊，而是通過重構來解決弹谁，架構設計和選擇遵循了“演化原則”。

4. 堅若磐石的 Java 時代 2.0

Java 時代 2.0，淘寶做了很多優(yōu)化工作：數(shù)據(jù)分庫预愤、放棄 EJB沟于、引入 Spring、加入緩存植康、加入 CDN旷太、采用開源的 JBoss∠觯看起來沒有章法可循供璧，其實都是圍繞著提高容量、提高性能冻记、節(jié)約成本來做的睡毒。

就是“買”也搞不定了，此時的業(yè)務發(fā)展情況是這樣的：隨著數(shù)據(jù)量的繼續(xù)增長檩赢，到了 2005 年吕嘀，商品數(shù)有 1663 萬，PV 有 8931 萬贞瞒，注冊會員有 1390 萬偶房，這給數(shù)據(jù)和存儲帶來的壓力依然很大，數(shù)據(jù)量大军浆，性能就慢棕洋。

整個架構上去進行調整和優(yōu)化。比如說 Oracle 再強大乒融，在做 like 類搜索的時候掰盘，也不可能做到純粹的搜索系統(tǒng)如 Solr、Sphinx 等的性能赞季，因為這是機制決定的愧捕。

另外，隨著規(guī)模的增大申钩，純粹靠買的一個典型問題開始成為重要的考慮因素次绘，那就是成本。當買一臺兩臺 Oracle 的時候撒遣，可能對成本并不怎么關心邮偎，但如果要買 100 臺 Oracle，成本就是一個關鍵因素了义黎。這就是“量變帶來質變”的一個典型案例禾进，業(yè)務和系統(tǒng)發(fā)生質變后，架構設計遵循“演化原則”的思想廉涕，需要再一次重構甚至重寫泻云。

5.Java 時代 3.0 和分布式時代

Java 時代 3.0 我個人認為是淘寶技術飛躍的開始艇拍，商用轉為“自研”，典型的就是去 IOE 化宠纯。

分布式時代我認為是淘寶技術的修煉成功淑倾，到了這個階段，自研技術已經(jīng)自成一派征椒，除了支撐本身的海量業(yè)務，也開始影響整個互聯(lián)網(wǎng)的技術發(fā)展湃累。

到了這個階段勃救，業(yè)務規(guī)模急劇上升后，原來并不是主要復雜度的 IOE 成本開始成為了主要的問題治力，因此通過自研系統(tǒng)來降低 IOE 的成本蒙秒，去 IOE 也是系統(tǒng)架構的再一次演化。

手機 QQ

注：以下部分內容摘自《QQ 1.4 億在線背后的故事》宵统。

手機 QQ 的發(fā)展歷程按照用戶規(guī)脑谓玻可以粗略劃分為 4 個階段：十萬級、百萬級马澈、千萬級瓢省、億級，不同的用戶規(guī)模痊班，IM 后臺的架構也不同勤婚，而且基本上都是用戶規(guī)模先上去，然后產(chǎn)生各種問題涤伐，倒逼技術架構升級馒胆。

1. 十萬級 IM 1.X

最開始的手機 QQ 后臺是這樣的，可以說是簡單得不能再簡單凝果、普通得不能再普通的一個架構了祝迂，因為當時業(yè)務剛開始，架構設計遵循的是“合適原則”和“簡單原則”器净。

2. 百萬級 IM 2.X

隨著業(yè)務發(fā)展到 2001 年型雳，QQ 同時在線人數(shù)也突破了一百萬。第一代架構很簡單掌动，明顯不可能支撐百萬級的用戶規(guī)模四啰，主要的問題有：

以接入服務器的內存為例，單個在線用戶的存儲量約為 2KB粗恢，索引和在線狀態(tài)為 50 字節(jié)柑晒，好友表 400 個好友 × 5 字節(jié) / 好友 = 2000 字節(jié)，大致來說眷射，2GB 內存只能支持一百萬在線用戶匙赞。

CPU/ 網(wǎng)卡包量和流量 / 交換機流量等瓶頸佛掖。

單臺服務器支撐不下所有在線用戶 / 注冊用戶。

于是針對這些問題做架構改造涌庭，按照“演化原則”的指導進行了重構芥被，重構的方案相比現(xiàn)在來說也還是簡單得多，因此當時做架構設計時也遵循了“合適原則”和“簡單原則”坐榆。IM 2.X 的最終架構如圖所示拴魄。

3. 千萬級 IM 3.X

業(yè)務發(fā)展到 2005 年，QQ 同時在線人數(shù)突破了一千萬席镀。第二代架構支撐百萬級用戶是沒問題的匹中，但支撐千萬級用戶又會產(chǎn)生新問題，表現(xiàn)有：

同步流量太大豪诲，狀態(tài)同步服務器遇到單機瓶頸顶捷。

所有在線用戶的在線狀態(tài)信息量太大，單臺接入服務器存不下屎篱，如果在線數(shù)進一步增加服赎，甚至單臺狀態(tài)同步服務器也存不下。

單臺狀態(tài)同步服務器支撐不下所有在線用戶交播。

單臺接入服務器支撐不下所有在線用戶的在線狀態(tài)信息重虑。

針對這些問題，架構需要繼續(xù)改造升級堪侯，再一次“演化”嚎尤。IM 3.X 的最終架構如下圖，可以看到這次的方案相比之前的方案來說并不簡單了伍宦，這是業(yè)務特性決定的芽死。

4. 億級 IM 4.X

業(yè)務發(fā)展到 2010 年 3 月，QQ 同時在線人數(shù)過億次洼。第三代架構此時也不適應了关贵，主要問題有：

靈活性很差，比如“昵稱”長度增加一半卖毁，需要兩個月揖曾；增加“故鄉(xiāng)”字段，需要兩個月亥啦；最大好友數(shù)從 500 變成 1000炭剪，需要三個月。

無法支撐某些關鍵功能翔脱，比如好友數(shù)上萬奴拦、隱私權限控制、PC QQ 與手機 QQ 不可互踢届吁、微信與 QQ 互通错妖、異地容災绿鸣。

除了不適應，還有一個更嚴重的問題：

IM 后臺從 1.0 到 3.5 都是在原來基礎上做改造升級的暂氯，但是持續(xù)打補丁已經(jīng)難以支撐億級在線潮模，IM 后臺 4.0 必須從頭開始，重新設計實現(xiàn)痴施！

這里再次遵循了“演化原則”擎厢，決定重新打造一個這么復雜的系統(tǒng)，不得不佩服當時決策人的勇氣和魄力辣吃！

重新設計的 IM 4.0 架構如圖所示锉矢，和之前的架構相比，架構本身都拆分為兩個主要的架構：存儲架構和通信架構齿尽。

存儲架構

通信架構

小結

搜索一個互聯(lián)網(wǎng)大廠（BATJ、TMD 等）的架構發(fā)展案例灯节，分析一下其發(fā)展過程循头，看看哪些地方體現(xiàn)了這三條架構設計原則。