SAL*_*000 7 architecture design-patterns scalability java-ee
不能完全无状态的大型网站如何在Web层实现极高的可扩展性？
有像eBay和亚马逊这样的网站,不能完全无国籍,因为他们有购物车或类似的东西.将购物车中的每个项目编码到URL中是不可行的,也不可能将每个项目编码到cookie中并在每个连接处发送它.所以亚马逊只是将session-id存储到正在发送的cookie中.所以我理解eBay和亚马逊的Web层的可扩展性应该比谷歌搜索引擎的可扩展性要困难得多,谷歌搜索引擎可以将所有内容编码到URL中.
另一方面,eBay和亚马逊都大规模扩展.有传言说eBay上有大约15000个J2EE应用服务器.
这些网站如何处理这两者:极端可扩展性和状态？由于站点是有状态的,因此进行简单的DNS平衡是不可行的.因此可以假设这些公司有一个基于硬件的负载均衡器,如BigIP,Netscaler或类似的东西,这是该站点的单个IP地址背后的唯一设备.此负载均衡器将解密SSL(如果已编码),检查cookie并根据该cookie的会话ID决定哪个应用程序服务器持有该客户的会话.
但这不可能工作,因为没有一个负载均衡器可以处理数千个应用服务器的负载？我想,即使这些硬件负载平衡器也不能扩展到这样的水平.
此外,负载平衡正在为用户透明地完成,即用户不会转发到不同的地址,但仍然全部共同留在www.amazon.com.
所以我的问题是:是否有一些特殊的技巧可以实现像Web层的透明分片(通常不是数据库层)？只要未检查cookie,就无法知道哪个应用程序服务器正在举行此会话.
编辑:我意识到只需要透明度,如果需要对网站进行拼接和添加书签.例如,如果该站点仅仅是一个Web应用程序,比如飞机或火车票预订系统,那么将用户重定向到不同URL后面的特定Web服务器集群(例如a17.ticketreservation.com)应该没有问题.在这种特定情况下,仅使用多个应用服务器集群是可行的,每个应用服务器集群都在他自己的负载均衡器之后.有趣的是,我没有找到使用这种概念的网站. 编辑:我发现这个概念讨论在highscalability.com,这里的讨论是指由擂主的文章命名"Web 2.0应用程序的客户端负载平衡".雷朱使用交叉脚本来透明地进行客户端负载均衡.
即使存在书签,xss等缺点,我也认为对于某些特殊情况,这几乎是一个非常好的主意,即几乎无内容的Web应用程序,不需要被蜘蛛网或书签(例如机票预订)系统或类似的东西).然后就不需要透明地进行负载均衡.
可以从主站点到服务器进行简单的重定向,例如从www.ticketreservation.com重定向到17.ticketreservation.com.从那里,用户停留在服务器a17.a17不是服务器,而是集群本身,通过它可以实现冗余.
初始重定向服务器本身可以是负载均衡器后面的集群.这样,可以实现真正高的可伸缩性,因为www后面的主要负载均衡器仅在每个会话开始时被击中一次.
当然,重定向到一个不同的URL看起来非常讨厌,但与单纯的Web应用程序(它不需要被震垮,深层链接或深书签反正),这应该是只对用户的光学问题？
重定向集群可以轮询应用程序集群的负载并相应地调整重定向,从而实现平衡而不仅仅是负载分配.
简单的。Web 服务器是无状态的，并且是负载平衡的。保存会话数据的应用程序服务器（中间层）则不然。Web 服务器可以使用您的会话 ID cookie 来确定要联系的应用程序服务器。
Memcached 和 Microsoft 的 Velocity 正是解决这一需求的产品。
编辑：网络服务器如何知道要联系哪个应用程序服务器？这被嵌入到会话 ID 哈希中，并且通常可以按照您喜欢的方式完成。它可以很简单，就像您的会话 ID 是 server:guid 一样。不过， Memcached 的基础是哈希值。
重要的是客户端必须能够确定以无状态方式联系哪个应用程序服务器。最简单的方法是将其嵌入到密钥中，尽管注册表（可能在它自己的层上）也可以工作并且可以提供一定的容错能力。
Edit2：回顾一些Ebay采访，我可能对他们的实施细节有些错误。他们不做缓存，也不做中间层的状态。他们所做的是建立一个按功能分区的负载平衡中间层（应用程序服务器）。因此，他们将拥有一个服务器池，用于查看项目等。然后是另一个用于销售物品的池。
这些应用程序服务器有一个“智能”DAL，可路由到分片数据库（按功能和数据进行分区，因此数据库 1 上的用户 AL、数据库 2 上的用户 MZ、项目 1 上的项目 1-10000 等）。
它们在中间层没有状态，因为它们是按功能分区的。因此，正常的用户体验将涉及多个应用程序服务器池。假设您查看一个项目 (ViewAppServerPool)，然后对一个项目 (BidAppServerPool) 进行出价。所有这些应用程序服务器都必须保持同步，这就需要分布式缓存来管理所有内容。但是，它们的规模如此之大，以至于没有分布式缓存可以有效地管理它，单个数据库服务器也不能。这意味着他们必须对数据层进行分片，并且任何缓存实现都必须跨越相同的边界进行分割。
这和我上面发布的类似，只是下移了一层。应用程序服务器决定联系哪个数据库，而不是让 Web 服务器确定要联系哪个应用程序服务器。只是，就 Ebay 而言，由于其分区策略，它实际上可能会访问 20 多个数据库服务器。但是，同样，无状态层具有某种用于联系有状态层的规则。然而，Ebay 的规则比我上面解释的简单的“User1 is on Server10”规则要复杂一些。