爲了防止負載平衡器瓶頸，分層（原文如此！）Web層？

Question

無法完全無狀態的大型網站如何在Web層實現極高的可伸縮性？

有像eBay和亞馬遜這樣的網站，不能完全無國籍，因爲他們有一個購物車或類似的東西。將購物車中的每件商品都編碼到URL中是不可行的，也不可能將每件商品都編碼到cookie中並在每個連接處發送它。因此，亞馬遜只是將session-id存儲到正在發送的cookie中。所以我明白，eBay和亞馬遜的網絡層的可擴展性應該比谷歌搜索引擎的可擴展性要難得多，在谷歌搜索引擎中，所有東西都可以編碼到URL中。

另一方面，eBay和亞馬遜都絕對大規模擴展。有傳言說eBay上有15000個J2EE應用服務器。

這些網站如何處理這兩個問題：極高的可伸縮性和狀態性？由於該網站是有狀態的，因此執行簡單的DNS平衡並不可行。所以人們會認爲這些公司有一個基於硬件的負載均衡器，比如BigIP，Netscaler或類似的東西，這是該站點單一IP地址背後的唯一設備。此負載均衡器將解密SSL（如果編碼），檢查該cookie並根據該cookie的會話ID來決定哪個應用程序服務器持有該客戶的會話。

但是，這不可能正常工作，因爲沒有單個負載平衡器可能處理數千個應用程序服務器的負載？我會想象，即使這些硬件負載平衡器也不會擴展到這樣的水平。

另外，負載平衡是爲用戶透明地完成的，即用戶不會被轉發到不同的地址，但仍然全部集體地一直停留在www.amazon.com上。

所以我的問題是：是否有一些特殊的技巧，可以實現像Web層的透明分片（而不是數據庫層）？只要未檢查cookie，就無法知道哪個應用程序服務器正在進行此會話。

編輯：我意識到只需要透明度，如果有需要蜘蛛和書籤的網站。例如。如果該網站僅僅是一個網絡應用程序，例如飛機票或火車票預定系統，那麼只需將用戶重定向到位於不同URL之後的特定網站服務器羣即可，例如， a17.ticketreservation.com。在這種特定情況下，僅使用多個應用程序服務器集羣是可行的，每個應用程序服務器集羣都在自己的負載平衡器後面。有趣的是，我沒有找到使用這種概念的網站。 編輯：我發現這個概念discussed在highscalability.com，這裏的討論是指雷珠的一篇文章命名爲"Client Side Load Balancing for Web 2.0 Applications"。雷珠用透明腳本來透明地做這個客戶端負載平衡。

即使存在缺陷，如書籤，xss等，我認爲這對於某些特殊情況聽起來像是一個非常好的主意，即幾乎無需內容的web應用程序，這些應用程序不需要被蜘蛛或書籤（例如票務預訂系統或類似的東西）。那麼就不需要透明地進行負載平衡。

可能存在從主站點到服務器的簡單重定向，例如，從www.ticketreservation.com重定向到a17.ticketreservation.com。從那裏用戶停留在服務器a17。 a17不是服務器，而是集羣本身，可以實現冗餘。

初始重定向服務器本身可能是負載均衡器後面的集羣。這樣，可以實現非常高的可擴展性，因爲www後面的主要負載均衡器在每個會話開始時只被擊中一次。

當然，重定向到不同的URL看起來非常討厭，但對於單純的Web應用程序（無論如何不需要被蜘蛛，深層鏈接或深藏書籤），這應該只是用戶的光學問題？

重定向集羣可以輪詢應用集羣的負載並相應地調整重定向，從而實現平衡而不僅僅是負載分佈。

Answer 1

Ea SY。無狀態的Web服務器負載均衡。持有會話數據的應用程序服務器（中間層）不是。 Web服務器可以使用您的會話ID cookie來確定要聯繫的應用程序服務器。

Memcached和微軟的Velocity是解決這個確切需求的產品。

編輯：Web服務器如何知道要聯繫哪個應用程序服務器？這嵌入到會話ID哈希中，並且可以按照您的喜好一般地完成。它可以像你的會話ID是server：guid一樣簡單。儘管如此，Memcached的基礎是散列。

重要的一點是，客戶端必須能夠找出無狀態聯繫的應用服務器。最簡單的方法是將其嵌入到密鑰中，儘管註冊表（可能在其自己的層上）也可以工作，並且可以提供一些容錯功能。

編輯2：回到some Ebay interviews，我可能已經得到他們的執行細節有點不對。他們不做緩存，他們不在中間層做狀態。他們所做的工作是按功能劃分負載平衡的中間層（應用程序服務器）。所以，他們會有一個服務器池，例如查看物品。然後另一個銷售物品池。

這些應用程序服務器有一個路由到分片數據庫的「智能」DAL（由功能和數據分區，因此Database1上的用戶A-L，Database2上的用戶M-Z，Items1上的項目1-10000等）。

它們在中間層沒有狀態，因爲它們是按功能分區的。因此，普通的用戶體驗將涉及超過1個應用服務器池。假設您查看某個項目（ViewAppServerPool），然後對項目（BidAppServerPool）進行出價。所有這些應用程序服務器都必須保持同步，然後需要分佈式緩存來管理所有內容。但是，它們的規模非常大，沒有分佈式緩存可以有效地管理它，單個數據庫服務器也無法進行管理。這意味着他們必須分割數據層，並且任何緩存實現都必須跨越相同的邊界進行分割。

這是類似我以上貼的東西，只是向下移動了一層。應用程序服務器決定與哪個數據庫聯繫，而不是讓Web服務器確定要聯繫哪個應用程序服務器。只有在Ebay的情況下，由於其分區策略，它實際上可能會擊中20多個數據庫服務器。但是，無狀態層又有一些它用來聯繫有狀態層的規則。然而，Ebay的規則比我上面解釋的簡單化的「User1在Server10上」的規則要複雜一些。

Answer 2

你可能必須要對工程團隊在這些地方之一，肯定知道，但還有誰已經從談判等信息做出的猜測已經走出兩地的人：

Ebay Architecture和Amazon Architecture

只是一個單一的負載本身在今天的世界平衡器一種DNS輪過去幾年的知更鳥的當量。今天，你有像anycast這樣的東西，讓你玩各種技巧。你可以很確定ebay和amazon這樣的喜歡使用負載平衡器，並且他們使用了很多。

您可能要多一點，當你想想它可能是如何工作的，因爲很多的流量是無狀態的熬下來。在一個頁面的單個請求中，可能有很多不需要了解狀態的對象。通過從無狀態系統提供服務，將這些對象從圖片中提取出來（這就是選播進來的地方），並且請求數量急劇下降。

如果不能讓你一個單一的負載均衡器可以處理負載點那麼接下來的一步就是要打破交易了使用IP路由和/或地理DNS。 eBay和亞馬遜這樣龐大的網站將分佈在衆多不同的數據中心中，每個數據中心都有大量的互聯網連接。你把所有來自互聯網流行任務西部的東西發送到西海岸數據中心的「任務」服務器，任何東西都從西部海岸數據中心「att」服務器發送到任何東西，東海岸數據中心「追求」服務器等等。這些系統中的每一個都可能是一個可以處理負載的單個負載均衡器，一些負載均衡器可以處理數十萬次甚至SSL加密的事務。在背面，您會不斷向每個數據中心批量複製數據，但它可能不同步。

Answer 3

您可能會發現有用的下列文件，該文件提出了一個高度可用的鍵 - 值存儲系統的設計和實施，一些亞馬遜的核心服務使用提供一個「永遠在線」的體驗：

朱塞佩DeCandia，德尼茲Hastorun，馬丹Jampani，Gunavardhan Kakulapati，阿維納什拉克什曼，亞歷克斯Pilchin，斯瓦米Sivasubramanian，彼得Vosshall和沃納·博赫爾斯「Dynamo: Amazon's Highly Available Key-Value Store」，在21 ACM研討會作業系統原理，史蒂文森，華盛頓的議事程序， 2007年10月。

Answer 4

我不知道他們是如何做到這一點，但這裏有一些建議：

• 爲了避免超載負載平衡器主機本身，使用循環DNS或
• 重定向不同客戶的不同基於負載，設置，地理位置等簇地址

要分發中間層負載，

• 將會話ID cookie中的中間層會話服務器的ID嵌入 - 如其他人所建議的那樣。這種方式你打哪個前端框是無關緊要的，他們可以添加/刪除沒有任何影響。
• 如果它足夠重要，在會話期間有一種將客戶端重定向到替代中間層服務器的機制，這樣可以將其中的一個關閉以進行維護等。
• 客戶開始使用新落成的中間層服務器，因爲他們開始一個新的會話

要分發後端數據庫負載

的每個帳戶或每「實時」
• 「傳統的」分片用戶數據
• 異步複製緩慢變化或相對靜態的數據;用戶可能會看到它過時（但大部分時間不會太多）。中間層和Web服務器連接到本地到自己的位置的數據庫