旁觀者看eBay技術發展

本文轉載自http://www.blogjava.net/BlueDavy/archive/2009/07/24/288055.html ， 轉載請註明

 

幾年以來，eBay在幾個不同的大會上先後分享過幾次關於eBay技術的PPT，在這篇blog中，就以這些PPT來以旁觀者的角度分析下eBay的技術 發展曆程，不論eBay現在的業績如何，不可否認，他們的技術還是挺強的，因此還是值得學習，eBay的整個技術發展曆程從一定程度上來說可以認為是互聯 網公司的典型技術發展曆程，基本上各家互連網公司都在走著類似的路線，只是各家選擇的語言不同、具體的實現方案不同、細節不同，當然，思路是一方面，實現 又是另外一方面，只有兩者結合才能實現一個高可用、高效能和高並發的有海量資料的系統。

本篇blog中涉及到的主要有eBay的以下三個PPT，先來闡述下這幾個PPT，最後從一個旁觀者的角度來總結下eBay的技術發展。
ps: 以下提及的三個PPT均可在此下載：http://www.blogjava.net/BlueDavy/archive/2009/04/28/267970.html

1、The eBay Architecture 2006
      這個PPT非常經典，闡述了eBay從成立之初到2006年所經曆的技術發展曆程，這個過程一定程度上也是目前大多數網站從小到大時的一個發展過程。
      在這個PPT中，eBay首先根據自己的經驗，總結出了一些經驗，這些經驗包括：
      (1). 每一層都要支援水平伸縮，按功能劃分；
      (2). 優選非同步方式為系統間互動的方式；
      (3). 減少系統間物理依賴以及提升部署的靈活性；
      (4). 自動化的錯誤診斷和通知，業務功能的降級支援。
     即使現在看這些經驗，可謂是金玉良言，想必eBay也是在一個快速發展的過程經曆了很多次血的教訓才得到上面這些經驗的。
     在總結完經驗後，PPT開始詳細的闡述eBay從1995--2006的技術發展曆程，從V 1.0到V 2.x，首先是將系統重構為3層結構，採用Oracle，商務服務器和資料庫伺服器分開，採用索引，這也就是2.0版本；進入2.1版本後，想必是資料庫 壓力開始增大了，這有兩方面原因，一是訪問量的上漲，二是資料量的上漲，因此將資料庫伺服器進行了升級，換成了更好的伺服器，同時給前端加上了負載平衡， 這應該是為了前端應用更簡單的實現水平擴充；進入2.3版本後，增加了第二台資料庫伺服器，以支援failover，提升可用性，同時其他的商務服務器在 不斷的增加中，到2.3版本啟動並執行末階段，資料庫伺服器已經達到了啟動並執行極限；進入2.4版本階段，專註解決資料庫壓力的問題，採用的方案為將資料庫邏輯 分區為多個執行個體；進入2.5版本階段，開始進行水平分表，例如按類目將商品分解到多張表中，或者讀寫分等。在V 2.5階段完成後，此時資料庫部分壓力的問題基本解決，但在eBay面前又出現了新的問題（畫外音：所以說互連網公司到最後技術的比拼也非常重要），幾百 人維護同樣的代碼，甚至還達到了類允許的最大的方法數等問題，於是進入了eBay架構的V 3時代。V 3最重要的是將整個應用翻寫為Java，並提升了代碼的重用性和代碼的職責分離，同時為開發人員提供了一個開發的架構（應該就是那篇著名的eclipse at eBay）。
      在PPT的最後，eBay又詳細的分享了他們對於構建可伸縮系統的一些經驗，這些經驗對多數人而言都會非常的有協助，來看看。
       (1). 資料層的伸縮
       主要是三種方法：分解壓力，減少資料庫做的事情，無事務等技巧。
       分解壓力最主要的方法有按功能進行劃分，功能範圍內的則可進行水平劃分，在PPT中eBay還分享了下按功能劃分的一些例子，例如按使用者、商品、評價等，水平劃分方面同樣列舉了一些例子，例如讀寫分、hash分等。
       對於資料層的伸縮，eBay在PPT中提到了非常關鍵的一點，那就是應用無需關心分庫、分表這些，這樣的話，無論是要分庫、合庫、分表還是合表，對應用都是完全透明的，正是因為這個理念造就了eBay很早以前就擁有了令人驕傲的資料層，也就是DAL。
       減少資料庫做的事情最主要的方法是不要在資料庫中做商務邏輯的處理，將耗CPU的操作（包括joins、sorting等）放到應用中完成，使用Prepared statements和綁定變數。
       所謂的無事務等技巧是指沒有分散式交易，而改為採用補償等方式去保持資料一致性。
       (2). 應用程式層的伸縮
       主要也是三種方法：分解壓力，減少依賴和虛擬資料操作。
       分解壓力最主要的方法有按功能劃分，水平則藉助負載平衡來進行伸縮，關於這裡面的具體的一些技巧，PPT中提到了應拋棄大部分Java EE的東西，保持應用程式層的無狀態，儘可能的使用緩衝。
       減少依賴最主要的方法有將代碼也按功能進行劃分，各功能之間需要共用的東西則放入domain中，所有的應用都只能依賴domain，不能依賴其他的應 用，而domain之間也不能有依賴，另外PPT中還提及到的有平台解耦，對於這點eBay的做法是經典的EDA以及同步的SOA。
       虛擬資料操作指的就是(1)中提及到的資料層了，不過在這裡還值得注意的是它有提到它們可以做到從資料路由方面來達到優雅降級，所謂優雅降級的概念就是當系統壓力大時，只保核心功能可用，而其他非核心的功能則不可用。
       (3).搜尋的伸縮
       對這部分不是高度興趣，大概提下主要就是做了即時索引，水平劃分以及緩衝。
       (4).操作的伸縮
       eBay在當時就能考慮這塊，真的很不容易，這裡包含的主要是兩點：代碼部署以及監測。
       由於當時的eBay基本每兩星期就要做全站部署，不過現在的eBay已經不會這麼頻繁部署了，部署時的依賴關係、部署後失敗的復原操作、眾 多的配置以及需要部署到眾多的機器，這些都煩惱著當時的eBay，因此eBay做了一個部署系統，該部署系統可做到的是根據需要的部署的功能，分析出其依 賴關係，按依賴關係進行部署，部署時自動進行檢測和校正，並可選擇性的進行復原或全部復原，不得不感歎，真夠強大的。
       監測方面基於訊息機制實現，對日誌進行廣播、記錄（記錄至檔案(當時的eBay記錄的動作記錄檔案就已經有1.5TB每天了)、捕捉異常進行警示或即時的系統狀態的監測）以及分析（報表、挖掘等）。
      從上面的對PPT的分析來看，儘管這個PPT並不厚，但它的價值真的非常的高，並且也充分的展現了eBay的技術實力。

2、eBay Architectural Principles 2008
      在2008年的QCon London會議上，eBay分享了這個PPT，這個PPT的內容不像上面的PPT講解eBay的架構演變過程，而是直接根據eBay的經驗總結了一些構 建大型可伸縮系統的架構原則，有點像設計模式，將之前應對情境需求的一些技巧都總結成了模式，因此這些原則對於構建大型系統的同學而言都非常有協助，來具 體的看看。
      PPT首先提到了架構關注的重點：延展性、可用性、延時、可管理性以及成本，然後就提交到四點架構模式，來具體看看。 
      (1). 能分則分
      在這點上eBay提出了一個觀點："If you can't split it,you can't scale it"，因此eBay建議將系統按資料、壓力或使用方式來進行分解，分解的模式為按功能以及水平分割。
      在PPT中eBay繼續提及了資料庫的垂直以及水平分割方法、無事務、應用程式層的垂直以及水平分割方法、應用程式層的無狀態、搜尋的垂直以及水平分割，這些方法在第一個PPT中也有詳細分享。
      (2). 能非同步則非同步
      在這點上，eBay認為，只要能非同步就應該非同步，非同步實現模式為訊息機制以及定時大量操作機制。
      訊息機制的方式通常為功能核心部分完成後發出訊息，然後訂閱訊息的應用非同步進行一些處理，例如建立商品在建立完畢後，發出訊息，影像處理的應用在接到消 息後則能對此商品進行相應的處理，在PPT中還舉到的一個例子為發出訊息，用於更新搜尋中的索引資訊，這其實也就是eBay的即時索引的實現方式了。
      定時大量操作適用於匯入三方資料、產生推薦等。
      (3). 能自動化則自動化
      在這點上，eBay認為，能自動化的就盡量自動化，避免人工操作，實現的模式為自適應配置以及機器學習。
      自適應配置方面eBay舉了個例子，給一個事件的訂閱者定義了SLA，例如為99%的事件應在15秒內處理完，那麼所謂的自適應配置就是系統應能根據配置 的SLA自動的調整，以最小的資源去滿足SLA，例如調整處理的線程數、隊列的大小、彈出的頻率等，是不是有那麼點雲端運算的前兆，:)。
      機器學習方面eBay主要提及到的為給使用者提供最匹配的頁面配置、推薦等。
      (4). 記住所有失敗的事     
      這裡的需求是所有的系統都應能容錯，主要目的是為了保證可用性，實現的模式為失敗檢測、復原以及優雅降級。
      失敗檢測上eBay採取的方法為通過發送訊息，由訊息訂閱者來進行記錄、警示、分析或挖掘。
      在復原方面主要指的是代碼的部署和復原，就是之前第一個PPT中提及的部署系統。
      優雅降級指的是系統功能的動態開啟和動態關閉，eBay採取的方法為一個集中的配置來管理功能的開啟或關閉。
      PPT中還舉了個例子來更好的說明，首先應用檢測到了某個資源不可用或很慢，此時為了保證可用性，可做的有這麼幾件事：應用停止對此資源的操作並發出警告、關閉非核心的功能、核心功能退化（基於failover切換至其他資源或轉為非同步處理模式）。
      這個PPT同樣也不厚，但總結的非常好，這些模式對於構建大型系統（尤其是互連網系統）而言基本都是必須的，在2009 QCon北京大會上，eBay分享的也是這方面的話題，大體都是相同的，因此就不再去分析那個PPT了。

3、Teaching Machines To Fish
      在QCon San Francisco上，eBay分享了這個PPT，這個PPT重點在於分享了eBay的智能化方面的工作，包括智能的推薦、使用者請求的智能回答等，實現的 策略方面主要是基於對使用者資料的收集和分析，這個部分由於主要是使用者資料分析的模型，在PPT中沒有做過多的介紹，但從PPT中也可以看出，eBay為了 改進搜尋的效果付出了很大的努力，以儘可能的達到讓使用者最快的搜到自己想要的東西，這其實很難做到，例如同樣一個使用者搜尋同樣一個單詞，期待的結果有可能 是不同的。

eBay的這三個PPT都非常的經典，不得不說，這種分享精神也是值得敬佩的，畢竟這都是eBay的發展曆程中摸索出來的，分享出來必然能讓很多碰到類似問題的網站少走很多的彎路，來說說我自己從旁觀者的角度看eBay的發展曆程。
從eBay的這幾個PPT來看，我覺得可以看出，eBay的技術其實在2006年就已經基本成型，而其發展過程也可以看做是互連網行業技術發展的一個縮影。
隨著訪問量的增長、資料量的增長以及功能的不斷增長，"分"基本成為了第一招救命招，而這招要做到其實不如想象中簡單，通常涉及到緩衝技術、應用的拆分、 eBay提及的同步SOA和非同步EDA、資料庫的拆分（分庫、分表）、檔案儲存體的拆分、負載平衡等，這些對技術的要求都很高，網站發展到了這一步後通常就 逐步顯示出技術的重要性了。
eBay在進行"分"的同時以及之後，在自動化以及可用性的提升方面也做出了很大的努力，這包括了部署系統、優雅降級、監測、系統容錯、自適應配置等的動作。
到了後面的階段，eBay開始投入了更多的精力在智能化的領域。
從上面這三個階段來看，可以認為"分"-->自動化-->智能化是互連網技術發展的一個常見發展模式，當然，這其中涉及到了非常多的技 術，eBay的PPT確實為我們分享了很多這方面的技術，而我同時覺得除了智能化以外，虛擬化或者雲端運算、節能技術也將成為後續互連網技術的重點，也許在 後面各類大會上我們會更多的看到這方面的知識，當然，目前也有一些在這方面領先的公司，例如Google、Amazon等。