.NET 上的服务层扩展策略答案

【问题标题】：Scaling strategies for Service Tiers on .NET.NET 上的服务层扩展策略
【发布时间】：2008-11-03 17:50:57
【问题描述】：

我正在开发一个由许多模块化 Web 应用程序组成的 Web 产品。对最终用户来说，它似乎是一个单独的应用程序，尽管各种组件被分解成各自的应用程序。

这样做的部分原因是它可以轻松地跨多个应用程序服务器进行水平扩展。

为了便于数据层的水平扩展，我们计划在数据库前面使用 Web 服务层。该层可以扩展到 N 台机器，并且它的每个实例都将单独处理缓存。

这个想法是应用程序会调用服务层负载均衡器，它将调用分配给服务实例，然后使用其缓存返回数据，或连接到数据库并查询数据.看起来这将是无需大量修改应用程序代码即可扩展的最简单的前瞻性解决方案。

[N Amount of Databases]
         |
         \/
[Service Tier X N amount of Machines]
         |
         \/
[Application Tier X n amount of Machines]

但有些问题出现了，我想在服务级别保留用户会话，以便每个应用程序只使用令牌进行身份验证，但是我不确定如何在所有服务机器上维护会话数据没有单点故障。

关于如何实现这一点的任何想法？关于建筑的任何其他想法？有没有其他人参与过设计一个可能每天处理数百万次点击的网站的项目？

编辑：甚至没有想法？ :(

【问题讨论】：

标签： .net scaling service-tier

【解决方案1】：

您已经描述了分布式缓存机制的完美用例，例如 memcached (http://www.danga.com/memcached) 或即将推出的 MS Velocity 项目 (http://code.msdn.microsoft.com/velocity)。

在您描述的情况下，您有越来越多的服务层实例，每个实例都进行自己的本地缓存，缓存的有用性随着每个新框的增加而降低，因为每个单独的实例必须从数据库中检索相同的数据以填充其本地缓存，即使相同的数据刚刚被另一个服务层实例访问。使用 memcached 或 Velocity，缓存机制将智能地将所有服务器上未使用的 RAM 组合到一个缓存中，供所有服务层安装共享。这样只有第一个访问数据的服务层实例需要使用数据库，其他服务层实例的后续访问将从缓存中提取相同的数据。

这样做也回答了用户会话问题，因为您可以轻松地使用相同的缓存来存储用户会话的状态值，并且您的所有服务层实例都可以访问相同的信息。

希望这会有所帮助！

亚当

【讨论】：