judicious use of server-side state
no server affinity
functional server pools
horizontal and vertical database partitioning
下面是關於伺服器狀態的引用：
基本上我們沒有真正地使用server-side state。我們可能使用它，但現在我們並沒有找到使用它的理由。....。如果需要狀態化的話，我們把狀態放到資料庫中;需要的時候我們再從資料庫中取。我們不必使用集群。也就不用為集群做任何工作。
總之，你自己不必為架構一台有狀態的伺服器所困擾，更進一步，忘掉集群，你不需要它。現在看看功能劃分：
我們有一組或者一批機器，上面執行的應用是某個具體的use case，比如搜尋功能有他們自己的伺服器群，我們可以採用不同的調優策略，原因是瀏覽商品這個基本上是唯讀的用例和賣一件商品這個讀寫的用例在執行的時候是不同。在過去四五年我們一直採用水平資料庫劃分達到我們需要的可用性和線性擴充套件性。
總之，不要把你的應用和資料庫放在乙個giant machine，僅僅使用servers pools，每個pools對應乙個use case. 聽起來是否類似google的策略。
下面是關於水平劃分的一些介紹：
基於內容的路由可以實現系統的水平線性擴充套件。所以，想象一下，如果ebay某天擁有6000萬種商品，我們不必把這些資料儲存到一台超級sun伺服器上。.....也許我們可以把這些資料庫放到許多臺sun伺服器,但是我們怎麼取到我們需要的資料呢？ebay提出了基於內容路由的方法. 這種方法通過一定的規則，從20臺物理伺服器中找到我需要的資料。更cool的事情是這裡還定義了failover的策略。
最後，下面一句話描述了未來採用更加鬆散耦合的架構：
使用訊息系統來耦合不同的use case是我們研究的內容。
總之，ebay和google的例子表明以use-case為基礎組成的伺服器pools的架構比幾個大型計算機證明是具有更好線性擴充套件性的和可用性。當然，廠商害怕聽到這樣的結論。然而，部署這麼多伺服器的最**煩是如何管理好他們。-)
我的總結：
ebay
採用設計模式達到ebay
架構的分層，各層（表示層、商業邏輯層、資料訪問層）之間鬆散耦合，職責明確，分層提高了**的擴充套件性和程式開發的效率。
ebay
層以及伺服器基於use cases
劃分，達到應用之間的鬆散耦合，提高系統的線性擴充套件性。
為什麼要求系統具有可線性擴充套件，目的就是當**的訪問量
上公升的時候，我們可以不用改動系統的任何**，僅僅通過增加伺服器就可以提高整個**的支撐量。
eBay架構的思想金礦
judicious use of server side state no server affinity functional server pools horizontal and vertical database partitioning 下面是關於伺服器狀態的引用 基本上我們沒有真正地使用...
eBay架構的思想金礦
judicious use of server side state no server affinity functional server pools horizontal and vertical database partitioning 下面是關於伺服器狀態的引用 基本上我們沒有真正地使用...
eBay架構的思想金礦
judicious use of server side state no server affinity functional server pools horizontal and vertical database partitioning 下面是關於伺服器狀態的引用 基本上我們沒有真正地使用...