design-patterns - 分片(原文如此!)Web 层以防止负载均衡器瓶颈？

Question

无法完全无状态的大型网站如何在 Web 层实现极致的可扩展性？

有像 eBay 和亚马逊这样的网站，它们不能完全无状态，因为它们有购物车或类似的东西。将购物车中的每件商品都编码到 URL 中是不可行的，将每件商品编码为 cookie 并在每次连接时发送它也是不可行的。所以亚马逊只是将 session ID 存储到正在发送的 cookie 中。所以我明白 eBay 和 Amazon 的 web 层的可扩展性应该比谷歌搜索引擎的可扩展性难得多，谷歌搜索引擎的所有内容都可以被编码到 URL 中。

另一方面，eBay 和亚马逊的规模都非常庞大。有传言说 eBay 上有大约 15000 个 J2EE 应用服务器。

这些站点如何同时处理:极端的可扩展性和状态性？由于站点是有状态的，所以做一个简单的 DNS 平衡是不可行的。所以人们会假设这些公司有一个基于硬件的负载平衡器，比如 BigIP、Netscaler 或类似的东西，它是该站点单个 IP 地址背后的唯一设备。此负载均衡器将解密 SSL(如果已编码)，检查 cookie 并根据该 cookie 的 session ID 决定哪个应用程序服务器保存该客户的 session 。

但这不可能工作，因为没有一个负载平衡器可以处理数千个应用程序服务器的负载？我想即使是这些硬件负载平衡器也不会扩展到这样的水平。

此外，负载平衡对用户来说是透明的，即用户不会被转发到不同的地址，但仍会一直集中在 www.amazon.com 上。

所以我的问题是:是否有一些特殊的技巧可以实现诸如 Web 层(而不是通常所做的数据库层)的透明分片之类的事情？只要不检查 cookie，就无法知道哪个应用程序服务器正在保存此 session 。

编辑:我意识到，如果需要对站点进行爬行和书签，则只需要透明度。例如。如果该站点仅仅是一个 Web 应用程序，例如飞机或火车票预订系统，那么只需将用户重定向到不同 url 后面的特定 Web 服务器集群应该没有问题，例如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 背后的主要负载均衡器仅在每个 session 开始时被命中一次。

当然，重定向到不同的 url 看起来非常讨厌，但是对于单纯的 Web 应用程序(无论如何都不需要蜘蛛网、深度链接或深度书签)，这应该只是用户的视觉问题吗？

重定向集群可以轮询应用集群的负载并相应地调整重定向，从而实现平衡而不仅仅是负载分配。

Answer 1

您可能会发现以下论文很有用，该论文介绍了高度可用的键值存储系统的设计和实现，亚马逊的一些核心服务使用该系统来提供“永远在线”的体验:

Giuseppe DeCandia、Deniz Hastorun、Madan Jampani、Gunavardhan Kakulapati、Avinash Lakshman、Alex Pilchin、Swami Sivasubramanian、Peter Vosshall 和 Werner Vogels，“ Dynamo: Amazon's Highly Available Key-Value Store ”，在第 21 届 ACM 操作系统原则研讨会论文集，华盛顿州史蒂文森，2007 年 10 月。