淘寶網發展史：揭開神祕組織的技術內幕與艱辛歷程

目前關於阿里上市、央行對第三方支付新政滿天飛，互聯網金融創新腳步不會中止，筆者帶您迴歸平靜心。本文絕對乾貨與經得起時間沉澱：分析淘寶網技術內幕、故事與艱辛歷程，從我的網站步入到堅若磐石時代，無論您是什麼角色，爲避免走彎路，都值得您閱讀與轉發.....
(編者 Boris)

　1、引言：光棍節的狂歡

　　11月11日「光棍節」網民感覺到的是瘋搶的喜悅，而網站的技術人員感覺到的倒是「壓力山大」。就如同你家辦酒席，宴請左鄰右舍，這個辦起來容易。假若宴請十里八鄉全部的人，吃飯的人天然開心，但卻不是通常人家可以辦得起來的。能辦得起來如此盛宴者，須要強大的財力物力、組織能力、技術實力(例如作這麼多菜，你的炒鍋必定要是「分佈式的」、「可複製的」、「可擴展的」，洗菜切菜要有「工做流引擎」，上菜的路徑要用圖論來計算出來，甚至連廚房的下水道都要從新設計)。

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

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

 

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

 

　　以上對比的這些網站，也許讀者很容易就猜到是哪一家，這裏拿出來做對比，絕對沒有嘲笑人家的意思，採用一般的網站技術方案，能作到這種程度已經不錯了。任何網站的發展都不是一蹴而就的，在什麼樣的階段採用什麼樣的技術。在發展的過程當中網站會遇到各類各樣的問題和業務帶來的壓力，正是這些緣由才推進着技術的進步和發展，而技術的發展又會反過來促進業務的更大提高。兩者互爲因果，相互促進。現在淘寶網的流量已是全球排名第十二、國內排名第3(美國的eBay全球排名23，國內前兩名是百度和騰訊)。淘寶網的系統也從使用一臺服務器，到採用萬臺以上的服務器。本書就爲你們描述淘寶網在整個發展過程當中，全部的主動和被動的技術變革的來龍去脈，這由不少有趣的故事組成。

 

　　正如同不少人或組織成功了之後，就會爲本身的出身編造一個美麗的傳說。淘寶網的出身，網上也有很是多的傳說，下面咱們就從它的出生開始講起。

 

 

　　2、我的網站

 

　　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、一臺負責運行數據庫、一臺負責運行Web App。過一段時間以後，商品搜索的功能佔用數據庫資源太大了(用like搜索的，很慢)，又從阿里巴巴中文站搬過來他們的搜索引擎iSearch，起初iSearch索引的文件放在硬盤上，隨着數據量的增加，又採購了NetApp服務器放置iSearch。

 

　　如此快節奏的工做，其實你們都累得不行，有人就提議你們隨時隨地的鍛鍊身體，但是外面SARS橫行，在一個一百多方的房子裏，怎麼鍛鍊呢?高挑美女阿珂提議你們練習提臀操，這個建議遭到男士的一致反對，後來虛竹就教你們練習倒立，這個你們都能接受。因而這個倒立的傳統一直延續至今，和花名文化、武俠文化一併傳承了下來。

 

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

 

(新用戶：點擊上面【互聯網金融】，一鍵關注本公衆號,或加公衆號：tifits)

　　3、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 的東西都很貴，咱們買不起，因而多隆在網上尋尋覓覓，找到一個開源的鏈接池代理服務 SQLRelay( http://sourceforge.jp/projects/freshmeat_sqlrelay )，這個東西可以提供鏈接池的功能，多隆對它進行了一些功能改進以後就拿來用了。這樣系統的架構就變成了以下的樣子：

 

 

數據一開始是放在本地的，DBA 們對 Oracle 作調優的工做，也對 SQL 進行調優。後來數據量變大了，本地存儲不行了。買了 NAS(NetworkAttached Storage：網絡附屬存儲)，NetApp 的 NAS 存儲做爲了數據庫的存儲設備，加上 Oracle RAC(Real Application Clusters，實時應用集羣)來實現負載均衡。七公說這其實是走了一段彎路，NAS 的 NFS(Network File System)協議傳輸的延遲很嚴重，但那時侯不懂。後來採購了 Dell 和 EMC 合做的 SAN 低端存儲，性能一會兒提高了 10 幾倍，這才比較穩定了。再日後來數據量更大了，存儲的節點一拆2、二拆四，RAC 又出問題了。這才踏上了購買小型機的道路。在那段不穩定的時間裏，七公曾經在機房住了 5 天 5 夜。

 

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

 

　　微博上有人說「好的架構是進化來的，不是設計來的」。的確如此，其實還能夠再加上一句「好的功能也是進化來的，不是設計來的」。在架構的進化過程當中，業務的進化也很是迅猛。最先的時候，買家打錢給賣家都是經過銀行轉帳匯款，有些騙子收了錢卻不發貨，這是一個很嚴重的問題。而後這夥人研究了 PayPal 的支付方式，發現也不能解決問題。後來這幾個聰明的腦殼又想到了「擔保交易」這種第三方託管資金的辦法。因而在 2003 年 10 月，淘寶網上面上線了一個功能，叫作「安全交易」，賣家選擇支持這種功能的話，買家會把錢交給淘寶網，等他收到貨以後，淘寶網再把錢給賣家。這就是如今的支付寶，在前兩天(2012.2.21)年會上，支付寶公佈 2011 年的交易筆數已是 PayPal 的兩倍。這個劃時代的創新，其實就是在不斷的思索過程當中的一個靈光乍現。

 

　　當時開發「安全交易」功能的是茅十八和他的徒弟苗人鳳(茅十八開發到一半去上海讀 MBA 去了，苗人鳳如今是支付寶的首席業務架構師)，開發跟銀行網關對接的功能的是多隆。當時多數銀行的網站已經支持在線支付了，但多隆告訴我，他們的網關五花八門，用什麼技術的都有，必須一家一家去接。並且他們不保證用戶付錢了就必定扣款成功、不保證扣款成功了就必定通知淘寶、不保證通知淘寶了就必定能通知到、不保證通知到了就不重複通知。這害苦了苗人鳳，他必須天天手工覈對帳單，對不齊的話就必定是有人的錢找不到地方了，少一分錢都睡不着覺。另外他爲了測試這些功能，去杭州全部的銀行都辦理了一張銀行卡。一堆銀行卡擺在桌子上，不知道的人還覺得這個傢伙必定頗有錢，其實裏面都只是十塊八塊的。如今咱們再一次知道，任何牛B的人物，都必須有一段苦B的經歷。

 

　　有人說淘寶戰勝易趣(eBay 中國)是靠免費，其實這只是緣由之一。若是說和易趣過招第一招是免費的話，這讓用戶沒有門檻就願意來，那第二招就是「安全支付」，這讓用戶放心付款，沒必要擔憂被騙。在武俠小說中真正的高手飛花摘葉便可傷人，他們不會侷限於一招兩招，一旦出手，連綿不絕。而淘寶的第三招就是「旺旺」，讓用戶在線溝通。其實淘寶旺旺也不是本身生出來的，是從阿里巴巴的「貿易通」複製過來的。從 2004 年 3 月開始，「叮咚、叮咚」這個經典的聲音就回蕩在全部淘寶買家和賣家的耳邊，「親，包郵不?」，「親，把零頭去掉行不?」，這親切的砍價聲造就了後來的「淘寶體」。有人說中國人就是愛砍價，雖然筆者體會不到砍價成功後有多少成就感，但每次我去菜市場，看到大媽們砍價砍得天昏地暗，那知足的勁頭堪比撿到了錢，我就深入的理解了淘寶旺旺在交易過程當中的價值。我猜 eBay 也體會不到砍價的樂趣，他們一直不容許買賣雙方在線聊天，收購了 skype 以後也沒有用到電子商務中去。

 

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

 

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

 

 

　　4、淘寶技術發展(Java時代：脫胎換骨)

 

　　個人師父黃裳@嶽旭強曾經說過，「好的架構圖充滿美感」，一個架構好很差，從審美的角度就能看得出來。後來我看了不少系統的架構，發現這個言論基本成立。那麼反觀淘寶前面的兩個版本的架構，你看哪一個比較美?

顯然第一個比較好看，後面那個顯得頭重腳輕，這也註定了它不是一個穩定的版本，只存活了不到半年的時間。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 這一部分會在最後講解，這裏先埋個千里伏筆。

 

(新用戶：點擊上面【互聯網金融】，一鍵關注本公衆號,或加公衆號：tifits)

　　5、淘寶技術發展(Java時代：堅若磐石)

 

　　已經有讀者在火燒眉毛的問怎麼去掉了 IOE，別急，在去掉 IOE 以前還有很長的路要走。行癲他們買回來小型機以後，咱們用上了 Oracle，七公帶着一幫 DBA 在優化 SQL 和存儲，行癲帶着幾個架構師在研究數據庫的擴展性。Oracle 自己是一個封閉的系統，用 Oracle 怎麼作擴展?用如今一個時髦的說法就是作「分庫分表」。

 

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

 

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

 

　　上一篇說過，採用 EJB 實際上是和 Sun 的工程師妥協的結果，在他們走了以後，EJB 也逐漸被冷落了下來。在 0五、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 的發展須要專門一個章節來說，想先睹爲快的能夠看一下筆者對章文嵩的專訪。

 

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

 

　　有些技術的發展是順其天然的，有些倒是突如其來的。到 2007 年的時候，咱們已經有幾百臺應用服務器了，這上面的 Java 應用服務器是 WebLogic，而 WebLogic 是很是貴的，比這些服務器自己都貴。有一段時間多隆研究了一下 JBoss，說咱們換掉 WebLogic 吧，因而又省下了很多銀兩。那一年，老馬舉辦了第一屆的「網俠大會」，會上來的大俠中有一位是上文提到的章文嵩，還有一位曾經在 JBoss 團隊工做，咱們也把這位大俠留下了，這樣咱們用起 JBoss 更加有底氣了。

 

　　這些雜七雜八的修改，咱們對數據分庫、放棄 EJB、引入 Spring、加入緩存、加入 CDN、採用開源的 JBoss，看起來沒有章法可循，其實都是圍繞着提升容量、提升性能、節約成原本作的，因爲這些不算大的版本變遷，咱們姑且叫它2.1版吧，這個版本從構圖上來看有 3 只腳，是否是穩定了不少?

 

　　架構圖以下：

 淘寶網發展史：Java時代：創造技術-TFS

 

　　在講淘寶文件系統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版本，在生產系統的性能已經獲得驗證，且不斷獲得了完善和優化，淘寶網目前在對象存儲領域的研究已經走在前列。

--------------分割線------------------

互聯網金融 每日e報 微信號 tifits
關注互聯網金融、移動互聯網、電子商務、互聯網創新。

2013互聯網金融.中國峯會、2014中國互聯網金融高層論壇論壇、2014中國互聯網金融創新論壇、第七屆中國電子金融年會 獨家官方微信公衆號。

中國最專業互聯網金融專業人士的關注；
合做企業：百度、騰訊、諾亞、中國電子商務協會、中國電子金融產業聯盟、中國互聯網協會、中金在線......