eaby技術架構變遷

ebay的系統架構的變遷主要經歷了4個階段，下面一幅圖展現了ebay系統架構變遷的時間表

在ebay的V1版本，ebay采用的是FREEBSD + APACHE + PERL +DGBM，這是一個比較原始的模型，而且相對比較簡單，操作系統，應用服務器，web服務器 以及 數據庫服務器都是在同一臺機器中，網絡結構在物理上只有一層。整個網站有四個域名，每個域名對應不同的應用，每組應用對應一臺服務器。

圖表 1 ebayV1系統架構
隨著業務量以及訪問量的不斷上升，ebay在1999年開始對架構進行升級，技術架構發生了較大的變化，這期間主要是從1999-2004年，而架構的版本號則從V2.0到V2.5 ，下面我們來看看Ebay V2.0技術架構

V2.0
開始采用ORACLE服務器，數據庫服務器和web服務器分開，數據庫獨立部署到一臺新的機器上面

程序邏輯上面已經開始分層，也就是我們常說的mvc3層結構：顯示層、業務邏輯層、數據訪問層，而在物理上面還是兩層結構 web服務器 以及 數據庫服務器

編程語言采用C++，那個時候java剛興起，估計也沒有其他好的語言選擇了。

V2.1
每組應用對應多臺服務器，而多臺服務器組成一個 servler pool(服務池)，通過一個負載均衡服務器來分別轉發請求到不同的服務器

數據庫部署到性能更加好的服務器上面

V2.2
增加了一臺數據庫服務器作為 備份服務器，防止失敗

V2.3
這個版本只是對每個應用增加了更多的服務器，不斷的進行server pool

V2.4
這個版本最大且最重要的改變就是對數據庫進行垂直拆分，即把數據庫按照不同的功能模塊進行劃分，例如交易庫，會員庫，帳務庫

V2.5
這個版本在2.4的版本上面，對部分數據庫進行讀寫分離，同時對Item(物品條目)數據庫進行水平拆分，把Items按照不同的Categoty分配到不同的Categoty商品庫里面，，這樣大大的擴展了對Items數據庫的訪問性能。

圖表 2 ebayV2系統架構

從上可以看出ebay V2的架構變遷，主要是通過服務器的添加，數據庫的垂直拆分以及水平拆分，數據庫的讀寫分離操作 來提高整個網站的性能。在web層，通過添加服務器來進行水平擴展，同時對應用服務功能進行垂直拆分，按照不同的業務功能劃分到不同的系統。在數據庫層面，進行了讀寫分離嘗試，對數據庫進行垂直拆分，同時把Items庫按照Category進行水平拆分，這樣做，分散了對產品庫items的集中訪問，不過需要在DAL層提供透明的訪問機制，ebays這里貌似還并沒有這個成熟的框架，同時不知道 分布式事務ebay在這個階段是如何實現的。

V3
整個應用程序開發平臺全部替換為j2ee平臺，用java改寫了整個網站。看來是一次比較大的工作。目的是為模塊解耦 以及模塊復用，從這里，我們可以看出java在開發復雜企業應用的優勢。

V3版本在數據庫層面上面做了更加優化的設計，ebay繼續在數據庫上面進行優化

垂直拆分數據庫，按照 功能模塊 拆分為更多的子庫

水平拆分數據庫，對同一類數據，按照key值的不同數據分配到不同的數據庫中（具體水平分庫的方式有多種，這里就不再介紹了。）在進行水平拆分數據庫的時候，ebay也必須建立一套透明的DAL訪問方式，必須提供透明的數據庫訪問機制以及透明的數據庫路由功能，數據庫的物理結構變更不會影響到代碼的邏輯變動。

在這里，ebay也在數據庫層給出了最佳實踐：

盡量減少數據庫CPU的消耗，例如不使用存儲過程，只使用少量的觸發器

減少數據庫層面的邏輯功能，例如數據轉化，組合，這些都放在邏輯層

減少動態SQL，主要是SQL中參數的動態生成功能，這一點，公司的DBA也在強調

盡可能的縮短數據庫的事務時間，盡可能早的結束事物

盡可能的采用異步更新數據庫方式，分散數據庫的壓力，例如消耗數據庫時間的操作要放在夜間處理。

不使用分布式事務，看來分布式事務的確不使用高并發性的系統

在應用邏輯層面，ebay把系統按照功能劃分成許多不同的模塊，每個模塊作為一個子系統，同時通過水平擴展子系統服務器數量來提高整個系統的伸縮性。

下面看看ebay在應用層面給出的最佳實踐

保持應用層子系統完全是無狀態的，可以水平進行無限擴展以提高伸縮性，通過負載均衡服務器均等分配到各個子系統的實例池里面。

盡可能的使用緩存，緩存能夠減少數據庫的壓力，使用空間來換時間

嚴格劃分系統的各個層面，表現層，業務邏輯層，服務集成層，DAO層，基礎設施層。

在應用層的設計上面，ebay通過不同的功能劃分了很多domain,每個domain只負責自己的功能的業務邏輯，domain與domain之間是不會依賴的，同時還會提供common domain 提供各個 domain之間的交互以及依賴，見下圖：

由于ebay的數據庫按照邏輯劃分了很多不同的字庫，那么ebay必須提供透明的訪問數據庫的能力，舉個例子：ebay把Items按照categoray分成了很多sub items庫，假如需要查詢出來某一個用戶所購買的所有Items，那么必須要查詢所有的sub items庫,把數據庫組合出來，那么DAL層必須屏蔽數據庫的物理結構，一次性的把所有的sub items庫中對應的數據查詢出來。而這個訪問，對應用來說是透明的。應用不需要關注到底items有多少個子庫。

ebay的架構特點：
Partition Everything

當一個網站剛開始時，可能一天只有幾十個人訪問，或者幾百個，可能一臺普通的服務器就足夠了，db和應用統統都可以放在一起，可是隨著用戶的增加，業務的增加，一臺服務器遠遠不夠了，就自然想增加服務器，系統應該跟隨改變。多一臺服務器，也就減輕了一臺壓力。這樣就出現了分割業務和分割數據。

其實要做到恰到好處，也非常不容易，ebay按照業務功能水平劃分應用，水平劃分數據庫。這個在國內好多網站都是這樣做，不足為奇了，不過水平劃分功能后，單個功能應用的分割也大有文章可做。怎么劃分，很早以前ebay的架構文檔說到這個事情。

在水平按照業務劃分數據庫后可以再根據一定的規則劃分表數，其中規則有很多，可以按照主要業務生產者為引導進行分割，所有數據跟隨生產者一起，至于什么規則可以各抒己見。

Asynchrony Everywhere

同步應用會帶來強耦合，可用性保障差，特別是在用戶體驗方面極度失敗，試想一個網站首頁要獲取那么多業務信息如果同步的話會流失很大一部份用戶，如果再加上網絡慢，等到蚊子都睡覺了，人哪里還有時間看，其實分布式系統應該盡量使用異步處理。

EBay的應對策略為：事件驅動和pipeline、多播消息，涉及的技術為：消息中間件（無序、至少一次到達）、基于SRM技術的可靠多播。

Automate Everything

配置信息的動態化，涉及的技術：配置發布/訂閱機制的實現、機器學習。這個超級牛，不知道國內有多少網站做到了，聽說淘寶做到了（呵呵）。

Remember Everything Fails

故障檢測和回滾

這個現在很多網站都做，不過ebay做地比較牛，ebay差不多每天有2TB 的日志，通過監控事件作出有效的判斷和預警，淘寶也做得很好。

eBay的應對策略為：異常后發消息、接收者獲取消息警報、按功能實現降級，保障核心功能的可用性，涉及的技術有：消息中間件、如何實現按功能降級。

Embrace Inconsistency

其實這個有點象我們整天說的“擁抱變化”。在系統中如果事務過多，極大影響性能，特別是分布式事務，如果一味追求一致性會嚴重性能，ebay的做法是過程不一致，最終一致。涉及的技術有：消息中間件、CAP（Consistency 一致性；Availability 可用性； Tolerance of network Partition 分區容忍性（可理解為部分節點故障或節點之間連接故障下系統仍可正常工作））等

 Expect (R)evolution

這里eBay講到的主要是如何更好的應對變化，這包括了功能演變、架構演變，eBay的應對策略為：靈活的schema、可插拔的處理流程以及增量的系統發布，這方面的技術還是相當復雜的，eBay采用的是：配置化處理流程、系統發布過程支持多版本共存。

Dependencies Matter

這點隨著分布式的應用和異步的應用，以及功能的不斷增加后，就會變得比較明顯，eBay也是如此。

他們的應對策略：服務拓撲管理、設計上的控制（只允許依賴…）、客戶端承擔責任。

說到這點，不得不說下，客戶端承擔責任這點其實真的很重要，現在很多架構都喜歡放在服務端上解決N多問題，但很多場合確實有必要放到客戶端去做，當然，這也會帶來一些問題，例如升級等。

總結：在大規模，高并發系統的設計中，最常用的技術就是分層和緩存，把一個業務流程垂直分解成幾個系統，每個系統提供不同類型的服務，一個業務流程通過不同的服務組裝起來，這就是SOA設計的思路吧。每個系統可以進行水平集群，提供無狀態的服務，可以水平無線擴展，數據庫層面，主要就是用到垂直分庫，水平分庫，讀寫分離，熱備份等技術，提高數據庫的讀寫能力。在應用層可以考慮使用集中式緩存或者分布式緩存來減少數據庫的訪問壓力。