3（物理）层架构效率低吗？答案

【问题标题】：Is a 3 (physical) tier architecture inefficient?3（物理）层架构效率低吗？
【发布时间】：2011-01-01 02:56:17
【问题描述】：

注意：当我提到层级时，我指的是物理层级。本网站上与“层”相关的许多问题都涉及逻辑层，这不是我要问的。

我正在使用标准的“3 层”架构设计应用程序，其中包括表示层、业务逻辑 (BLL) 和数据访问 (DAL) 层。技术是 WPF、C#、LINQ 和 SQL Server 2008。我的问题与这个应用程序的物理架构有关。

我可以将 BLL/DAL 放在一个标准 DLL 中，该 DLL 在用户机器上加载和运行，形成一个 2 层架构 - 客户端机器和数据库服务器。但将 BLL/DAL 转换为 WCF 服务并不难，该服务位于应用服务器上并从用户计算机调用。这会给我一个 3 层架构 - 客户端机器、应用服务器和数据库服务器。

我的问题是 - 使用 3 层架构有什么优势？我经常被告知 3 层增加了可扩展性，但我并没有立即明白为什么会这样。同样的数据必须在网络上进行两次跳跃——从数据库服务器到应用程序服务器，然后从应用程序服务器到客户端机器，你肯定会受到性能的影响。

我非常感谢经验丰富的架构师和开发人员的建议。

【问题讨论】：

标签： c# sql-server architecture

【解决方案1】：

可以。这取决于实施了什么以及如何实施。

创建 3 层物理架构的驱动力不一定与性能相关。

引用可伸缩性的原因是服务可能在服务器场上运行，但客户端不会意识到这一点。如果架构设计为支持它，则可以增加服务器场的大小以满足需求。

【讨论】：

【解决方案2】：

这取决于您的应用程序的使用情况和您对安全性的要求。如果您的应用程序正在 Internet 上使用，并且您正在以任何方式存储任何可能敏感的内容，强烈建议为数据库添加物理删除。永远不要让任何人从外部进入任何可以直接访问您的数据库的机器。人们可以而且将会试图破坏您的安全，没有比他们无所事事更好的理由。

可伸缩性也是一个因素，无论是在表示层之前（在 Web 服务器之前）还是在数据库中。在表示层前面放置一个负载均衡器可以将传入的请求路由到一组可以独立管理的机器。机器可以在需要时添加到池中并移除以进行维护。在其他层之间放置负载平衡器可能会产生相同的影响。这个想法是提供一个灵活、动态的后端环境，可以根据需要进行调整。

【讨论】：

【解决方案3】：

低效率在旁观者的眼中。

例如，让所有事情都发生在客户端上可能会增加客户端计算机的内存占用或 CPU/网络需求。如果这项工作可以卸载到服务器/服务器场，您可能无需为运行您的软件而对客户端 PC 进行硬件升级。如果需要更多资源或升级，可以在业务逻辑层中添加/完成它们，而不会影响客户端。

此外，当您需要在基于 Web 的系统或 Outlook 插件中公开应用程序的某些功能时（从软件开发的角度来看），将业务逻辑放在自己的层上可能会更有效，或者iPhone 应用程序。每当业务逻辑发生轻微变化时，您都不想更新所有这些系统。

安全性可能会更好，因为您的用户不需要直接访问数据库服务器，它们被应用程序服务器隔离。

它还迫使您以模块化的方式考虑您的应用程序，这些接口定义明确，可能对您的应用程序设计具有架构优势。

【讨论】：

【解决方案4】：

每当您发现自己在问“X 效率低吗？”时您应该立即问自己三个前导问题：

通过“低效”，您认为哪些资源应该有效使用，但可能不会？时间？空间？带宽？ 开发时间？
你为什么在乎？不，说真的：如果你要花一分钟来回答这个问题，那肯定是有原因的。这是什么原因？
与什么比较？

就您对可伸缩性的评论而言：有一段时间，我不幸有责任维护一个系统，该系统的架构师被告知尽量减少与数据库的往返次数将使应用程序具有可伸缩性。他接受了这种洞察力并随之而来。你可以阅读这个项目here。我突然想到，我应该提到，在该应用程序的整个十多年的生命周期中，从来没有超过四个用户同时登录。

【讨论】：

【解决方案5】：

像您描述的 3t 应用程序的主要优点不是可扩展性。可能是可维护性。

为了使您的架构具有可扩展性，您还需要一项您没有提到的技术。 - 你需要服务。我会建议 WCF。

制作您的 BLL WCF 服务（或多个服务）将使您的应用程序更加高效和可扩展，允许您的 BLL 在不同/多台机器上运行。

【讨论】：