『淘寶十年技術路』讀書筆記

　　最近有幸，在學校的圖書館借到了子柳先生的《淘寶技術這十年》，拜讀一番，感慨萬分。將書中內容加上自己的想法與諸君分享，畢竟未經人事看法粗淺，希望能得到前輩們的指點。

　　一、淘寶的核心技術（國內乃至國際的Top，這還是2011年的資料）

• 擁有全國最大的分散式Hadoop叢集（雲梯，2000左右節點，24000核CPU，48000GB記憶體，40PB儲存容量）
• 全國分佈80+CDN節點，能夠自動找尋最近的節點提供服務，支援流量超過800Gbps，足以拖垮一個城市的流量
• 不遜於百度的搜尋引擎，對數十億商品進行搜尋，全球最大的電商平臺
• 頂尖的負載均衡系統，頂尖的分散式系統，頂尖的網際網路思想，功能多樣執行極其穩定
• 豐富的生態產業以及先進的資料探勘技術
• ……很多很多

　　二、淘寶網的誕生

　　馬總在2003年4月7日祕密叫來阿里巴巴的十位員工，來到杭州一個隱祕的毛坯房，要求他們在一個月左右的時間內做出一個C2C網站。

　　結果當然還是直接買的快，一個基於LAMP架構的網站，原名是PHPAuction，老美開發的一個拍賣網站。當然必須要做修改才能用。（作為一個曾經用老美開發的前端頁面開發自己部落格的同學，確實感覺用別人寫的比較方便偷懶-_-，不過我確信虛竹、三豐、多隆等前輩是有足夠實力開發自己網站的——還是馬總催的緊）

　　當時財大氣粗的eBay正在中國耀武揚威，加上SARS肆虐，可能大家對網購產生了新的認識。而淘寶刻意保持低調，甚至連阿里的員工都不知道這是他們自己公司的產品。

　　淘寶的員工積極回答著使用者的問題，早起貪黑，鍛鍊身體的方法就是倒立。

　　淘寶的功能也在不斷的完善著，釋出、管理、搜尋、詳情、購買等等，伺服器也變成了三臺。因為資料量大了，淘寶的搜尋很慢（使用LIKE匹配…），多隆前輩把阿里巴巴的搜尋引擎iSearch搬了過來。

　　當時MySQL的預設儲存引擎MyISAM會導致讀寫鎖等待時間過長等等大量問題，所以意外還是很多的。

　　2003年底，淘寶註冊使用者23萬，PV 31萬/day，半年成交額3371萬。

　　三、淘寶的更新

　　很顯然MySQL無法撐得起如此大的訪問量，資料庫瓶頸出現了。幸好阿里的DBA隊伍足夠強大，他們使用Oracle替代了MySQL。

　　Oracle那時就已經有了強大的併發性訪問設計——連線池，從連線池取連線的耗費比單獨建立連線少很多。但是PHP當時並沒有官方提供支援語言連線池特性，於是多隆前輩用Google（不會是Baidu）搜到了一個開源的SQL Relay，於是資料庫軟體方面的瓶頸暫時解決了。

　　但是硬體容量不夠了，阿里買了NAS（後來因為延遲嚴重原因買了EMC的SAN低端儲存），加上Oracle高效能RAC，硬體容量也暫時沒問題了。

　　開源的東西固然好，但是大膽使用也是一次嘗試的過程，SQL Relay會頻繁的導致死鎖問題，導致工程師不得不定期進行重啟服務，從書中的描述可以看出，淘寶的工程師們真的非常辛苦。

　　淘寶網不會止步於僅僅為賣家和買家提供一個交易的網站而已，還需要建立一個完善的第三方體系，來保證賣家和買家之間的交易是安全的，於是支付寶誕生了。比較麻煩的是，當時雖有很多銀行開放了網銀介面，但是甚至不能保證付錢後就會扣款成功，還是需要工程師們辛苦的一板一眼去對賬……

　　淘寶為了便於使用者的交流，開發了一個IM軟體——旺旺，不僅給買賣雙方使用，阿里內部也使用旺旺交流。

　　四、第一個里程碑

　　因為SQL Relay的問題實在過於嚴重，2004年於是淘寶終於做出了跨時代的決策——使用Java重寫網站（鼓掌~~~）。

　　沒錯，淘寶請了Sun的高階工程師來幫忙做Java架構。那麼他們是如何做到修改程式語言而不改變網站使用呢——模組化替換，今天寫好了A模組，另開一個新域名，將連線指向該模組，同時別的模組不變，等到全部模組完成的時候，原域名放棄。

　　使用的框架：淘寶的架構師在Jakarta Turbine的基礎上開發了自己的MVC框架——WebX。而Sun公司堅持使用EJB作為控制層（估計當時只有他們才能玩貫EJB），加上使用iBatis作為持久層，一個可擴充套件且高效的Java EE應用誕生了。BYW，支付寶也是Sun的工程師用同樣的架構設計的。

　　送走Sun的大牛們之後，阿里的資料儲存又遇到了瓶頸，於是忍痛買了一臺IBM小型機（我猜至少是百萬級別的…….），也就有了IOE（IBM + Oracle + EMC）這樣的傳說。

　　2004年底，淘寶註冊使用者400萬，PV 4000萬/day，全網成交額10個億。

　　五、再接再厲

　　Oracle也有處理上限，當數量的級別是“億”的時候，就不是一個Oracle伺服器支撐的起的了。DBA們把資料分到了兩個資料庫中，通過ID的第一位決定查詢哪一個資料。比如，‘0’至‘7’放在A資料庫，‘8’至‘f’放在B資料庫，通用資訊放在C資料庫。但是如何既查詢’3′開頭又查詢’e'開頭的資料呢？一個資料庫路由框架DBRoute由架構師行癲編寫，統一處理合並問題而對上層透明。

　　Spring誕生了，早聞Spring框架在Web應用不可或缺，而在淘寶網，Spring也達到了Rod Johnson設計它的目的——替代EJB。

　　2005年底，淘寶註冊使用者1390萬，PV 8931萬/day，商品數目1663萬個。

　　說實話我真的好佩服，這麼大的訪問量都能如此堅挺，但是，考慮到未來的發展，這樣的設施架構只是勉強可以應付現在的要求。於是，CDN技術派上用場了，一開始使用商用的ChinaCache，後來使用章文嵩博士搭建低耗能CDN網路，淘寶網的效能越來越好了。

　　2006年底，淘寶註冊使用者3000萬，PV 15000萬/day，商品數目5000萬，全網成交額169億元。

　　六、創造技術

　　為了考慮交易的公平性，淘寶增加了交易快照功能，將當前交易網頁以圖片的形式儲存下來，淘寶的交易量如此之大，帶來了一個問題——碎片圖片過多，2010年，淘寶網的後端上儲存著286億張圖片。

　　淘寶在2007年之前，使用NetApp的商用儲存系統，但是仍然不夠應付迅速增長的趨勢。同年Google公佈了GFS的設計思想，參照它的思想，淘寶也開發了自己的檔案系統——TFS。至於這個檔案系統的具體原理書上給的並不詳細（應該是我看不懂-_-），不過可以大概可以瞭解是專門為大量的圖片設計的，從每個使用者1張圖片到TFS上線後5張再到1GB的圖片空間，這些都得益於TFS叢集的檔案儲存系統以及大量的圖片伺服器。淘寶使用實時生成縮率圖，全域性負載均衡以及一級和二級快取來保證圖片的訪問優化與高效訪問。

　　淘寶的伺服器軟體使用Tengine，一個被優化過的nginx模組。

　　淘寶也做過失敗的產品，不是因為技術原因而是市場原因。首先是“團購”，失敗在於人心叵測。再次是“我的淘寶”，使用了風靡全球的AJAX的技術，但是做的過於AJAX了，可能是太不容易上手了（馬總親口說的），還有“招財進寶”（被競爭對手認為是破壞了“免費”的承諾而大肆宣揚）。

　　記錄商品的訪問量，使用傳統的資料庫I/O實在過於影響效率，所以淘寶使用了緩衝的技術，先是使用ESI（Edge Side Includes）,解決了片段緩衝問題。因為有些大店鋪訪問量過大，頻繁的I/O實在得不償失，於是多隆前輩寫出了TBstore，可以快取大量的資料，核心思想是使用Hash演算法快速尋找。其核心是基於Berkeley DB，一種類記憶體資料庫，導致的問題是記憶體資料量大了還是會刷到磁碟中，因此效能並不是那麼的好。

　　後來，淘寶分離出了UIC（User Information Center），供所有模組呼叫。多隆前輩再次為其編寫出了TDBM，完全是基於記憶體的資料快取（參考了memcached）。再然後，淘寶將TBstore和TDBM合併，寫出了Tair，一個基於Key-Value的分散式快取資料系統。然後升級了自己的iSearch系統。

　　2007年底，淘寶註冊使用者5000萬，PV 25000萬/day，商品數目1個億，全網成交額433億元。

　　七、更多的技術

　　一個電子商務平臺不可缺少的細節——商品類目的處理。因為商品的類目實在過於龐大，因此如何根據類目劃分商品成為了難題。機智的一燈前輩說，這些屬性可以當做標籤，直接“貼”在商品上（應該是這樣的吧）。

　　2008年，淘寶將支付寶單獨分離出來。其中交易的底層業務叫交易中心TC（Trade Center），涉及訂單之類的原子操作。交易的上層業務叫做交易管理TM（Trade Manager），不涉及對物流的操作。

　　於是，應運而生的，第二個堪稱里程碑的專案——系統拆分 誕生了。這個正是我們在阿里圓桌會議上HR所說一位元老級員工做的——“給一架高速飛行的飛機換髮動機”這麼驚險的重構任務。這些元件分割難度非常之大，以至於那張複雜的邏輯圖我實在看不懂……總之，淘寶中介軟體誕生了。

　　HSF（高效能服務框架）：核心，外號好舒服。請參見作者的博文http://www.blogjava.net/BlueDavy/archive/2008/01/24/177533.html

　　Notify（訊息中介軟體）：淘寶自主開發的訊息佇列產品。支撐了10億+的訊息通知。

　　TDDL（分散式資料訪問層）：優化了DBRoute，在JDBC和DB之間隔了一層，負責資料庫的優化工作。

　　Tbsession：因為Session儲存在伺服器中，但是使用者可能會被動的頻繁的切換伺服器，淘寶的設計思路是將Session資訊儲存在Cookie中，最後使用Tair來儲存。

　　阿里的開放平臺也相當有歷史，有興趣的可以參觀參觀http://open.taobao.com/index.htm

　　八、總結

　　當你處於業界中流時，你可以向老大學習，等當你成為業界老大之後，你就需要不斷超越自己，用自己的力量來改變整個行業，乃至整個世界。無論是華為，還是阿里，當成為業內的Top時，責任反而更加重大。

　　一直覺得自己想著隨大流，但是卻又心有不甘。如今有機會能進入全中國最好的網際網路網站，一直為自己這些年的付出感到榮幸，同時不斷勉勵自己，你需要變得更強才能融入這個集體。

　　任重而道遠，縱望阿里淘寶這些年的發展之路，那些默默無聞卻勇於探索鑽研的人是最可愛的，遇到問題永遠不服輸，總會有辦法去解決的。正如阿里圓桌會議HR所說的“在座的各位都是愛折騰的人”，我承認自己受之有愧，自己的身體一直不能保證毫無顧忌的拼鬥，自己雖然每天堅持都去跑步，底子還是不行，想要成為一名武林中人，更漫長的路需要我堅持的走下去，意志力，我可以有。

　　堅持學習，鑽研學習，實踐學習。希望自己能堅持這三點信條。

　　相當佩服馬總的思想理念和為人處事，也相當佩服那麼多實力不凡而又忠心耿耿的部下，他們對得起他們的身價。

　　子柳兄的《淘寶技術這十年》到此總結完畢，我相信淘寶的光輝路程的還有很長，我的學問之路，也必將一直走下去。

　　相關文件：淘寶技術路