这个问题是关于设计决策的。我目前正在从事一个 Web 项目，该项目将有 40K 用户开始，并在几个月内预计将增加 5000 万用户(虽然不是并发用户)。我想要一个无需太多努力即可轻松扩展的架构。
为了解释，我想使用一个简单的场景。可以说，用户实体和服务(如 CreateUser、AuthenticateUser 等)是对页面 Controller 的简单方法调用。但是，一旦流量增加，例如，必须将身份验证用户(或与用户实体相关的此类服务)移出到不同的内部服务器以分散负载。但与此同时，当用户数量为 40K 时通过网络使用 RPC 调用将变得过大。
我的建议是最初使用 IPC，当我们需要扩展时，我们可以内部切换到基于 TCP 的 RPC 调用，以便它可以轻松扩展。例如，我指的是 System.IO.Pipes.NamedPipeStreamServer 开始，稍后转到 TcpListener。
如果我们有适当的设计来封装上述方法，我们将很容易将服务扩展到多个网络服务器，同时避免在用户数量较少时进行网络调用。
这是最好的方法吗？任何建议都会很棒..
注意:数据库扩展绝对是第二阶段优化，因此我们已经进行了架构设计，以便在流量增加时轻松分区数据。在这段时间内，主要瓶颈将是应用服务器。
最佳答案
如果您打算做的是(如果我没看错的话)将身份验证和授权工作外包给中央服务器，那么我认为如果您尝试使用命名管道甚至低级 TCP 套接字。没有理由不能通过常规 Web 服务甚至基于 TCP channel 的 WCF 服务访问这些内部服务器。
我之所以选择这条路线，是因为调用无状态 Web 服务(ASMX 或 WCF)将允许您创建“auth and auth”(身份验证和授权)服务器以及您的用户管理服务器(createuser，等)在农场。因此，随着您对这些服务的访问量增加，您可以扩展响应这些调用的服务器数量，而无需更改客户端代码。
关于asp.net-mvc - 设计决策 - 扩展基于 Web 的应用程序架构，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/3015764/