第 19 章：MSDN 上的物理层和部署描述了“分布式部署”（见图 2）。一切都很好。
根据我的经验，我们总是按照他们所说的“非分布式部署”（图 1）来部署基于 Web 的系统。我的理解是，在 Microsoft 世界中，作为独立事物的“应用程序服务器”并不真正存在（就像在 Java 世界中那样），因为它有效地“融入”了操作系统/Windows。
所以我的问题是，如果您要将 UI 和业务逻辑 (BL) 分发到不同的服务器/层，它们将如何通信？
我知道一个答案是使用“服务层” - 有哪些替代方案？你会怎么做呢？从代码的角度来看它会是什么样子？
首先关。不要这样做。只是不要。你进入了一个痛苦的世界。逻辑层和物理层是不同的东西。应用程序层的逻辑分离是一个好主意。应用程序层的物理分离往往是灾难的根源。如果有一个很好的部署原因（另一个盒子上的共享支付处理器），当然，继续。您可以使用我们都知道和喜爱的标准机制——WCF、MSMQ、HTTP，......选择你的毒药。但是不要为了实现 MSDN 白皮书中的一些神话般的理想而承担开销和复杂性。
应用服务器被认为是一种帮助分配稀缺资源的想法：中间层的计算能力。这个想法来自大型机领域，最初，CPU 稀缺且昂贵，因此花费大量时间、精力和金钱将大型机 CPU 分配给各种用户，限制工作负载，保持数据库负载，“钝化" 交易直到数小时后负载减少，依此类推。在那些日子里，人们花费数百万美元购买跟踪大型机交易的软件，以便能够执行“退款” - 内部成本核算使用昂贵的大型机。是的，人们花了一大笔钱，这样他们就可以向内部部门计费以使用大型机。
问题是，英特尔（以及后来的 AMD）、思科（等）、EMC、微软和 Linux 使整个想法变得毫无意义。计算变得便宜。真的很便宜。真的，真的，真的没有必要对中层计算资源进行配给。这些天来双CPU服务器是什么？您可以为 ONE IT 人员的年薪部署多少个？这是大型机计算的旧经济学的倒置，其中计算是昂贵的稀缺资源，而人们相对（！！）便宜。现在人是最昂贵的部分，而计算是便宜的。
应用程序服务器，以及它们为限制对计算的访问、或将其打包、或对其进行节流甚至“监控”交易以进行退款的所有花里胡哨……当您拥有大量的便宜的 AMD 服务器。
应用服务器做的另一件事是保护数据库免受工作负载的影响。本质上，从数据库服务器卸载工作。时间是，开发人员将业务逻辑放入存储过程中，然后，您的应用程序就出现了。但是这种方法存在可扩展性问题。但是，现在，存储过程既快速又高效。数据库服务器可以廉价地扩展。很有可能，您没有世界上排名前 100 的工作负载量之一，这些工作负载量无法在英特尔硬件上承载，并具有存储的 proc 逻辑。
然而，存储过程方法的一个主要问题是，用主流语言（Java、C#、VB 等）编写和管理存储过程仍然有点困难。是的，我知道数据库管理的 SQL CLR 和 Java VM。但这些都不是主流方法。此外，DB 管理员不喜欢代码骑师弄乱他的利用率图表。由于这些原因，仍然希望使用专用于该目的的单独语言编写业务逻辑。并且仍然希望在专用计算资源上运行和管理该逻辑。但是……传统的“应用服务器”？？不，这没有意义。
把你所有的逻辑都放在英特尔服务器上，然后就可以了！如果你需要更多的规模，克隆盒子。所有的业务逻辑都是无状态的（对吧？），所以你可以向外扩展。使用 3 台“应用程序”服务器机器，或者 4 或 5 台，或者你需要的任何数量。所有运行完全相同的代码。互相克隆。无论您拥有多少业务逻辑机器，都不要物理地分配工作负载。为了获得最大的可扩展性，请努力将每笔交易都放在一个盒子上。这是提高效率和优化资源利用的秘诀。
在应用程序架构中使用逻辑层是最佳实践。这使得开发和维护变得更容易。但不要认为逻辑分离一定意味着，甚至推荐物理分离。它不是。