设计决策 - 扩展基于Web的应用程序的体系结构

Question

这个问题是关于设计决策的。我目前正在开发一个网络项目，该项目将有4万用户，并且在几个月内预计将增长5千万用户（尽管不是并发用户）。我想要有一个可以轻松扩展而不需要太多努力的架构。

为了解释，我想使用一个微不足道的场景。比方说，用户实体和服务，如CreateUser，AuthenticateUser等，是页面控制器的简单方法调用。但是，一旦流量增加，例如，认证用户（或与用户实体相关的这类服务）必须被移出到不同的内部服务器以传播负载。但是同时在用户数为40K时通过网络使用RPC调用会变得过度。

我的建议是最初使用IPC，当我们需要扩展时，我们可以间接切换到基于TCP的RPC调用，以便它可以轻松扩展。例如，我指的是System.IO.Pipes.NamedPipeStreamServer开头，稍后再转到TcpListener。

如果我们有适当的设计可以封装上述方法，那么我们很容易将服务扩展到多个网络服务器，但同时避免在用户数较少时进行网络调用。

这是最好的方法吗？任何建议都会很棒..

注意：数据库缩放定义为第二阶段优化，因此我们已经制定了适当的架构设计，以便在流量增加时轻松分区数据。主要的瓶颈将是这段时间内的应用程序服务器。

Answer 1

如果你打算做的是（如果我正确地读了它的话）将认证和授权工作划分给中央服务器，那么我认为如果你尝试去做，你会发现可伸缩性方面的问题使用命名管道甚至低级别的TCP套接字。没有理由不能通过常规Web服务甚至基于TCP通道的WCF服务访问这些内部服务器。

我会走这条路线的原因是因为调用无状态Web服务（ASMX或WCF）将允许您使用“auth和auth”（身份验证和授权）服务器以及用户管理服务器（createuser等）在农场。因此，随着您对这些服务的访问量的增加，您可以扩展响应这些调用的服务器数量，而无需更改客户端代码。

Answer 2

根据我的经验，“你现在不需要它，所以不要在上面浪费精力”和“这里有龙”之间总是存在一种张力。

当需求出现时，您的缩放策略是使用特定的remotng技术将工作片段卸载到其他主机。听起来像它可能工作。 [顺便说一下，另一种方法是让同一事物具有许多并行实例，因此将所有事物保持在本地 - 我的直觉是，这可能会更好。但让我们坚持你的计划，现在...]

我的一般建议是早期攻击风险。因此，在这种情况下，您打算在将来使用远程技术卸载一些工作。增加这个新的（对你的系统）技术将有（至少）两个影响：

1. 新的故障模式
2. 延迟增加

哦，还有的（admitedly不太可能）可能性远程控制策略不起作用！您可能看不到您期望的扩展收益。表现非常不直观。

所以我在这里看到风险，我想要解决这个风险现在。即使没有必要，我会立即做远程处理。然后，您将对所有性能进行测试，测试增加的延迟时间以及测试失败模式的所有弹性。当压力关闭时，你正在做这件事，而用户人数很少。您也可以对实际的可伸缩性进行一些测试。

Answer 3

在我的一个旅游行业项目（每天约100万点击）中，我们有一个单独的auth服务器场。当时大约有四台负载均衡服务器。我们的业务层称为认证Web服务（asmx），传递用户凭证并获取XML结果。如果用户数量增加，我们可以进一步扩展auth场。通过http（在Intranet上）使用Web服务的恕我直言，给予比TCP更多的性能好处。