2012年11月15日新增章節（分布式時代：服務化），之前閱讀過的網友可直接進入第八頁。

引言

光棍節的狂歡

“時間到，開搶！”坐在電腦前早已等待多時的小美一看時間已到2011年11月11日零時，便迫不及待地投身于淘寶商城一年一度的大型網購促銷活動——“淘寶雙11購物狂歡節”。小美打開早已收藏好的寶貝——某品牌的雪地靴，飛快的點擊購買，付款，一回頭發現3000雙靴子已被搶購一空。

小美跳起來，大叫一聲“歐耶！”

小美不知道，就在11日零點過后的這一分鐘內，全國有342萬人和她一起涌入淘寶商城。當然，她更不知道，此時此刻，在淘寶杭州的一間辦公室里，燈火通明，這里是“戰時指揮部”，淘寶技術部的一群工程師，正在緊盯著網站的流量和交易數據。白板上是他們剛剛下的注，賭誰能最準確地猜中流量峰值和全天的交易總額。他們的手邊放著充足的食物和各類提神的飲料。

一陣急促的電話聲響起來，是前線部門詢問數據的，工程師大聲報著：“第1分鐘，進入淘寶商城的會員有342萬”。過一會工程師主動拿起電話：“交易額超過1億了，現在是第8分鐘。”接下來，“第21分鐘，剛突破2億”。“第32分鐘，3億了”。“第1個小時，4.39億”。這些數據隨后出現在微博上，引起一片驚呼。

“完蛋了！”突然有人大喝一聲，所有的眼睛都緊張的盯著他，只見他撓撓頭，嘿嘿的笑道“我賭的少了，20億輕松就能過了，我再加5億”，他跑去白板邊上把自己的賭注擦去，寫上25，接下來有人寫上28，有人寫上30，有人跑到微博上開下盤口，同事們紛紛轉載下注。接下來的這24個小時，戰時指揮部的工程師們都不能休息，他們盯著網站的各種監控指標，適時的調整機器和增減功能。頂住第一波高峰之后，這些人開始忙里偷閑的給自己買東西，大家互相交流著哪家買的移動硬盤靠譜，哪家衣服適合自己的女朋友，不時的有人哀嚎寶貝被人搶了、信用卡額度不夠了。同時，旁邊白板上的賭注越下越大。

[[65346]] 

11月11日，這個棍子最多的日子被網民自我調侃的變成了一個節日——“光棍節”。而淘寶網又用瘋狂的折扣促銷給它賦予了另外一個意義——“購物狂歡節”。2011年11月11日這一天，淘寶商城與淘寶網交易額之和突破52億，這個數字是“購物天堂”香港一天零售總額8.5億的6倍。

網民感受到的是瘋搶的喜悅，而網站的技術人員感受到的卻是“壓力山大”。就如同你家辦酒席，宴請左鄰右舍，這個辦起來容易。倘若宴請十里八鄉所有的人，吃飯的人自然開心，但卻不是一般人家能夠辦得起來的。能辦得起來如此盛宴者，需要強大的財力物力、組織能力、技術實力（例如做這么多菜，你的炒鍋一定要是“分布式的”、“可復制的”、“可擴展的”，洗菜切菜要有“工作流引擎”，上菜的路徑要用圖論來計算出來，甚至連廚房的下水道都要重新設計）。

淘寶能夠舉辦如此盛宴，網站的技術實力可見一斑。淘寶網擁有全國最大的hadoop分布式計算集群之一，日新增數據50TB，有40PB海量數據存儲。分布在全國各地80多個節點的CDN網絡，支持的流量超過800Gbps。淘寶的搜索引擎能夠對數十億的商品數據進行實時搜索，另外還擁有自主研發的文件存儲系統和緩存系統，以及java中間件和消息中間件系統，這一切組成了一個龐大的電子商務操作系統。另外從商業數據上來看，AMAZON的財報顯示2011年完成了大約 480億美金的交易額，EBAY2011年財報全年完成了大約600億美金的交易額（不包括其獨立的汽車交易平臺）。不管從交易額、商品數量、同比增速等指標上看，淘寶網均遠超于此，是目前全球最大的電子商務平臺。（由于淘寶非上市公司，未公布2011年業績，以上內容來自淘寶網技術副總裁@_行癲 的微博）

以上這些技術數據可能已經讓一些同學產生不適的感覺，為了讓更多的人讀懂這本書，我們從技術的角度來看，小美訪問淘寶網的時候，網站上發生了什么事情。下參考資料：《你剛才在淘寶上買了一件東西【技術普及帖】》，來自南京郵電大學孫放同學

 

為了有個更直觀的對比，我們說一個同行，他在2011年光棍節之前做促銷，流量上去之后，達到12Gbps（他們有這么大的流量，老板很高興，在微博上面說了這個數據），這時候流量達到了極限，網站幾乎掛掉，用戶無法下訂單。而淘寶網光棍節當天網絡的流量最高達到800多Gbps，帶給各家銀行和快遞公司的流量也讓他們壓力山大，如臨大敵（后來，他們以能夠撐住淘寶帶來的流量為榮而到處宣傳）。另外如果你在網上購買過火車票的話，更能體會到網站能支持多大的流量有多重要。但這不是一朝一夕做出來的，也不是有錢就能辦到的。

以上對比的這些網站，也許讀者很容易就猜到是哪一家，這里拿出來作對比，絕對沒有嘲笑人家的意思，采用通常的網站技術方案，能做到這種程度已經不錯了。任何網站的發展都不是一蹴而就的，在什么樣的階段采用什么樣的技術。在發展的過程中網站會遇到各種各樣的問題和業務帶來的壓力，正是這些原因才推動著技術的進步和發展，而技術的發展又會反過來促進業務的更大提升。二者互為因果，相互促進。如今淘寶網的流量已經是全球排名第12、國內排名第3（美國的ebay全球排名23，國內前兩名是百度和騰訊）。淘寶網的系統也從使用一臺服務器，到采用萬臺以上的服務器。本書就為大家描述淘寶網在整個發展過程中，所有的主動和被動的技術變革的前因后果，這由很多有趣的故事組成。

正如同很多人或組織成功了以后，就會為自己的出身編造一個美麗的傳說。淘寶網的出身，網上也有非常多的傳說，下面我們就從它的出生開始講起。

#p#

個人網站

2003年4月7日，馬云，在杭州，成立了一個神秘的組織。他叫來十位員工，要他們簽了一份協議，這份協議要求他們立刻離開阿里巴巴，去做一個神秘的項目。這個項目要求絕對保密，老馬戲稱“連說夢話被老婆聽到都不行，誰要是透漏出去，我將追殺到天涯海角”。這份協議是英文版的，匆忙之間，大多數人根本來不及看懂，但出于對老馬的信任，都卷起鋪蓋離開了阿里巴巴。

他們去了一個神秘的據點——湖畔花園小區的一套未裝修的房子里，房子的主人是馬云。這伙人剛進去的時候，馬云給他們布置了一個任務，就是在最短的時間內做出一個個人對個人（C2C）的商品交易的網站。現在出一個問題考考讀者，看你適不適合做淘寶的創業團隊。親，要是讓你來做，你怎么做？

在說出這個答案之前，容我先賣個關子，介紹一下這個創業團隊的成員：三個開發工程師（虛竹、三豐、多隆）、一個UED（二當家）、三個運營（小寶、阿珂、破天）、一個經理（財神）、還有就是馬云和他的秘書。當時對整個項目組來說壓力最大的就是時間，怎么在最短的時間內把一個從來就沒有的網站從零開始建立起來？了解淘寶歷史的人知道淘寶是在2003年5月10日上線的，這之間只有一個月。要是你在這個團隊里，你怎么做？我們的答案就是：買一個來。

買一個網站顯然比做一個網站要省事一些，但是他們的夢想可不是做一個小網站而已，要做大，就不是隨便買個就行的，要有比較低的維護成本，要能夠方便的擴展和二次開發。那接下來就是第二個問題：買一個什么樣的網站？答案是：輕量一點的，簡單一點的，于是買了這樣一個架構的網站：LAMP（linux+apache+mySQL+PHP）。這個直到現在還是一個很常用的網站架構模型。這種架構的優點是：無需編譯，發布快速，PHP功能強大，能做從頁面渲染到數據訪問所有的事情，而且用到的技術都是開源的，免費。

當時我們是從一個美國人那里買來的一個網站系統，這個系統的名字叫做PHPAuction（他們的官方網站 http://www.phpauction.net 這個名字很直白，一眼就看出來這個系統是用什么語言做的、是干什么用的），PHPAuction有好幾個版本，我們買的是最高版的，功能比較多，而且最重要的是對方提供了源代碼。最高版比較貴，花了我們2000美金（貌似現在降價了，只要946美元）。買來之后不是直接就能用的，需要很多本地化的修改，例如頁面模板改的漂亮一點，頁頭頁腳加上自己的站點簡介等，其中最有技術含量的是對數據庫進行了一個修改。原來是從一個數據庫進行所有的讀寫操作，拿過來之后多隆把它給拆分成一個主庫、兩個從庫，讀寫分離。這么做的好處有幾點：存儲容量增加了，有了備份，使得安全性增加了，讀寫分離使得讀寫效率提升了。這樣整個系統的架構就如下圖所示：

 

其中pear DB是一個PHP模塊，負責數據訪問層。另外也用開源的論壇系統PHPBB（ http://www.phpbbchina.com ）搭建了一個小的論壇社區，虛竹負責機器采購、配置、架設等，三豐和多隆負責編碼，他們把交易系統和論壇系統的用戶信息打通，給運營人員開發出后臺管理（admin系統）的功能，把交易類型從只有拍賣這一種增加為拍賣、一口價、求購商品、海報商品（意思是還沒推出的商品，先掛個海報出來）這四種。（PHPAuction只有拍賣的交易，Auction即拍賣的意思。@_行癲在微博中提到：今天eBay所有交易中拍賣交易仍然占了40%，而在中國，此種模式在淘寶幾乎從一開始就未能占據優勢，如今在主流的交易中幾乎可以忽略不計。背后的原因一直令人費解。我大致可以給出其中一種解釋，eBay基本在發達國家展開業務，制造業外包后，電子商務的基本群體大多只能表現為零散的個體間交易。）

在經歷了另外一些有趣的事情之后（這些有趣的事情包括“淘寶”這個名字的由來，員工花名的由來等等，由于本書主要描述技術方面的故事，對這些有興趣的可以去網上找），網站開始上線運行了。

 

 

在接下來的大半年時間里，這個網站迅速顯示出了它的生機。這里有必要提一下當時的市場環境，非典（SARS）的肆虐使得大家都不敢出門，尤其是去商場之類人多的地方。另外在神州大地上最早出現的C2C網站易趣也正忙的不亦樂乎，2002年3月，eBay以3000萬美元收購了易趣公司33%的股份，2003年6月以1.5億美元收購了易趣公司剩余67%的股份。當時淘寶網允許買賣雙方留下聯系方式，允許同城交易，整個操作過程簡單輕松。而eBay為了收取交易傭金，是禁止這么做的，這必然增加了交易過程的難度。而且eBay為了全球統一，把易趣原來的系統替換成了美國eBay的系統，用戶體驗一下子全變了，操作起來非常麻煩，這等于是把積累的用戶拱手送給了淘寶。為了不引起eBay的注意，淘寶網在2003年里一直聲稱自己是一個“個人網站”。由于這個創業團隊強大的市場開拓和運營能力，淘寶網發展的非常迅猛，2003年底就吸引了注冊用戶XXX，最高每日31萬PV，從5月到年底成交額4000萬。這沒有引起eBay的注意，卻引起了阿里巴巴內部很多員工的注意，他們覺得這個網站以后會成為阿里巴巴強勁的對手。甚至有人在內網發帖，忠告管理層要警惕這個剛剛起步的網站，但管理層似乎無動于衷。（這個團隊的保密工作做的真好）

在市場和運營的后方，淘寶網的技術團隊也在快速的做著系統的改進和創新。這里還有個有趣的故事，eBay和易趣早期都有員工在論壇上響應用戶的需求，eBay的論壇用粉紅色背景來區分員工的發言，易趣的員工在論壇上昵稱都選各種豆豆，例如黃豆豆、蠶豆豆等。淘寶在討論運營策略的時候提到這個問題，要求所有的員工都去論壇上回答用戶的問題。最早回答問題的任務落在小寶頭上，那我們用什么名字好呢？“淘淘”？“寶寶”？小寶都不滿意，太女性化了。討論了很久之后，小寶靈光乍現，干脆取個名字叫“小寶”吧，小寶帶七個老婆來開店，迎接各位客官，很有故事性。于是很多武俠小說中的人物開始在論壇中行俠仗義，這些昵稱下面標志著“淘寶店小二”，他們回答著各種各樣的問題，快速響應著用戶的各種需求。如果是技術上能解決的，幾個人商量一下，馬上就開發、測試、發布上線。反過來對比一下，易趣被eBay收購之后，系統更換成了全球通用的版本，響應用戶的一個需求需要層層審批，反應速度自然慢了下來。

當時淘寶第一個版本的系統里面已經包含了商品發布、管理、搜索、商品詳情、出價購買、評價投訴、我的淘寶這些功能（現在主流程中也是這些模塊。在2003年10月增加了一個功能節點：“安全交易”，這個是支付寶的雛形）。隨著用戶需求和流量的不斷增長，系統上面做了很多的日常改進，服務器由最初的一臺變成了三臺，一臺負責發送email、一臺負責運行數據庫、一臺負責運行webApp。過一段時間之后，商品搜索的功能占用數據庫資源太大了（用like搜索的，很慢），又從阿里巴巴中文站搬過來他們的搜索引擎iSearch，起初iSearch索引的文件放在硬盤上，隨著數據量的增長，又采購了NetApp服務器放置iSearch。

如此快節奏的工作，其實大家都累得不行，有人就提議大家隨時隨地的鍛煉身體，可是外面SARS橫行，在一個一百多方的房子里，怎么鍛煉呢？高挑美女阿珂提議大家練習提臀操，這個建議遭到男士的一致反對，后來虛竹就教大家練習倒立，這個大家都能接受。于是這個倒立的傳統一直延續至今，和花名文化、武俠文化一并傳承了下來。

隨著訪問量和數據量的飛速上漲，問題很快就出來了，第一個問題出現在數據庫上。mySQL當時是第4版的，我們用的是默認的存儲引擎myisam，這種類型讀數據的時候會把表鎖住（我們知道Oracle在寫數據的時候會有行鎖，讀數據的時候是沒有的），尤其是主庫往從庫上面寫數據的時候，會對主庫產生大量的讀操作，使得主庫性能急劇下降。這樣在高訪問量的時候，數據庫撐不住了。另外當年的mySQL不比如今的mySQL，在數據的容量和安全性方面也有很多先天的不足（和Oracle相比）。

#p#

Oracle/支付寶/旺旺

淘寶網作為個人網站發展的時間其實并不長，由于它太引人注目了，馬云在2003年7月就宣布了這個是阿里巴巴旗下的網站，隨后在市場上展開了很成功的運作。最著名的就是利用中小網站來做廣告，突圍eBay在門戶網站上對淘寶的廣告封鎖。上網比較早的人應該還記得那些在右下角的彈窗和網站腰封上一閃一閃的廣告。市場部那位到處花錢買廣告的家伙，太能花錢了，一出手就是幾百萬，他被我們稱為“大少爺”。

“大少爺”們做的廣告，帶來的就是迅速上漲的流量和交易量。在2003年底，MySQL已經撐不住了，技術的替代方案非常簡單，就是換成Oracle。換Oracle的原因除了它容量大、穩定、安全、性能高之外，還有人才方面的原因。在2003年的時候，阿里巴巴已經有一支很強大的DBA團隊了，有馮春培、汪海（七公）這樣的人物，后來還有馮大輝（@fenng）、陳吉平（拖雷）。這樣的人物牛到什么程度呢？Oracle給全球的技術專家頒發一些頭銜，其中最高級別的叫ACE（就是撲克牌的“尖兒”，夠大的吧），被授予這個頭銜的人目前全球也只有300多名（名單在這里： http://apex.oracle.com/pls/otn/f?p=19297:3 ），當年全球只有十幾名。有如此強大的技術后盾，把MySQL換成Oracle是順理成章的事情。

但更換數據庫不是只換個庫就可以的，訪問方式，SQL語法都要跟著變，最重要的一點是，Oracle并發訪問能力之所以如此強大，有一個關鍵性的設計——連接池。但對于PHP語言來說它是放在Apache上的，每一個請求都會對數據庫產生一個連接，它沒有連接池這種功能（java語言有servlet容器，可以存放連接池）。那如何是好呢？這幫人打探到eBay在PHP下面用了一個連接池的工具，是BEA賣給他們的。我們知道BEA的東西都很貴，我們買不起，于是多隆在網上尋尋覓覓，找到一個開源的連接池代理服務SQL Relay（ http://sourceforge.jp/projects/freshmeat_sqlrelay ），這個東西能夠提供連接池的功能，多隆對它進行了一些功能改進之后就拿來用了。這樣系統的架構就變成了如下的樣子：

 

數據一開始是放在本地的，DBA們對Oracle做調優的工作，也對SQL進行調優。后來數據量變大了，本地存儲不行了。買了NAS（Network Attached Storage：網絡附屬存儲），NetApp的NAS存儲作為了數據庫的存儲設備，加上Oracle RAC（real application clusters，實時應用集群）來實現負載均衡。七公說這實際上是走了一段彎路，NAS的NFS（Network File System）協議傳輸的延遲很嚴重，但那時侯不懂。后來采購了dell和EMC合作的SAN低端存儲，性能一下子提升了10幾倍，這才比較穩定了。再往后來數據量更大了，存儲的節點一拆二、二拆四，RAC又出問題了。這才踏上了購買小型機的道路。在那段不穩定的時間里，七公曾經在機房住了5天5夜。

替換完數據庫，時間到了2004年春天，俗話說“春宵一刻值千金”，但這些人的春宵卻不太好過了。他們在把數據的連接放在SQL Relay之后就噩夢不斷，這個代理服務經常會死鎖，如同之前的MySQL死鎖一樣。雖然多隆做了很多修改，但當時那個版本內部處理的邏輯不對，問題很多，唯一解決的辦法就是“重啟”它的服務。這在白天還好，連接上機房的服務器，把進程殺掉，然后開啟就可以了，但是最痛苦的是它在晚上也要死掉，于是工程師們不得不24小時開著手機，一旦收到“SQL Relay進程掛起”的短信，就從春夢中醒來，打開電腦，連上機房，重啟服務。后來干脆每天睡覺之前先重啟一下。做這事最多的據說是三豐，他現在是淘寶網的總裁。現在我們知道，任何牛B的人物，都有一段苦B的經歷。

微博上有人說“好的架構是進化來的，不是設計來的”。的確如此，其實還可以再加上一句“好的功能也是進化來的，不是設計來的”。在架構的進化過程中，業務的進化也非常迅猛。最早的時候，買家打錢給賣家都是通過銀行轉賬匯款，有些騙子收了錢卻不發貨，這是一個很嚴重的問題。然后這伙人研究了paypal的支付方式，發現也不能解決問題。后來這幾個聰明的腦袋又想到了“擔保交易”這種第三方托管資金的辦法。于是在2003年10月，淘寶網上面上線了一個功能，叫做“安全交易”，賣家選擇支持這種功能的話，買家會把錢交給淘寶網，等他收到貨之后，淘寶網再把錢給賣家。這就是現在的支付寶，在前兩天（2012.2.21）年會上，支付寶公布2011年的交易筆數已經是paypal的兩倍。這個劃時代的創新，其實就是在不斷的思索過程中的一個靈光乍現。

當時開發“安全交易”功能的是茅十八和他的徒弟苗人鳳（茅十八開發到一半去上海讀MBA去了，苗人鳳現在是支付寶的首席業務架構師），開發跟銀行網關對接的功能的是多隆。當時多數銀行的網站已經支持在線支付了，但多隆告訴我，他們的網關五花八門，用什么技術的都有，必須一家一家去接。而且他們不保證用戶付錢了就一定扣款成功、不保證扣款成功了就一定通知淘寶、不保證通知淘寶了就一定能通知到、不保證通知到了就不重復通知。這害苦了苗人鳳，他必須每天手工核對賬單，對不齊的話就一定是有人的錢找不到地方了，少一分錢都睡不著覺。另外他為了測試這些功能，去杭州所有的銀行都辦理了一張銀行卡。一堆銀行卡擺在桌子上，不知道的人還以為這個家伙一定很有錢，其實里面都只是十塊八塊的。現在我們再一次知道，任何牛B的人物，都必須有一段苦B的經歷。

有人說淘寶打敗易趣（eBay中國）是靠免費，其實這只是原因之一。如果說和易趣過招第一招是免費的話，這讓用戶沒有門檻就愿意來，那第二招就是“安全支付”，這讓用戶放心付款，不必擔心被騙。在武俠小說中真正的高手飛花摘葉即可傷人，他們不會局限于一招兩招，一旦出手，連綿不絕。而淘寶的第三招就是“旺旺”。其實淘寶旺旺也不是自己生出來的，是從阿里巴巴的“貿易通”復制過來的。從2004年3月開始，“叮咚、叮咚”這個經典的聲音就回蕩在所有淘寶買家和賣家的耳邊，“親，包郵不？” “親，把零頭去掉行不？”這親切的砍價聲造就了后來的“淘寶體”。有人說中國人就是愛砍價，雖然筆者體會不到砍價成功后有多少成就感，但每次我去菜市場，看到大媽們砍價砍得天昏地暗，那滿足的勁頭堪比撿到了錢，我就深刻的理解了淘寶旺旺在交易過程中的價值。我猜eBay也體會不到砍價的樂趣，他們一直不允許買賣雙方在線聊天，收購了skype之后也沒有用到電子商務中去。

旺旺在推出來沒多久，就惹了一個法律方面的麻煩。有個做雪餅的廠家找上門來，說我們侵權了，他們家的雪餅很好吃，牛奶也做得不錯，我們都很喜歡。然后我們就在旺旺的前面加了兩個字，叫做“淘寶旺旺”。在那個野蠻生長的階段，其實很多產品都是想到什么就做什么，例如我們還搭建過一個聊天室，但似乎淘寶網不是一個閑聊的地方，這個聊天室門可羅雀，一段時間后就關閉掉了。

SQL Relay的問題搞得三豐他們很難睡個囫圇覺，那一年開半年會的時候，公司特地給三豐頒了一個獎項，對他表示深切的安慰。但不能總這樣啊，于是，2004年的上半年開始，整個網站就開始了一個脫胎換骨的手術。

#p#

我的師父黃裳@岳旭強曾經說過，“好的架構圖充滿美感”，一個架構好不好，從審美的角度就能看得出來。后來我看了很多系統的架構，發現這個言論基本成立。那么反觀淘寶前面的兩個版本的架構，你看哪個比較美？

 

 

顯然第一個比較好看，后面那個顯得頭重腳輕，這也注定了它不是一個穩定的版本，只存活了不到半年的時間。2004年初，SQL Relay的問題解決不了，數據庫必須要用Oracle，那從哪里動刀？只有換開發語言了。換什么語言好呢？Java。Java是當時最成熟的網站開發語言，它有比較良好的企業開發框架，被世界上主流的大規模網站普遍采用，另外有Java開發經驗的人才也比較多，后續維護成本會比較低。

到2004年上半年，淘寶網已經運行了一年的時間，這一年積累了大量的用戶，也快速的開發了很多功能，當時這個網站已經很龐大了，而且新的需求還在源源不斷的過來。把一個龐大的網站的開發語言換掉，無異于脫胎換骨，在換的過程中還不能拖慢業務的發展，這無異于邊換邊跑，對時間和技術能力的要求都非常高。做這樣的手術，需要請第一流的專家來主刀。現在再考一下讀者，如果你在這個創業團隊里面，請什么樣的人來做這事？我們的答案是請Sun的人。沒錯，就是創造Java語言的那家公司，世界上沒有比他們更懂Java的了。除此之外，還有一個不為人知的原因，……（此處和諧掉200字，完整版見aliway）

這幫Sun的工程師的確很強大，在筆者2004年底來淘寶的時候，他們還在，有幸跟他們共事了幾個月。現在擺在他們面前的問題是用什么辦法把一個龐大的網站從PHP語言遷移到Java？而且要求在遷移的過程中，不停止服務，原來系統的bugfix和功能改進不受影響。親，你要是架構師，你怎么做？有人的答案是寫一個翻譯器，如同把中文翻譯成英文一樣，自動翻譯。我只能說你這個想法太超前了，換個說法就是“too simple, sometimes naive”。當時沒有，現在也沒有人能做到。他們的大致方案是給業務分模塊，一個模塊一個模塊的替換。如用戶模塊，老的member.taobao.com繼續維護，不添加新功能，新的功能先在新的模塊上開發，跟老的共用一個數據庫，開發完畢之后放到不同的應用集群上，另開個域名member1.taobao.com，同時替換老的功能，替換一個把老的模塊上的功能關閉一個，逐漸的把用戶引導到member1.taobao.com，等所有功能都替換完畢之后，關閉member.taobao.com。后來很長時間里面都是在用member1這樣奇怪的域名，兩年后有另外一家互聯網公司開始做電子商務了，我們發現他們的域名也叫member1.xx.com、auction1.xx.com……

說了開發模式，再說說用到的Java MVC框架，當時的struts1.x是用的比較多的框架，但是用過webwork和struts2的同學可能知道，struts1.x在多人協作方面有很多致命的弱點，由于沒有一個輕量框架作為基礎，因此很難擴展，這樣架構師對于基礎功能和全局功能的控制就很難做到。而阿里巴巴的18個創始人之中，有個架構師，在Jakarta Turbine的基礎上，做了很多擴展，打造了一個阿里巴巴自己用的MVC框架WebX （ http://www.openwebx.org/docs/Webx3_Guide_Book.html ），這個框架易于擴展，方便組件化開發，它的頁面模板支持JSP和velocity等、持久層支持ibatis和hibernate等、控制層可以用EJB和Spring（Spring是后來才有的）。項目組選擇了這個強大的框架，這個框架如果當時開源了，也許就沒有webwork和struts2什么事了。另外，當時Sun在全世界大力推廣他們的EJB，雖然淘寶的架構師認為這個東東用不到，但他們還是極力堅持。在經歷了很多次的技術討論、爭論和爭吵之后，這個系統的架構就變成了下圖的樣子：

 

Java應用服務器是Weblogic，MVC框架是WebX、控制層用了EJB、持久層是ibatis，另外為了緩解數據庫的壓力，商品查詢和店鋪查詢放在搜索引擎上面。這個架構圖是不是好看了一點了，親？

這幫Sun的工程師開發完淘寶的網站之后，又做了一個很牛的網站，叫“支付寶”。

其實在任何時候，開發語言本身都不是系統的瓶頸，業務帶來的壓力更多的是壓到了數據和存儲上。上面一篇也說到，MySQL撐不住了之后換Oracle，Oracle的存儲一開始在本機上，后來在NAS上，NAS撐不住了用EMC的SAN存儲，再然后Oracle的RAC撐不住了，數據的存儲方面就不得不考慮使用小型機了。在2004年的夏天，DBA七公、測試工程師郭芙和架構師行癲，踏上了去北京測試小型機的道路。他們帶著小型機回來的時候，我們像歡迎領袖一樣的歡迎他們，因為那個是我們最值錢的設備了，價格表上的數字嚇死人。小型機買回來之后我們爭相合影，然后Oracle就跑在了小型機上，存儲方面從EMC低端cx存儲到Sun oem hds高端存儲，再到EMC dmx高端存儲，一級一級的往上跳。

到現在為止，我們已經用上了IBM的小型機、Oracle的數據庫、EMC的存儲，這些東西都是很貴的，那些年可以說是花錢如流水啊。有人說過“錢能解決的問題，就不是問題”，但隨著淘寶網的發展，在不久以后，錢已經解決不了我們的問題了。花錢買豪華的配置，也許能支持1億PV的網站，但淘寶網的發展實在是太快了，到了10億怎么辦？到了百億怎么辦？在N年以后，我們不得不創造技術，解決這些只有世界頂尖的網站才會遇到的問題。后來我們在開源軟件的基礎上進行自主研發，一步一步的把IOE（IBM小型機、Oracle、EMC存儲）這幾個“神器”都去掉了。這就如同在《西游記》里面，妖怪們拿到神仙的兵器會非常厲害，連猴子都能夠打敗，但最牛的神仙是不用這些神器的，他們揮一揮衣袖、翻一下手掌就威力無比。去IOE這一部分會在最后一個章節里面講，這里先埋個千里伏筆。

欲知后事如何，且聽下回分解。

#p#

已經有讀者在迫不及待的問怎么去掉了IOE，別急，在去掉IOE之前還有很長的路要走。行癲他們買回來小型機之后，我們用上了Oracle，七公帶著一幫DBA在優化SQL和存儲，行癲帶著幾個架構師在研究數據庫的擴展性。Oracle本身是一個封閉的系統，用Oracle怎么做擴展？用現在一個時髦的說法就是做“分庫分表”。

我們知道一臺Oracle的處理能力是有上限的，它的連接池有數量限制，查詢速度跟容量成反比。簡單的說，在數據量上億、查詢量上億的時候，就到它的極限了。要突破這種極限，最簡單的方式就是多用幾個Oracle數據庫。但一個封閉的系統做擴展，不像分布式系統那樣輕松。我們把用戶的信息按照ID來放到兩個數據庫里面（DB1/DB2），把商品的信息跟著賣家放在兩個對應的數據庫里面，把商品類目等通用信息放在第三個庫里面(DBcommon)。這么做的目的除了增加了數據庫的容量之外，還有一個就是做容災，萬一一個數據庫掛了，整個網站上還有一半的數據能操作。

數據庫這么分了之后，應用程序有麻煩了，如果我是一個買家，買的商品有DB1的也有DB2的，要查看“我已買到的寶貝”的時候，應用程序怎么辦？必須到兩個數據庫里面分別查詢出來對應的商品。要按時間排序怎么辦？兩個庫里面“我已買到的寶貝”全部查出來在應用程序里面做合并。還有分頁怎么處理？關鍵字查詢怎么處理？這些東西交給程序員來做的話會很悲催，于是行癲在淘寶的第一個架構上的作品就來解決了這個問題，他寫了一個數據庫路由的框架DBRoute，這個框架在淘寶的Oracle時代一直在使用。后來隨著業務的發展，這種分庫的第二個目的——容災的效果就沒有達到。像評價、投訴、舉報、收藏、我的淘寶等很多地方，都必須同時連接DB1和DB2，哪個庫掛了都會導致整個網站掛掉。

上一篇說過，采用EJB其實是和Sun的工程師妥協的結果，在他們走了之后，EJB也逐漸被冷落了下來。在05、06年的時候，spring大放異彩，正好利用spring的反射（IoC）模式替代了EJB的工廠模式，給整個系統精簡了很多代碼。

上一篇還說過，為了減少數據庫的壓力，提高搜索的效率，我們引入了搜索引擎。隨著數據量的繼續增長，到了2005年，商品數有1663萬，PV有8931萬，注冊會員有1390萬，這給數據和存儲帶來的壓力依然山大，數據量大，性能就慢。親，還有什么辦法能提升系統的性能？一定還有招數可以用，這就是緩存和CDN（內容分發網絡）。

你可以想象，九千萬的訪問量，有多少是在商品詳情頁面？訪問這個頁面的時候，數據全都是只讀的（全部從數據庫里面讀出來，不寫入數據庫），如果把這些讀操作從數據庫里面移到內存里，數據庫將會多么的感激涕零。在那個時候我們的架構師多隆大神，找到了一個基于 Berkeley DB 的開源的緩存系統，把很多不太變動的只讀信息放了進去。其實最初這個緩存系統還比較弱，我們并沒有把整個商品詳情都放在里面，一開始把賣家的信息放里面，然后把商品屬性放里面，商品詳情這個字段太大，放進去受不了。說到商品詳情，這個字段比較恐怖，有人統計過，淘寶商品詳情打印出來平均有5米長，在系統里面其實放在哪里都不招人待見。筆者清楚的記得，我來淘寶之后擔任項目經理做的第一個項目就是把商品詳情從商品表里面給移出來。這個字段太大了，查詢商品信息的時候很多都不需要查看詳情，它跟商品的價格、運費這些放在一個表里面，拖慢了整個表的查詢速度。在05年的時候，我把商品詳情放在數據庫的另外一張表里面，再往后這個大字段被從數據庫里面請了出來，這也讓數據庫再一次感激涕零。

到現在為止，整個商品詳情的頁面都在緩存里面了，眼尖的讀者可能會發現現在的商品詳情不全是“只讀”的信息了，這個頁面上有個信息叫“瀏覽量”，這個數字每刷新一次頁面就要“寫入”數據庫一次，這種高頻度實時更新的數據能用緩存嗎？如果不用緩存，一天幾十億的寫入，數據庫會怎么樣？一定會掛掉。那怎么辦？親……

 

CDN這個工作相對比較獨立，跟別的系統一樣，一開始我們也是采用的商用系統。后來隨著流量的增加，商用的系統已經撐不住了，LVS的創始人章文嵩博士帶人搭建了淘寶自己的CDN網絡。在本文的引言中我說過淘寶的CDN系統支撐了800Gbps以上的流量，作為對比我們可以看一下國內專業做CDN的上市公司ChinaCache的介紹——“ChinaCache……是中國第一的專業CDN服務提供商，向客戶提供全方位網絡內容快速分布解決方案。作為首家獲信產部許可的CDN服務提供商，目前ChinaCache在全國50多個大中城市擁有近300個節點，全網處理能力超過500Gbps，其CDN網絡覆蓋中國電信、中國網通、中國移動、中國聯通、中國鐵通和中國教育科研網等各大運營商。”——這樣你可以看得出淘寶在CDN上面的實力，這在全世界都是數一數二的。另外因為CDN需要大量的服務器，要消耗很多能源（消耗多少？在前兩年我們算過一筆帳，淘寶上產生一個交易，消耗的電足以煮熟4個雞蛋）。這兩年章文嵩的團隊又在研究低功耗的服務器，在綠色計算領域也做了很多開創性的工作。淘寶CDN的發展需要專門一個章節來講，想先睹為快的可以看一下筆者對章文嵩的專訪：http://qing.weibo.com/1866752224/6f4460e033000jme.html

回想起剛用緩存那段時間，筆者還是個小菜鳥，有一個經典的錯誤常常犯，就是數據庫的內容更新的時候，忘記通知緩存系統，結果在測試的時候就發現我改過的數據怎么在頁面上沒變化呢。后來做了一些頁面上的代碼，修改CSS和JS的時候，用戶本地緩存的信息沒有更新，頁面上也會亂掉，在論壇上被人說的時候，我告訴他用ctrl+F5刷新頁面，然后趕緊修改腳本文件的名稱，重新發布頁面。學會用ctrl+F5的會員對我佩服的五體投地，我卻慚愧的無地自容。

有些技術的發展是順其自然的，有些卻是突如其來的。到2007年的時候，我們已經有幾百臺應用服務器了，這上面的java應用服務器是weblogic，而weblogic是非常貴的，比這些服務器本身都貴。有一段時間多隆研究了一下jboss，說我們換掉weblogic吧，于是又省下了不少銀兩。那一年，老馬舉辦了第一屆的“網俠大會”，會上來的大俠中有一位是上文提到的章文嵩，還有一位曾經在jboss團隊工作，我們也把這位大俠留下了，這樣我們用起jboss更加有底氣了。

這些雜七雜八的修改，我們對數據分庫、放棄EJB、引入Spring、加入緩存、加入CDN、采用開源的Jboss，看起來沒有章法可循，其實都是圍繞著提高容量、提高性能、節約成本來做的，由于這些不算大的版本變遷，我們姑且叫它2.1版吧，這個版本從構圖上來看有3只腳，是不是穩定了很多？

架構圖如下：

 

 

#p#

在講淘寶文件系統TFS之前，先回顧一下上面幾個版本。1.0版的PHP系統運行了將近一年的時間（2003.05-2004.01）；后來數據庫變成Oracle之后（2004.01-2004.05，叫1.1版本吧），不到半年就把開發語言轉換為Java系統了（2004.02-2005.03，叫2.0版本）；進行分庫、加入緩存、CDN之后我們叫它2.1版本（2004.10-2007.01）。這中間有些時間的重合，因為很多架構的演化并沒有明顯的時間點，它是逐步進化而來的。

在描述2.1版本的時候我寫的副標題是“堅若磐石”，這個“堅若磐石”是因為這個版本終于穩定下來了，在這個版本的系統上，淘寶網運行了兩年多的時間。這期間有很多優秀的人才加入，也開發了很多優秀的產品，例如支付寶認證系統、招財進寶項目、淘寶旅行、淘寶彩票、淘寶論壇等等。甚至在團購網站風起云涌之前，淘寶網在2006年就推出了團購的功能，只是淘寶網最初的團購功能是買家發起的，達到賣家指定的數量之后，享受比一口價更低的價格，這個功能看起來是結合了淘寶一口價和荷蘭拍的另一種交易模式，但不幸沒有支撐下去。

在這些產品和功能的最底層，其實還是商品的管理和交易的管理這兩大功能。這兩大功能在2.1版本里面都有很大的變化。商品的管理起初是要求賣家選擇7天到期還是14天到期，到期之后就要下架，必須重新發布才能上架，上架之后就變成了新的商品信息（ID變過了）。另外如果這個期間內成交了，之后再有新貨，必須發布一個新的商品信息。這么做有幾個原因，一是參照拍賣商品的時間設置，要在某日期前結束掛牌；二是搜索引擎不知道同樣的商品哪個排前面，那就把掛牌時間長的排前面，這樣就必須在某個時間把老的商品下架掉，不然它老排在前面；第三是成交信息和商品ID關聯，這個商品如果多次編輯還是同一個ID的話，成交記錄里面的商品信息會變來變去；還有一個不為人知的原因，我們的存儲有限，不能讓所有的商品老存放在主庫里面。這種處理方式簡單粗暴，但還算是公平。不過這樣很多需求都無法滿足，例如同樣的商品，我上一次銷售的時候很多好評都沒法在下一個商品上體現出來；再例如我買過的商品結束后只看到交易的信息，不知道賣家還有沒有再賣了。后來基于這些需求，我們在2006年下半年把商品和交易拆開。一個商家的一種商品有個唯一的ID，上下架都是同一個商品。那么如果賣家改價格、庫存什么的話，已成交的信息怎么處理？那就在買家每交易一次的時候，都記錄下商品的快照信息，有多少次交易就有多少個快照。這樣買賣雙方比較爽了，給系統帶來了什么？存儲的成本大幅度上升了！

存儲的成本高到什么程度呢？數據庫方面提到過用了IOE，一套下來就是千萬級別的，那幾套下來就是⋯⋯。另外淘寶網還有很多文件需要存儲，我們有哪些文件呢？最主要的就是圖片、商品描述、交易快照，一個商品要包含幾張圖片和一長串的描述信息，而每一張圖片都要生成幾張規格不同的縮略圖。在2010年，淘寶網的后端系統上保存著286億個圖片文件。圖片在交易系統中非常重要，俗話說“一張好圖勝千言”、“無圖無真相”，淘寶網的商品照片，尤其是熱門商品，圖片的訪問流量是非常大的。淘寶網整體流量中，圖片的訪問流量要占到90%以上。且這些圖片平均大小為17.45KB，小于8K的圖片占整體圖片數量61%，占整體系統容量的11%。這么多的圖片數據、這么大的訪問流量，給淘寶網的系統帶來了巨大的挑戰。眾所周知，對于大多數系統來說，最頭疼的就是大規模的小文件存儲與讀取，因為磁頭需要頻繁的尋道和換道，因此在讀取上容易帶來較長的延時。在大量高并發訪問量的情況下，簡直就是系統的噩夢。我們該怎么辦？

同樣的套路，在某個規模以下，采用現有的商業解決方案，達到某種規模之后，商業的解決方案無法滿足，只有自己創造解決方案了。對于淘寶的圖片存儲來說，轉折點在2007年。這之前，一直采用的商用存儲系統，應用NetApp公司的文件存儲系統。隨著淘寶網的圖片文件數量以每年2倍(即原來3倍)的速度增長，淘寶網后端NetApp公司的存儲系統也從低端到高端不斷遷移，直至2006年，即使是NetApp公司最高端的產品也不能滿足淘寶網存儲的要求。從2006年開始，淘寶網決定自己開發一套針對海量小文件存儲的文件系統，用于解決自身圖片存儲的難題。這標志著淘寶網從使用技術到了創造技術的階段。

2007年之前的圖片存儲架構如下圖：

 

 

章文嵩博士總結了幾點商用存儲系統的局限和不足:

首先是商用的存儲系統沒有對小文件存儲和讀取的環境進行有針對性的優化；其次，文件數量大，網絡存儲設備無法支撐；另外，整個系統所連接的服務器也越來越多，網絡連接數已經到達了網絡存儲設備的極限。此外，商用存儲系統擴容成本高，10T的存儲容量需要幾百萬，而且存在單點故障，容災和安全性無法得到很好的保證。

談到在商用系統和自主研發之間的經濟效益對比，章文嵩博士列舉了以下幾點經驗：

1.商用軟件很難滿足大規模系統的應用需求，無論存儲還是CDN還是負載均衡，因為在廠商實驗室端，很難實現如此大的數據規模測試。

2.研發過程中，將開源和自主開發相結合，會有更好的可控性，系統出問題了，完全可以從底層解決問題，系統擴展性也更高。

 

 

3.在一定規模效應基礎上，研發的投入都是值得的。上圖是一個自主研發和購買商用系統的投入產出比對比，實際上，在上圖的交叉點左邊，購買商用系統都是更加實際和經濟性更好的選擇，只有在規模超過交叉點的情況下，自主研發才能收到較好的經濟效果。實際上，規模化達到如此程度的公司其實并不多，不過淘寶網已經遠遠超過了交叉點。

4.自主研發的系統可在軟件和硬件多個層次不斷的優化。

歷史總是驚人的巧合，在我們準備研發文件存儲系統的時候，google走在了前面，2007年他們公布了GFS（ google file system ）的設計論文，這給我們帶來了很多借鑒的思路。隨后我們開發出了適合淘寶使用的圖片存儲系統TFS（ taobao file system ）。3年之后，我們發現歷史的巧合比我們想象中還要神奇，幾乎跟我們同時，中國的另外一家互聯網公司也開發了他們的文件存儲系統，甚至取的名字都一樣——TFS，太神奇了！（猜猜是哪家？）

2007年6月，TFS正式上線運營。在生產環境中應用的集群規模達到了200臺PC Server(146G*6 SAS 15K Raid5)，文件數量達到上億級別；系統部署存儲容量：140TB；實際使用存儲容量： 50TB；單臺支持隨機IOPS 200+，流量3MBps。

要講TFS的系統架構，首先要描述清楚業務需求，淘寶對圖片存儲的需求大概可以描述如下：

文件比較小；并發量高；讀操作遠大于寫操作；訪問隨機；沒有文件修改的操作；要求存儲成本低；能容災能備份。應對這種需求，顯然要用分布式存儲系統；由于文件大小比較統一，可以采用專有文件系統；并發量高，讀寫隨機性強，需要更少的IO操作；考慮到成本和備份，需要用廉價的存儲設備；考慮到容災，需要能平滑擴容。

參照GFS并做了適度的優化之后，TFS1.0版的架構圖如下：

 

 

從上面架構圖上看：集群由一對Name Server和多臺Data Server構成，Name Server 的兩臺服務器互為雙機，就是集群文件系統中管理節點的概念。

在這個架構中：

• 每個Data Server運行在一臺普通的Linux主機上
• 以block文件的形式存放數據文件(一般64M一個block)
• block存多份保證數據安全
• 利用ext3文件系統存放數據文件
• 磁盤raid5做數據冗余
• 文件名內置元數據信息，用戶自己保存TFS文件名與實際文件的對照關系–使得元數據量特別小。

淘寶TFS文件系統在核心設計上最大的取巧的地方就在，傳統的集群系統里面元數據只有1份，通常由管理節點來管理，因而很容易成為瓶頸。而對于淘寶網的用戶來說，圖片文件究竟用什么名字來保存實際上用戶并不關心，因此TFS在設計規劃上考慮在圖片的保存文件名上暗藏了一些元數據信息，例如圖片的大小、時間、訪問頻次等等信息，包括所在的邏輯塊號。而在元數據上，實際上保存的信息很少，因此元數據結構非常簡單。僅僅只需要一個fileID，能夠準確定位文件在什么地方。

由于大量的文件信息都隱藏在文件名中，整個系統完全拋棄了傳統的目錄樹結構，因為目錄樹開銷最大。拿掉后，整個集群的高可擴展性極大提高。實際上，這一設計理念和目前業界的“對象存儲”較為類似，淘寶網TFS文件系統已經更新到1.3版本，在生產系統的性能已經得到驗證，且不斷得到了完善和優化，淘寶網目前在對象存儲領域的研究已經走在前列。

在TFS上線之前，淘寶網每個商品只允許上傳一張圖片，大小限定在120K之內，在商品詳情里面的圖片必須使用外站的服務。那時侯發布一件商品確實非常麻煩，筆者曾經想賣一臺二手電腦，先把照片上傳到google相冊，在發布到淘寶網之后發現google相冊被墻了，我的圖片別人看不到，當時郁悶的不行。TFS上線后，商品展示圖片開放到5張，商品描述里面的圖片也可以使用淘寶的圖片服務，到現在為止，淘寶網給每個用戶提供了1G的圖片空間，這下大家都滿足了。技術和業務就是這么互相用力的推動著，業務滿足不了的時候，技術必須創新，技術創新之后，業務有了更大的發展空間。

1.3版本的架構見阿里味（阿里巴巴內網）⋯⋯

#p#

Tair

TFS 的開發，讓淘寶的圖片功能得到了充分的發揮。同 TFS 一樣，很多技術都是在產品的推動下得到發展的。在講下面的技術之前，有必要說說那些年，我們一起做過的幾個產品。

先說個比較悲劇的——【團購】，這個團購可不是現在滿大街掛的那種 groupon 類型的模式，在 groupon 出生之前，在 2006 年，淘寶的產品經理一燈就提出了“團購”這種產品。一燈最初的設想是讓買家在社區發起團購，“團長”找到足夠的人之后，去跟賣家砍價，這類似于現在蘑菇街的“自由團”。但由于種種原因，在開發的時候產品的功能做了裁剪，跟最初的設想比起來偏離了一點，變成了讓賣家設置團購價，在買家達到指定的數量之后，以團購價成交。這個功能看起來是結合了淘寶一口價和荷蘭拍的另一種交易模式，但不幸沒有支撐下去，這種交易方式最大的弱點就是讓買家看到了賣家的底牌，即便達不到團購的數量，他們也往團購的價格上砍。當時為了引流量，淘寶網開辟了團購專區，實誠的賣家在達不到團購數量的時候，被砍價砍虧了，狡猾的賣家干脆提高原價，利用這個專區做促銷。在接下來的兩年里這個產品淪落成了促銷工具（話說現在滿大街的團購，其實也就是促銷）。這個產品，讓研發人員對“產品”這個概念有了深刻的認識。

再說一個更加悲劇的——【我的淘寶】，我的淘寶是給會員管理自己的商品、交易、收貨地址、評價、投訴的地方，這個地方由于登錄之后才能看到，所以風格跟外面完全不一樣，很長時間都沒有優化過，樣子丑，用戶操作也不方便，如果一個人有很多商品，上下架需要一個一個的操作，非常麻煩（想想那些賣書的）。這時候一個重要人物登場了，承志（現在的蘑菇街 CEO，他讓我把他描寫的帥一點），他給我們演示了最牛叉的前端交互技術，就是 Gmail 上那種 Ajax 的交互方式，可以拖動、可以用右鍵、可以組合鍵選擇、操作完畢還不刷新頁面，管理商品如有神助，帥呆了。我是這個項目的項目經理，一燈是產品經理，我們再拉上萬劍和一伙工程師就開搞了。熱火朝天的干了三個月，快要完成的時候，老馬不知道怎么回事突然出現在我身后，看我操作了一遍新版我的淘寶之后，問我這是不是客戶端軟件，我說是網頁，他抓狂了，說這跟客戶端軟件一樣，鏈接底下連線都木有，上下架用文件夾表示，我都不知道怎么操作了，賣家肯定也不會玩。

老馬果然是神一樣的人物，他說的應驗了，淘寶歷史上第一個群體性事件爆發了，試用完新版本的我的淘寶之后，很多賣家憤怒了，說不會玩。一燈就和承志一起商量怎么把頁面改得像個網頁一點，改了半個月，憤怒依然沒有平息。我很無奈地看著這兩個人在那里堅持，然后跟老板們商量怎么辦。后來我們用了一個很挫的方法給自己一個臺階，到論壇上讓大家投票要不要使用新版我的淘寶，投票結果是一半以上的反對。于是這么十來個人做了 3 個月的系統被殺掉了。這讓我非常沮喪，但最痛苦的還不是這個，我們下線之后，另外一撥賣家不滿了，說這么好的功能怎么沒有了？啊~~~你們怎么不早點站出來，親？這個產品帶給我們的是新技術（Ajax、YUI 前端框架）的嘗試，還有就是新技術對用戶操作習慣的改變，一定要慎之又慎。另外還有一點沒有總結好的教訓，就是應對群體事件的時候，我們手足無措，在后來【招財進寶】和淘寶商城出現群體性事件的時候，我發現悲劇在重演。

說到【招財進寶】，這個是最悲劇的產品。到 2006 年五一的時候，一個劃時代的項目啟動了（我苦逼的連續失去了兩個五一節，前面一個是 2005 年做支付寶系統）。財神說要用最好的項目陣容，我被選中了，這一下子讓我覺得我能劃分到最好的員工之類，在【我的淘寶】這個產品中嚴重受傷的心又痊愈了。這是一個商品 P4P 的系統，就是按成交付費。我們認為已經有很多賣家有錢了，但淘寶上這么多的商品，他們很難被找到，賣家愿意花錢讓商品排在前面。我們允許賣家購買廣告位，把他的商品按一定算法給個排名（類似于百度的競價排名，但不僅僅看他出了多少錢，還有信用、成交量、被收藏數量等等，這個算法搞的巨復雜）。這是一個多么牛叉的盈利模式啊！

這個系統進行的很順利，但發布的時候，更大的群體性事件出來了，買家們質疑：你們不是承諾 3 年不收費么？收廣告費不是收費么？后來我們的競爭對手又推波助瀾，公關公司和圈子里各路大俠上躥下跳，甚至同行搞了個“一鍵搬家”的功能來收納我們的會員。一時之間，輿論嘩然，各種矛頭都指了過來。為了收場，我們又一次在論壇里面讓用戶投票決定產品是否下線，同【我的淘寶】一樣，以悲劇收場。也如同【我的淘寶】一樣，下線后，一撥嘗到甜頭的賣家說，這么好的功能怎么沒有了？（直到后來 yahoo 中國合并過來之后，開發了淘寶直通車，才以類似的產品形態滿足了這部分需求）

雖然招財進寶失敗了，但這個項目中對技術的探索更加深入，這里面用到了用戶行為追蹤、Ajax 等。其中有一個技術的細節非常經典，淘寶商品詳情頁面每天的流量在 10 億以上，里面的內容都是放在緩存里的，做招財進寶的時候，我們要給賣家顯示他的商品被瀏覽的次數（見下圖），這個數字必須實時更新，而用緩存的話一般都是異步更新的。于是商品表里面增加了這樣一個字段，每增加一個 PV 這個字段就要更新一次。發布上去一個小時數據庫就掛掉了，撐不住這么高的 update。數據庫撐不住怎么辦？一般的緩存策略是不支持實時更新的，這時候多隆大神想了個辦法，在 apache 上面寫了一個模塊，這個數字根本不經過下層的 web 容器（只經過 apache）就寫入一個集中式的緩存區了，這個緩存區的數據再異步更新到數據庫。這就是我前面提到的，我們整個商品詳情的頁面都在緩存中了，把緩存用到了極致。

 

　　（這個圖真不是廣告，親）

那么接下來，我們就說說緩存的技術吧。

淘寶在很早就開始使用緩存的技術了，在 2004 年的時候，我們使用一個叫做 ESI（Edge SideIncludes）的緩存。在決定采用 ESI 之前，多隆試用了很多 java 的 cache，但都比較重，后來用了 oracle webcache，也經常掛掉，oracle webcache 也支持 ESI，多隆由此發現了 ESI 這個好東東。ESI 是一種數據緩沖/緩存服務器，它提供將 Web 網頁的部分（這里指頁面的片段）進行緩沖/緩存的技術及服務。由 Oracle 公司和 AkamaiTechnologies 公司制定規格，Akamai 公司提供對應的信息傳送的服務。以往的數據緩沖服務器和信息傳送服務以“頁”為單位制作，復制到數據緩沖服務器中，處理靜態頁面很有效。但在面對動態內容的時候，就很難得到高效率。在 ESI 中是部分的緩沖網頁，使用基于 XML 的標記語言，指定想要緩沖的頁面部分。由此，頁面內分為動態地變更的部分和靜態的不變更的部分，只將靜態的部分有效地發送到服務器中。淘寶網的數據雖然大部分都是動態產生的，但頁面中的靜態片段也有很多，例如頁面的頭、尾，商品詳情頁面的賣家信息等（如下圖右側），這些最早都是從 ESI 緩存中讀取的。

 

 

ESI 解決了頁面端靜態片段的緩存，聰明的讀者可能馬上就想到了，在后端的那些數據能不能使用緩存？顯然也是可以的，而且是必須的。例如一個大賣家的商品和店鋪，一天的瀏覽量可能是幾百萬，一個小賣家的可能只有幾個，那這個大賣家的用戶信息要是每次都去數據庫里面取，顯然不劃算，要是把這個信息放在內存里面，每次都從內存里取，性能要好很多。這種應用場景，就是 memcached 這種 Key-Velue 緩存的用武之地。只可惜在淘寶急需要 memcached 的時候，它還沒有嶄露頭角（它 2003.6 出現的，但近幾年才火爆起來，當時沒發現它）。我們的架構師多隆大神再一次出手了，他寫了一個緩存系統，叫 TBstore，這是一個分布式的基于 BerkeleyDB 的 cache 系統，推出之后在 Alibaba 集團內部使用非常廣泛，特別是對于淘寶，tbstore 上應用了 ESI（就是上面說過的那個 ESI）、checkcode（驗證碼）、description（前文說過的商品詳情）、story（心情故事，商品信息里面的一個大字段，長度僅次于商品詳情）、用戶信息等等內容。

TBstore 的分布式算法實現：根據保存的 key，對 key 進行 hash 算法，取得 hash 值，再對 hash 值與總 Cache 服務器數據取模。然后根據取模后的值，找到服務器列表中下標為此值 Cache 服務器。由 javaclient api 封裝實現，應用無需關心；這點和 memecached 的實現方案完全一致。

TBstore 有一個優點，這也是它的弱點，它的存儲是基于 Berkeley DB 的，而 BerkeleyDB 在數據量超過內存的時候，就要往磁盤上寫數據了，所以說它是可以做持久化存儲的。但是一旦往磁盤寫數據，作為緩存的性能就大幅度下降。

這時又有一個項目，推動了淘寶在緩存方面的技術提升。在 2007 年，我們把淘寶的用戶信息獨立出來，形成一個中心系統 UIC（userinformationcenter），因為淘寶所有的功能都要依賴于用戶信息，所以這個模塊必須單獨拿出來，不然以后系統無法擴展了。把 UIC 拿出來以后，應用系統訪問 UIC，UIC 訪問數據庫取得用戶信息，粗粗算一下，每天要取幾十億的用戶信息，直接查詢數據庫的話，顯然數據庫要崩潰的，這里必須要用緩存。于是多隆為 UIC 專門寫了一個緩存系統，取名叫做 tdbm。tdbm 拋棄了 BerkeleyDB 的持久功能，數據全部存放在內存中。到 2009 年，多隆又參考了 memcached 的內存結構，改進了 tdbm 的集群分布方式，在內存利用率和吞吐量方面又做了大幅提升，推出了 tdbm2.0 系統。

由于 tdbm 和 TBstore 的數據接口和用途都很相似，開發團隊把二者合并，推出了淘寶自創的 KV 緩存系統——tair。tair 包括緩存和持久化兩種存儲功能。tair 作為一個分布式系統，是由一個中心控制節點和一系列的服務節點組成。我們稱中心控制節點為 config server，服務節點是 dataserver。config server 負責管理所有的 data server，維護 data server 的狀態信息。dataserver 對外提供各種數據服務，并以心跳的形式將自身狀況匯報給 config server。 configserver 是控制點，而且是單點，目前采用一主一備的形式來保證其可靠性。所有的 data server 地位都是等價的。tair 的架構圖如下所示：

 

 

目前，tair 支撐了淘寶幾乎所有系統的緩存信息。Tair 已開源，地址 code.taobao.org。

在創造了 TFS 和 tair 之后，整個系統的架構可以如下所示：

  

在這個時候搜索引擎 iSearch 也進行了一次升級，之前的搜索引擎是把數據分到多臺機器上，但是每份數據只有一份，現在是每份數據變成多份，整個系統從一個單行的部署變成了矩陣。能夠支撐更大的訪問量，并且做到很高的可用性。

#p#

分布式時代：服務化

在系統發展的過程中，架構師的眼光至關重要，作為程序員，把功能實現即可，但作為架構師，要考慮系統的擴展性、重用性，這種敏銳的感覺，有人說是一種代碼潔癖。淘寶早期有幾個架構師具備了這種感覺。一指開發的Webx是一個擴展性很強的框架，行癲在這個框架上插入了數據分庫路由的模塊、session框架等等。在做淘寶后臺系統的時候，同樣需要這幾個模塊，行癲指導我把這些模塊單獨打成了jar包。另外在做淘寶機票、彩票系統的時候，頁面端也有很多東西需要復用，最直觀的是頁頭和頁腳，一開始我們每個系統里面復制了一份過去，但奇妙的是，那段時間頁腳要經常修改，例如把“雅虎中國”改成“中國雅虎”，過一段時間又加了一個“口碑網”，再過一段時間變成了“雅虎口碑”，最后又變成了“中國雅虎”，每個系統都改一遍，折騰啊。后來我就把這部分velocity模版單獨拿出來了，做成了公用的模塊。

本文將于作者同步更新，請留意。

原文鏈接：http://blog.sina.com.cn/s/blog_633219970100x9cc.html

【編輯推薦】

1. Java中常見IO的讀寫效率對比
2. Java幾款性能分析工具的對比
3. 棧的Java實現和棧的應用舉例
4. 實戰是硬道理：記Java技術面試
5. Java中的Enum的使用與分析