本文轉載自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等。