eBay的網(wǎng)站架構(gòu)有哪些技術(shù)特點(diǎn)

本篇內(nèi)容介紹了“eBay的網(wǎng)站架構(gòu)有哪些技術(shù)特點(diǎn)”的有關(guān)知識，在實(shí)際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

eaby技術(shù)架構(gòu)變遷

ebay的系統(tǒng)架構(gòu)的變遷主要經(jīng)歷了4個階段，下面一幅圖展現(xiàn)了ebay系統(tǒng)架構(gòu)變遷的時間表

在ebay的V1版本，ebay采用的是FREEBSD + APACHE + PERL +DGBM，這是一個比較原始的模型，而且相對比較簡單，操作系統(tǒng)，應(yīng)用服務(wù)器，web服務(wù)器 以及 數(shù)據(jù)庫服務(wù)器都是在同一臺機(jī)器中，網(wǎng)絡(luò)結(jié)構(gòu)在物理上只有一層。整個網(wǎng)站有四個域名，每個域名對應(yīng)不同的應(yīng)用，每組應(yīng)用對應(yīng)一臺服務(wù)器。

圖表 1 ebayV1系統(tǒng)架構(gòu)
隨著業(yè)務(wù)量以及訪問量的不斷上升，ebay在1999年開始對架構(gòu)進(jìn)行升級，技術(shù)架構(gòu)發(fā)生了較大的變化，這期間主要是從1999-2004年，而架構(gòu)的版本號則從V2.0到V2.5 ，下面我們來看看Ebay V2.0技術(shù)架構(gòu)

V2.0
開始采用ORACLE服務(wù)器，數(shù)據(jù)庫服務(wù)器和web服務(wù)器分開，數(shù)據(jù)庫獨(dú)立部署到一臺新的機(jī)器上面

程序邏輯上面已經(jīng)開始分層，也就是我們常說的mvc3層結(jié)構(gòu)：顯示層、業(yè)務(wù)邏輯層、數(shù)據(jù)訪問層，而在物理上面還是兩層結(jié)構(gòu) web服務(wù)器 以及 數(shù)據(jù)庫服務(wù)器

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

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

數(shù)據(jù)庫部署到性能更加好的服務(wù)器上面

V2.2
增加了一臺數(shù)據(jù)庫服務(wù)器作為 備份服務(wù)器，防止失敗

V2.3
這個版本只是對每個應(yīng)用增加了更多的服務(wù)器，不斷的進(jìn)行server pool

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

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

圖表 2 ebayV2系統(tǒng)架構(gòu)

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

V3
整個應(yīng)用程序開發(fā)平臺全部替換為j2ee平臺，用java改寫了整個網(wǎng)站?？磥硎且淮伪容^大的工作。目的是為模塊解耦 以及模塊復(fù)用，從這里，我們可以看出java在開發(fā)復(fù)雜企業(yè)應(yīng)用的優(yōu)勢。

V3版本在數(shù)據(jù)庫層面上面做了更加優(yōu)化的設(shè)計，ebay繼續(xù)在數(shù)據(jù)庫上面進(jìn)行優(yōu)化

垂直拆分?jǐn)?shù)據(jù)庫，按照 功能模塊 拆分為更多的子庫

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

在這里，ebay也在數(shù)據(jù)庫層給出了最佳實(shí)踐：

盡量減少數(shù)據(jù)庫CPU的消耗，例如不使用存儲過程，只使用少量的觸發(fā)器

減少數(shù)據(jù)庫層面的邏輯功能，例如數(shù)據(jù)轉(zhuǎn)化，組合，這些都放在邏輯層

減少動態(tài)SQL，主要是SQL中參數(shù)的動態(tài)生成功能，這一點(diǎn)，公司的DBA也在強(qiáng)調(diào)

盡可能的縮短數(shù)據(jù)庫的事務(wù)時間，盡可能早的結(jié)束事物

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

不使用分布式事務(wù)，看來分布式事務(wù)的確不使用高并發(fā)性的系統(tǒng)

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

下面看看ebay在應(yīng)用層面給出的最佳實(shí)踐

保持應(yīng)用層子系統(tǒng)完全是無狀態(tài)的，可以水平進(jìn)行無限擴(kuò)展以提高伸縮性，通過負(fù)載均衡服務(wù)器均等分配到各個子系統(tǒng)的實(shí)例池里面。

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

嚴(yán)格劃分系統(tǒng)的各個層面，表現(xiàn)層，業(yè)務(wù)邏輯層，服務(wù)集成層，DAO層，基礎(chǔ)設(shè)施層。

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

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

ebay的架構(gòu)特點(diǎn)：
Partition Everything

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

其實(shí)要做到恰到好處，也非常不容易，ebay按照業(yè)務(wù)功能水平劃分應(yīng)用，水平劃分?jǐn)?shù)據(jù)庫。這個在國內(nèi)好多網(wǎng)站都是這樣做，不足為奇了，不過水平劃分功能后，單個功能應(yīng)用的分割也大有文章可做。怎么劃分，很早以前ebay的架構(gòu)文檔說到這個事情。

在水平按照業(yè)務(wù)劃分?jǐn)?shù)據(jù)庫后可以再根據(jù)一定的規(guī)則劃分表數(shù)，其中規(guī)則有很多，可以按照主要業(yè)務(wù)生產(chǎn)者為引導(dǎo)進(jìn)行分割，所有數(shù)據(jù)跟隨生產(chǎn)者一起，至于什么規(guī)則可以各抒己見。

Asynchrony Everywhere

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

EBay的應(yīng)對策略為：事件驅(qū)動和pipeline、多播消息，涉及的技術(shù)為：消息中間件（無序、至少一次到達(dá)）、基于SRM技術(shù)的可靠多播。

Automate Everything

配置信息的動態(tài)化，涉及的技術(shù)：配置發(fā)布/訂閱機(jī)制的實(shí)現(xiàn)、機(jī)器學(xué)習(xí)。這個超級牛，不知道國內(nèi)有多少網(wǎng)站做到了，聽說淘寶做到了（呵呵）。

Remember Everything Fails

故障檢測和回滾

這個現(xiàn)在很多網(wǎng)站都做，不過ebay做地比較牛，ebay差不多每天有2TB 的日志，通過監(jiān)控事件作出有效的判斷和預(yù)警，淘寶也做得很好。

eBay的應(yīng)對策略為：異常后發(fā)消息、接收者獲取消息警報、按功能實(shí)現(xiàn)降級，保障核心功能的可用性，涉及的技術(shù)有：消息中間件、如何實(shí)現(xiàn)按功能降級。

Embrace Inconsistency

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

 Expect (R)evolution

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

Dependencies Matter

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

他們的應(yīng)對策略：服務(wù)拓?fù)涔芾?、設(shè)計上的控制（只允許依賴…）、客戶端承擔(dān)責(zé)任。

說到這點(diǎn)，不得不說下，客戶端承擔(dān)責(zé)任這點(diǎn)其實(shí)真的很重要，現(xiàn)在很多架構(gòu)都喜歡放在服務(wù)端上解決N多問題，但很多場合確實(shí)有必要放到客戶端去做，當(dāng)然，這也會帶來一些問題，例如升級等。

“eBay的網(wǎng)站架構(gòu)有哪些技術(shù)特點(diǎn)”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識可以關(guān)注億速云網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實(shí)用文章！