我正在开发一个有很多并发用户的.net 门户。
因此可扩展性、性能需要在设计和架构中加以解决。
我们计划在应用程序中使用负载平衡。
记住这一点，在 IIS Web 服务器(托管 aspx、aspx.cs 文件)和应用程序服务器(托管 .net 程序集，如业务逻辑和数据访问层)之间进行通信的最佳方式是什么？
它应该是 .net 远程处理还是肥皂网络服务？还是有其他方法？
谢谢。
最佳答案
还有另一种方法吗？ 是的 - 不要分发你的对象。
最具可扩展性的方法是不要将您的对象彼此分开。问问自己，为什么要将一种风格的代码部署到“应用服务器”而另一种风格的代码部署到“Web 服务器”？这两个层之间进行的通信，如果它们是分布式的，将比本地调用昂贵得多(等等)。
对于当今的 64 位服务器、所有内存和热 CPU，以及 ASP.NET 卓越的内存管理，为什么不将业务逻辑和 DAL 与 ASPX 文件放在同一台物理机器上呢？为什么不？
如果您需要扩展，请添加更多服务器。简单的。
当然，分发是有充分理由的。最常见的充分理由与所有权领域有关 - 沿着几个轴:安全管理，甚至预算和控制。换句话说，对于后一种情况，如果团队负责运行业务逻辑，而一个单独的团队负责构建和运行 Web 层——那么分配这两个东西以允许管理的独立性可能是有意义的。大多数分发计算机代码的充分理由都源于使用或开发代码的人类组织的结构。
一个网页不应该在同一个 CPU 上运行，共享同一个 CLR 虚拟机和内存堆，作为数据库访问层，没有什么好的技术理由。
无论您如何处理分发，使用定义层之间连接的不太正式的接口(interface)来构建您的系统都是不明智的。如果您保留正式的接口(interface)，那么衡量分布式方法与协同定位方法的性能和效率应该没有问题。
关于asp.net - 解决 .net Web 应用程序中的可伸缩性和性能问题，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/580514/