这个问题是关于设计决定的。我目前正在开发一个将有40,000用户开始的网络项目，并且在几个月内预计将增加50M用户（尽管不是并发用户）。我希望有一个可以轻松扩展的架构，而不需要太多努力。
为了解释，我想使用一个简单的场景。可以说，用户实体和服务（如CreateUser，AuthenticateUser等）是页面控制器的简单方法调用。但是，一旦流量增加，例如，必须将用户（或与用户实体相关的此类服务）的身份验证移出到不同的内部服务器以分散负载。但同时，当用户数为40K时，通过网络使用RPC调用将变得过度。
我的建议是最初使用IPC，当我们需要扩展时，我们可以集中切换到基于TCP的RPC调用，以便它可以轻松扩展。例如，我指的是System.IO.Pipes.NamedPipeStreamServer开始，稍后再转到TcpListener。
如果我们有适当的设计可以封装上述方法，我们很容易将服务扩展到多个网络服务器，但同时避免在用户数量较少时进行网络呼叫。
这是最好的方法吗？任何建议都会很棒..
注意：数据库扩展绝对是第二阶段优化，因此我们已经进行了架构设计，以便在流量增加时轻松划分数据。主要瓶颈是应用程序服务器在这段时间内。
答案 0 :(得分：1)
如果您计划进行的操作（如果我正确阅读）将认证和授权工作分配到中央服务器，那么我认为如果您尝试使用它，那么您将发现可扩展性方面的问题命名管道甚至是低级TCP套接字。没有理由不通过常规Web服务甚至是基于TCP通道的WCF服务来访问这些内部服务器。
我之所以选择这条路是因为调用无状态Web服务（ASMX或WCF）将允许您创建“auth and auth”（身份验证和授权）服务器以及您的用户管理服务器（createuser，等）在农场。因此，随着您对这些服务的点击量的增加，您可以扩展响应这些调用的服务器数量，而无需更改客户端代码。
答案 1 :(得分：1)
在我的一个旅游行业项目（每天大约100万次点击）中，我们有一个单独的auth服务器场。当时有大约四个负载均衡的服务器。我们的业务层称为身份验证Web服务（asmx），它传递用户凭据并获取xml结果。如果用户数量增加，我们可以进一步扩展auth场。通过http（在Intranet上）使用Web服务的恕我直言提供了比TCP更多的性能优势。
答案 2 :(得分：0)
根据我的经验，“你现在不需要它，所以不要浪费精力”和“这里是龙”之间始终存在紧张关系。
当需要时，您的扩展策略使用特定的远程技术将工作卸载到其他主机。听起来它可能有用。 [顺便说一句，另一种方法只是有许多相同的并行实例，所以保持一切本地 - 我的直觉是，这可能会更好。但是现在让我们坚持你的计划......]
我的一般建议是尽早攻击风险。所以在这种情况下，您打算将来使用远程技术卸载一些工作。添加这个新的（到您的系统）技术将（至少）有两个影响：
哦，而且远程控制策略不起作用的可能性很小（不太可能）！您可能看不到预期的扩展效益。表现非常不直观。
所以我在这里看到风险，我想解决这个风险现在。我会说立即进行远程处理，即使它不是必需的。然后，您将进行所有性能测试，以测试增加的延迟以及测试故障模式的所有弹性。当压力消失时，你正在这样做，而用户数量很少。您还可以对实际可伸缩性进行一些测试。