Design patterns 切分（原文如此！）web层以防止负载平衡器瓶颈？

无法完全无状态的大型网站如何在web层实现极端的可伸缩性

有些网站像eBay和Amazon，它们不能完全无状态，因为它们有购物车或类似的东西。将购物车中的每个项目编码到URL中是不可行的，将每个项目编码到cookie中并在每个连接处发送也是不可行的。因此Amazon只是将会话id存储到正在发送的cookie中。因此，我知道eBay和Amazon的web层的可伸缩性应该比google搜索引擎的可伸缩性要困难得多，在google搜索引擎中，所有内容都可以用restful编码到URL中

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

这些站点如何处理这两个问题：极端的可伸缩性和状态性？由于站点是有状态的，所以进行简单的DNS平衡是不可行的。因此，我们假设这些公司有一个基于硬件的负载平衡器，比如BigIP、Netscaler或类似的东西，它是该站点单一IP地址后面的唯一设备。此负载平衡器将解密SSL（如果已编码），检查cookie，并根据该cookie的会话id决定哪个应用程序服务器持有该客户的会话

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

此外，负载平衡对用户来说是透明的，即用户不会被转发到不同的地址，但所有用户始终都在www.amazon.com上

所以我的问题是：是否有一些特殊的技巧可以实现web层（而不是通常的数据库层）的透明切分？只要未检查cookie，就无法知道哪个应用程序服务器正在进行此会话

编辑：我意识到，如果需要对网站进行加密和添加书签，那么只需要透明度。例如，如果该网站仅仅是一个web应用程序，比如飞机或火车票预订系统，那么将用户重定向到不同URL后面的特定web服务器集群应该没有问题，例如a17.ticketreservation.com。在这种特定情况下，只使用多个应用服务器集群是可行的，每个集群都位于自己的负载平衡器后面。 有趣的是，我没有找到一个使用这种概念的网站。 编辑：我是在找到这个概念的，这里的讨论涉及到了朱磊写的一篇名为的文章。Lei Zhu使用交叉脚本透明地完成客户端负载平衡

即使存在一些缺点，比如书签、xss等，但我确实认为这对于某些特殊情况来说是一个非常好的主意，即几乎没有内容的web应用程序，这些应用程序不需要被加密或添加书签（例如机票预订系统或类似的东西）。这样就不需要透明地进行负载平衡

可能存在从主站点到服务器的简单重定向，例如从www.ticketreservation.com重定向到a17.ticketreservation.com。从那里开始，用户停留在服务器a17。a17不是一个服务器，而是一个集群本身，通过它可以实现冗余

初始重定向服务器本身可以是负载平衡器后面的集群。这样，就可以实现真正高的可伸缩性，因为www背后的主负载平衡器在每个会话开始时只被命中一次

当然，重定向到不同的URL看起来非常糟糕，但是对于仅仅是web应用程序（无论如何都不需要插入、深度链接或深度书签），这应该只是用户的一个视觉问题

---

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

您可能必须在其中一个地方的工程团队中才能确定，但有些人从这两个地方的谈话和其他信息中做出了有根据的猜测：

及

在当今世界，仅仅一个负载平衡器本身就相当于多年前的DNS循环。今天，你可以玩各种各样的把戏。你可以非常肯定，ebay和amazon等公司确实使用了负载平衡器，而且它们使用了很多负载平衡器

在考虑它的工作原理时，您可能希望将其进一步简化，因为很多流量都是无状态的。在对页面的单个请求中，可能有许多对象不需要了解状态。通过从无状态系统（这就是anycast的用武之地）为这些对象提供服务，将它们从图中删除，请求数量将显著减少

如果这还不能使您达到单个负载平衡器可以处理负载的程度，那么下一步就是使用IP路由和/或geo DNS将事务分解。像易趣和亚马逊这样大的网站将位于多个不同的数据中心，每个中心都有大量的互联网连接。你把来自互联网流行音乐西部的所有信息发送到西海岸数据中心的“任务”服务器，从att西部的所有信息发送到西海岸数据中心的“att”服务器，从quest东部的所有信息发送到东海岸数据中心的“任务”服务器，这些系统中的每一个都可能是一个孤岛，一个可以处理负载的负载平衡器，有些负载平衡器每秒可以处理数十万个事务，甚至可以通过SSL加密。在你复制的背面