代码之家 › 专栏 › 技术社区 › asyncwait

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

rpc ipc scalability architecture asp.net-mvc

asyncwait · 技术社区 · 14 年前

这个问题是关于设计决策的。我目前正在进行一个网络项目,该项目将有4万用户,并在两个月内预计增长5000万用户(但不是并发用户)。我想有一个架构,可以很容易地扩展不需要太多的努力。

为了解释,我想使用一个简单的场景。比方说,用户实体和服务(如createuser、authenticateuser等)是对页控制器的简单方法调用。但是,一旦流量增加,例如,认证用户(或与用户实体相关的此类服务)必须转移到不同的内部服务器以分散负载。但同时,当用户数为40k时,在网络上使用rpc调用将变得过分。

我的建议是最初使用ipc,当我们需要扩展时,我们可以内部切换到基于tcp的rpc调用,以便它可以轻松扩展。例如,我指的是 System.IO.Pipes.NamedPipeStreamServer 开始并继续 TcpListener 后来。

如果我们有适当的设计,可以封装上述方法,我们将很容易把服务扩展到多个网络服务器,但同时避免网络调用时,用户数很小。

这是最好的方法吗?任何建议都很好。

注意:数据库扩展被定义为第二阶段优化,因此我们已经进行了架构设计,以便在流量增加时轻松地划分数据。在这段时间内,主要的瓶颈是应用服务器。

3 回复 | 直到 14 年前

Kevin Hoffman 14 年前

如果您计划将身份验证和授权工作分配给中心服务器(如果我读得对的话),那么我认为如果您尝试使用命名管道甚至低级TCP套接字,那么您将发现可伸缩性方面的问题。没有理由不能通过常规web服务甚至基于tcp通道的wcf服务访问这些内部服务器。

我选择此路径的原因是,调用无状态web服务(asmx或wcf)将允许您在服务器场上创建“auth and auth”(身份验证和授权)服务器以及用户管理服务器(createuser等)。因此,当您对这些服务的点击率增加时,您可以扩展响应这些调用的服务器的数量,而无需更改客户端代码。

matrix 14 年前

在我的一个旅游业项目中(每天点击量约为100万次),我们有一个单独的auth服务器场。当时大约有四台负载平衡服务器。我们的业务层称为身份验证web服务(asmx),它传递用户凭据并获取xml结果。如果用户数量增加,我们可以进一步扩展身份验证场。imho通过http(在intranet上)使用web服务比tcp提供更多的性能优势。

djna 14 年前

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

您的扩展策略是,当需要时,使用特定的remotng技术将工作卸载到其他主机。听起来可能有用。[顺便说一句,另一种方法是让同一个事物有很多并行实例,所以保持所有的局部性-我的直觉是这样可能更好。但现在我们还是坚持你的计划吧…]

我的一般建议是及早打击风险。因此,在本例中,您打算在将来使用远程处理技术来卸载一些工作。将此新技术(添加到您的系统)将(至少)产生两个影响:

新的失效模式
延迟增加

哦,还有一种(令人钦佩的不太可能)远程处理策略不起作用的可能性!您可能看不到您所期望的扩展好处。众所周知,表演不生动。

所以我看到了风险,我想解决这个风险现在是的。我想说的是,即使不是高考,也要马上做远程处理。然后,您将在所有性能测试中加入增加的延迟,并在所有弹性测试中加入故障模式。你这样做的时候,压力是关闭的,而用户数量是低的。您还可以对实际的可伸缩性进行一些测试。