.NET上服务层的扩展策略

时间:2008-11-03 17:50:57

标签: .net scaling service-tier

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

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

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

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

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

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

关于如何解决此问题的任何想法?关于架构的任何其他想法?有没有其他人有过设计一个每天可能处理数百万次点击的网站的项目?

编辑:甚至不是一个想法? :(

1 个答案:

答案 0 :(得分:2)

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

在这种情况下,您描述了每个服务层实例都在进行自己的本地缓存的情况,每个新框都会降低缓存的实用性,因为每个实例必须从数据库中检索相同的数据以填充其即使另一个Service Tier实例刚刚访问了相同的数据,也会生成本地缓存。使用memcached或Velocity,缓存机制将智能地将所有服务器上未使用的RAM组合到一个缓存中,以便共享所有Service Tier安装。这样,只有第一个Service Tier实例访问一段数据才需要使用数据库,其他Service Tier实例的后续访问将从缓存中提取相同的数据。

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

希望这有帮助!

亚当