Ebay架構特點(HPTS 2009)

在HPTS 2009上，ebay 架構師Randy Shoup又列出了五個lessions.它們分別是： 1 Expect (R)evolution 2 Dependencies Matter 3 Be Authoritative 4 Never Enough Data 5 Custom Infrastructure 我結合ebay以前的5個lessions,總結一下可伸縮性和高性能的系統架構的一些最佳的實踐: 一 Partition Everything 在一個大型的系統架構和設計當中，我們會面臨各種各樣的挑戰，而爲了能使得系統具有良好的可伸縮性，我們就需要“切分系統的每個部分”，而這裏的切分又設計到一些方向性或者是策略性的問題，也就是如何切分，從什麼方向入手去切分，我結合Ebay架構師的經驗以及自己的想法，總結如下。 1 垂直切分 說到垂直切分，我們能第一時間想到的就應該是系統的分層架構，一個系統可以分爲好幾個層次，比如在目前J2EE系統的開發當中，我們一般都會分爲表現層，應用層（負責業務邏輯的封裝），領域模型層（負責業務邏輯的實現),和持久層（負責對底層數據源的訪問），按照分層的思想切分以後，系統的每一個層都是高內聚的，同時層與層之間也是低耦合的，這就符合了高內聚和低耦合的原則，這樣以來系統的各個層次可以獨立的進行維護，擴展和伸縮。分層的好處還可以參見我的一篇文章：系統爲什麼要分層？ 2 水平切分 當系統按照分層原則分爲幾個層次以後，雖然層與層之間實現了好的解耦，從而容易維護和伸縮，但是隨着負載的增大，單個層的伸縮也會遇到瓶頸，而這個時候就需要水平的切分各個層次，這裏又可以按照邏輯功能的水平切分和存儲或者數據的水平切分。 2.1 應用水平切分 在一個大型的系統中往往會涉及到很多的錯綜複雜的邏輯，這個時候架構師就需要根據不同的功能對系統進行水平的分割，比如按照用戶，商品，交易，搜索等功能進行水平的分割。而在具體架構和設計的過程中，我們一般通過不同的jar,bundle等來進行分割。 在按照功能進行切分以後，我們還需要注意一點就是儘量採用無狀態的架構，因爲系統的伸縮性很大部分上取決於你的應用的狀態如何保存，因此無狀態的架構對於水平的切分很重要，只有儘量的採用了無狀態的架構以後，我們的系統纔可以能更好的進行水平的伸縮。 2.2 存儲水平切分 一個大型的系統往往會有非常巨大的數據量，這個時候就需要對數據也進行切分，比如將數據分爲用戶數據庫，交易數據庫，商品數據庫等。在對數據按照功能進行切分以後，我們還可以對其進行進一步的切分，此時一般採用“Shard”技術，比如將前100W條記錄保存一臺主機上，然後依次類推。 二 Abstract and Virtualize at all Levels 在第一條"Partition Everything"中，我們將切分融入了系統的血液當中，這樣也就使得系統具有了良好可伸縮性的血液，但是在切分以後，也給系統帶來了其它的問題，比如在存儲層面上，因爲我們將數據按照功能進行了水平的切分，這樣以來就使得數據的訪問複雜了起來，這個時候就需要對數據訪問層進行合理化得抽象和虛擬化，使得物理上分割的數據庫對外界來說是一個統一的整體，而此時一般我們可以採用DAL技術。 在Ebay的系統中，搜索是系統很重要的構成部分，一般用戶的一次搜索都需要通過一個聚合器對搜索結果的進行整合，對於外界來說通過聚合器封裝和抽象了搜索系統。 因此抽象和虛擬化使得系統的伸縮性的實現更加容易和方便，它使得伸縮性的系統更加方便管理和維護。 三 Asynchrony Everywhere 目前J2EE其實都是同步的API(JMS除外），同步必然帶來組件與組件之間的緊耦合，而組件之間的耦合度越高，也就不能獨立對其進行伸縮，從而影響到伸縮性。假如系統中A組件調用了B組件，從基本的數理邏輯來看，如果A可以用，那麼B可以用，反過來，如果B不可以用，那麼A也不可以用，這就是同步調用給系統可用性帶來的損失。因此只有通過一種鬆耦合的方式對組件進行解耦，這樣才能使得系統具有好的可用性和伸縮性，而通過異步的方式是一種比較好的解耦的方式。關於異步大家可以參考一下這篇文章：Java EE meets Web 2.0 Ebay將異步這條原則貫徹的非常徹底。在組件內部使用SEDA來實現異步性，組件和組件之間的交互也儘量的採用異步，將業務程分爲很多個階段，各個階段通過異步的方式連接起來。在Ebay中，異步主要用了Event Queue和消息多播等技術。 說到這裏，我也想說說目前比較流行的DDD如何引入異步，在傳統的J2EE開發當中，業務邏輯實現都是在action或者service，業務邏輯的實現是通過action和service這些技術的組件來驅動的，而採用領域驅動設計以後，業務邏輯的操作是由Model驅動的，Model觸發Domain Event，然後異步的驅動技術性的組件來完成對Domain Event的響應，這樣以來整個系統的核心就是Domain Model，而各種的技術性的組件僅僅是一種爲Domain Model服務的tools。Domain Model和Domain Event的結合可以參見下圖： 四 Avoid Distributed Transactions 事務和性能，伸縮性是相互矛盾的，系統中事務用的越多，那麼性能和伸縮性就會變得越差，因此必須合理化得利用事務。尤其是傳統的分佈式事務，採用2PC來提交，這樣就要求所有事務性的資源必須都準備好，只要一個有問題，那麼整個事務都會受到限制，更嚴重的是2PC是非常影響性能和伸縮性的。從Ebay的架構中也可以看的出來，Ebay堅決的杜絕分佈式事務。如果不採用傳統那種分佈式事務，那麼採用什麼樣的事務策略呢？答案就是BASE策略。 在說BASE策略之前，我們有必要來了解一下Eric Brewer大叔的CAP理論，CAP是Consistency,Availability,Partition_tolerance的縮寫，Consistency表示系統的狀態對所有的Client都是即時一致的。Availability表示系統的可用性，它主要是指任何一個業務操作都能在預定的時間內完成。最後一項Partition_tolerance表示分區容錯性，它主要是指業務操作不能受單個系統組件的影響，即使某一些組件不能使用，業務操作也必須完成。理解了CAP理論的這三個方面以後，我們來看看CAP理論到底告訴了我們什麼,CAP告訴我們，任何一個分佈式系統不可能同時滿足這三個條件，最多隻能同時滿足兩個（是不是有點失望*^__^*). 我們現在明白了CAP，那麼BASE是什麼？它和傳統的ACID又有什麼區別和聯繫呢？接着往下看，你就會明白啦呵呵。BASE是basically available,soft state,eventually consistent的縮寫，BASE表示基本可用，事務軟狀態和最終一致性。BASE採用一種樂觀策略，它不要求事務狀態的即時一致性，而是要求一種最終一致性，也就是說事務狀態在某一個用戶可以接受的範圍內是不一致的，但是最終會變的一致，而傳統的ACID事務策略採用一種悲觀的方式，它要求事務狀態在業務操作結束以後必須是即時一致的，是一種Hard state，一種面向連接的狀態，炫繃得越緊越容易斷，事務也是一樣的，ACID這跟炫也非常容易斷，但是無論是BASE還是ACID都無法擺脫CAP的限制，BASE通過一種事務的軟狀態和弱一致性換來了可用性，同時也滿足分區容錯性，而ACID採用了強的一致性，而犧牲了可用性。因此BASE適合於對可用性最求大於一致性需求的場合，而ACID適合於對一致性要求很嚴格的場合，比如一些股票軟件系統就適合ACID。最後，如果大家對BASE和ACID還是不理解的話，推薦大家看看Dan Pritchett大哥的這篇文章：BASE: An Acid Alternative 五 Cache 緩存存在的地方很多，系統中用緩存的方式也有很多方式，我這裏僅僅說說我自己的理解，這些也是我目前公司的項目中所運用的方式。 我這裏主要說一下緩存如何和領域模型進行結合使用。在傳統的軟件開發中，我們一般採用action -->service-->Dao中，系統的業務邏輯充斥在action或者Service裏面，最終的結果就是action和service非常龐大，非常的難於理解，尤其是在設計到事務的時候，到項目後期，你會發現事務配置在action和service都不合適，這都是傳統的SSH傳統的開發帶來的負面影響。那麼採用DDD以後，業務邏輯的實現是通過Domain model驅動技術組件去完成功能，所有的業務邏輯都被封裝在了Domain Model裏面，但是這樣也帶來一個問題，Domain model一般聚合了很多的東西，如果我們用完了就是把它扔掉，那麼每次從持久層構建它是非常耗費性能的，因此這就需要將其放在某一個地方，這個地方就是緩存。當然了隨着目前KEY-VALUE存儲系統的不斷髮展，以後我們可以直接用KEY-VALUE存儲系統來講Domain Model保存起來。如果大家對於Domain model爲什麼要聚合很多東西，爲什麼也不能聚合不該聚合的東西，請大家參考另外一篇文章：Improving performance and scalability with DDD 六 Not Only SQL 對象和關係數據庫很矛盾，這個經常來本站的人應該都清楚。我就不多說了，目前隨着KEY-VALUE存儲系統的逐漸成熟和普及，我想一種：面向業務的分析和設計（DDD)+面向業務的存儲（KEY-VALUE)的新的架構方式也將會誕生。 七 Embrace Inconsistency 這一點其實也還可以算是一致性和性能，伸縮性，高可用性之間的博弈 八 Automate Everything 九 Remember Everything Fails 十 Expect (R)evolution 十一 Dependencies Matter 十二 Be Authoritative 十三 Never Enough Data 十四 Custom Infrastructure 轉帖自：http://www.jdon.com/jivejdon/thread/37753