揭秘eBay架構與存儲

eBayd Web領域樹立了一個典范。從一系列的數(shù)據當中都可以看到，這樣一個超大規(guī)模的網站，其數(shù)據和計算量對技術的要求非常之高。為了能保證全球兩億多用戶的正常訪問，除了要有優(yōu)良的技術架構作為支撐外，每天產生的海量數(shù)據也需要精心保存。作何一個開發(fā)人員和信息管理人員面對這樣艱巨的任務都如履薄冰。為此本刊組織了兩篇eBay的技術文章，以饗讀者。

擴展：不僅僅關于架構

文/Frank Sommers 譯者/靳黎明

在2006 SD論壇中，兩位eBay的架構師發(fā)表演講，總體闡述了兩個主題：eBay的架構是如何處理每天十億次的頁面訪問請求，以及該架構是如何從當初的Perl腳本演化到目前的運行在8個數(shù)據中心的1萬5千個應用程序例。該演講所得出一個結論就是，擴展僅僅是架構中的問題。

eBay系統(tǒng)架構的演化

在2006 SD論壇中，Randy Shoup和Dan Pritchett都結合eBay發(fā)表了關于eBay架構的演講。Pritchett隨后在他的Blog中發(fā)布了一個演講幻燈片——標題為eBay的架構。

意料之中，他在演講中提到了一些令人驚嘆的統(tǒng)計數(shù)字，具體如下：

l         2億1千2百萬注冊用戶

l         每天10億次的訪問量

l         每天260億次的SQL查詢和更新

l         超過2千萬億的數(shù)據量

l         每秒價值1590美元的貨物交易

l         超過10億張的圖片存儲

l         7種不同的語言

l         99.94%的系統(tǒng)可用性

與開發(fā)過程和特性相關的其他統(tǒng)計數(shù)據，如下：

l         每季度網站新增300多項新特性

l         每兩周發(fā)布超過十萬行的代碼

根據他的演講，盡管eBay的架構已經達到了如此大的規(guī)模，但是，eBay期望能夠在短短幾年內實現(xiàn)它的目標——處理通信量高達十倍的額外增長。另外一個架構目標是，能夠處理峰值載荷，并且在非常負載或者系統(tǒng)癱瘓的情況下能夠使組件安全地停止工作而不致受損。

根據演講的內容，目前，eBay的系統(tǒng)架構正朝著第四個版本努力。當然，演講中最吸引人的技術部分也主要是關于這個版本的各種技術信息，例如，演講者所講述的是擴展應用程序層的第一步：摒棄大部分的J2EE特性。取而代之的是，他們注意到“eBay采用Servlets 和一個重寫的連接池進行擴展。”

根據演講的介紹，關于應用程序層擴展的另一吸引人的方面是，在應用程序層完全不保存會話狀態(tài)信息。取而代之的是，“在cookie或者scratch數(shù)據庫中保存過渡狀態(tài)。”為了實現(xiàn)數(shù)據存取，eBay使用內部開發(fā)的Java O/R映射解決方案。

在擴展該網站的搜索方面，演講者注意到一個與眾不同的需求，而這是Google這樣的通用Web搜索引擎所不會遇到的問題，即：eBay的用戶期望能夠在搜索結果中立即查詢出他們對數(shù)據所做出的變動。同樣地，拍賣者確切地知道他們所期望的搜索結果——舉個例子，他們剛剛列出的項目必須出現(xiàn)在所有相關的搜索結果中。顯而易見，在最新版eBay搜索的重架構出現(xiàn)之前，僅僅是更新一次搜索的索引也需要9個小時。

演講者說到了很多類似的具有挑戰(zhàn)性的問題，同時也深入探討了問題的解決方案。然而對我而言，演講中令我最感興趣的話題是，關于eBay架構本身是如何演化的介紹。關于這個話題，我們需要對第一版本的架構進行一些思考，例如：

l         1995年的一個周末Pierre Omidyar構建了第一版本的架構

l         每個項目是一個單獨的文件，由Perl腳本生成

l         沒有搜索，只能夠按照類別進行瀏覽

l         系統(tǒng)硬件是由能夠在Fry商店購買的商品零件所組裝的

從1995年到1997年9月，eBay一直使用這個架構。演講提到，那時，eBay已經是一個比較有名的網站了，而且它的架構也達到了5萬項的最高值。

接下來的幾次迭代使得eBay的架構進入了3層架構的階段，最初是在微軟的IIS服務器上，然后轉移到Java中。最終的幾個版本表明，需要摒棄J2EE的很多特性，以高度化定制的架構來滿足eBay的獨特需求。

關于eBay所經歷的這四個主要的架構版本，一種觀點是，這四種版本是一場進化。然而，另外一種觀點是，這四個版本形成了一個完整的圓圈：剛開始時，采用設計定制的解決方案，最終又轉回到定制解決方案上來。

根據對各個不同架構階段的介紹，我非常希望了解，eBay的架構師在解決表現(xiàn)層擴展這一迫切問題上達到了哪種程度，他們希望在系統(tǒng)中實現(xiàn)可擴展性以此來處理將來的負載，那么這一目標的實現(xiàn)又達到了何種程度。即使是為將來考慮，那么，架構師需要預測未來某些假設的時間點處系統(tǒng)的可擴展性，他們的這一能力又達到了何種程度呢？

關于這些預測的一個問題是，即使目前的操作系統(tǒng)中保存的大量數(shù)據都是可供使用的，系統(tǒng)的使用模式也會發(fā)生改變的——舉個例子，用戶可能開始喜歡視頻而不是簡單的圖片，或者語音電話作為系統(tǒng)交互的一部分。根據演講的內容，這些使用模式的變化完全可以很快地到來，尤其是當平均架構生命周期變成了大約2-3年。例如，兩三年前，聽說過YouTube的人很少，但是，在該公司短短的兩三年生命周期中，數(shù)百萬的用戶已經習慣于網絡視頻了。

實現(xiàn)擴展：組織能力+架構

   我認為最后爭論的這個問題是這次eBay演講主要信息之所在。對我來說，關于eBay架構的變革，最驚人的方面不僅僅是每一個架構時期所采用的解決方案技術的卓越，還有這個事實——eBay能夠通過對系統(tǒng)進行不斷的改進來迎接所遇到的各種挑戰(zhàn)，所有階段的努力使得這個網站長久不衰。

有趣的是，它建議你幾乎可以從任何一種架構開始做起——甚至是使用Perl或者Rails或者JSP頁面——當你需要擴展你的應用程序時，只要你知道如何轉移到下一步，并且有能力實現(xiàn)。反過來，它也建議，可擴展性的關鍵并不完全是每個架構階段之間如何進行擴展，而是一個公司或者一個組織如何把應用程序從一個架構階段推進到下一階段。這表明，擴展像技術問題一樣是個人或者組織的問題。

當然，這并沒有什么令人驚訝的，因為，與架構設計一樣，擴展也總是可以實現(xiàn)的。（eBay演講的最后一部分就講解了擴展的可操作性這個主題——例如，它解釋了1萬5千個應用程序實例是如何通過八個數(shù)據中心進行管理的。）然而，如果從更寬廣的視角來看待擴展的話，其中兩個普遍存在的擴展方式可能在實際中是沒有用處的。

一個方式是，從開始就過于強調可擴展性的設計。大多數(shù)開發(fā)人員都知道架構的擴展無法從一開始就確定，但是，在某些情況下，架構師仍然寧愿花費過多的精力來試圖設計一個能夠長期滿足應用程序需求的架構。Pierre Omidyar基本上不同意這個觀點，這就是為什么他會選擇在他的初始版本中使用Perl腳本以及每個項目一個文件的機制，而不采用一勞永逸的方式。

第二個主張可擴展性無用的觀點認為，可擴展性和性能一樣純粹是事后考慮的，而且反對在應用程序開發(fā)的初始階段就考慮可擴展性。XP倡導者有些時候利用這一觀點辯護，因為他們更熱衷于快速地寫代碼，而不是考慮以后這些代碼將如何進行擴展以處理將來的應用程序工作負載。

實際上，這兩種觀點都是沒有太大用處的。更加現(xiàn)實的觀點是，第三種觀點，把擴展作為組織上甚至是業(yè)務層上的能力的一部分。預測將來的工作負載是非常困難的，我們需要認識到這一點，那么，如果可以預測的話，這個觀點將主要用于這種架構——處理近期進行的擴展，同時允許對特性進行快速部署，以使應用程序的實際用戶能夠為支持將來的架構更新生成業(yè)務合理性。然而，遠遠不同于把擴展作為組織甚至業(yè)務能力開始，發(fā)展到能夠處理系統(tǒng)的架構變化。這看起來正是2006 SD論壇上eBay架構師所做演講的觀點之所在。

那么在你的項目中，你什么時候開始考慮實現(xiàn)擴展性呢？