Architecture 三层Web体系结构：不同机器上的层是否有益？

我工作的一个客户机有一个标准，他们要求将新应用程序的数据层包装到一个web服务中，并将一台机器与业务/表示层的托管位置分开。有人能告诉我这样做有什么好处吗？在我看来，这造成的问题比解决的问题多：

• 导致更多的通信量/CPU时间-生成XML soap请求/响应，而不是直接连接到数据库
• 难以调试-需要调试两个独立的项目，而不是一个

我猜这可能是由于安全问题（表示机器暴露于Internet，而数据层机器不暴露于Internet）；但是，我看不出这比直接连接到数据库更安全：登录到数据库的帐户不应该有比web服务包装器更多的访问权限

---

我遗漏了什么吗？

我认为背后的原因与将域和业务逻辑包装到存储过程中的原因相同。为运行在不同平台上的多个应用程序和客户端提供对数据的安全访问，同时在数据层中强制执行数据完整性检查和其他规则

---

这个想法实际上是有道理的，但实施的想法并不完美。如果数据层需要大量的流量，那么序列化和反序列化数据将在性能和设备要求方面产生巨大的成本。

我认为通过web服务与数据层通信非常奇怪，我不建议这样做

访问数据库（如果您谈到数据层，我想您指的是数据库）有既定的标准，这些数据库也可以访问远程数据库（例如JDBC、ODBC等）。因此，没有真正需要使用web服务

如果您使用web服务，您会遇到大量新问题，例如超时、消息完整性、消息安全性或您必须处理的可靠消息。这些都是潜在的错误源

Web服务在延迟和消息大小方面都有巨大的开销。为了获得快速的整体解决方案，Web服务必须是粗粒度的。例如，Web服务必须是整个过程的前端，如注册学生（以保持较低的消息交换次数），但不能是细粒度的，如保存学生数据，然后在学生数据中附加学习计划，然后在学生数据中附加一些费用的新账单等。（这些都是单独的消息交换，但这也是访问数据层时的常见粒度）

---

因此，我会选择JDBC/ODBC与数据层的通信。Web服务在业务层和表示层或第三方应用程序（应用程序集成）之间可能会更有意义.

除了具有良好定义接口的模块化软件的常见优势外，三层体系结构将独立地允许三层中的任何一层在需求或技术变化时进行升级或更换。此外，您还可以使用许多前端服务器进行负载平衡

例如，表示层中操作系统的更改只会影响用户界面代码

---

看看银行业，你对账户信息的网络访问仍然来自COBOL系统。

就像许多体系结构问题一样，这可能是一种平衡行为

当然，将一个三层web应用程序拆分为单独的机器上的每一层的一个好处是，您现在可以单独地对应用程序的各个部分进行负载平衡。例如，您可以有3个web服务器只为GUI提供服务，这个“群集”将连接到一个“群集”在3台应用服务器中，所有服务器都实现了良好的负载平衡，并被视为web服务器的一个“实例”。同样，DAL（数据访问层）也存在类似的情况

以这种方式分离各层还允许对整个应用程序的各层进行一定程度的“解耦”。这允许对每一层进行不同的设置（即可以使用不同的硬件或不同的操作系统等）只要接口保持一致，如果任何一个单独的层被改变，就不会有问题

这必然会对软件开发产生影响，因为DAL/BLL/UI现在将是单独的程序集（可能是单独编译的DLL或等效程序）和真正独立的层，而不仅仅是在一个应用程序/项目中将代码结构化为单独的层

在过去，我将web应用程序的业务层公开为web服务，web GUI完全是针对该服务编写的。这使公司能够将该产品作为托管的基于web的解决方案进行销售，客户可以使用该解决方案，同时还可以销售与web服务相同的产品的访问权限，从而允许客户进入将产品的功能整合到他们自己的内部应用程序中（ala垂直市场解决方案）

当然，还有平衡的作用。将层分离到单独的机器上会给系统的整体架构带来一些复杂性。您正确地指出了一些潜在的问题，例如机器之间的通信现在会增加一些开销，如果通信层在同一台机器上。每层之间的数据编组也会增加开销。当然，在web服务的情况下，序列化和反序列化复杂对象会增加大量开销，并对性能产生负面影响，特别是在流量非常大的情况下

根据实际向整个应用程序的用户公开的内容，“较低”层上的安全性可能需要，也可能不需要 - Database Node | (database access protocol) - Data Access Layer/Business Logic Layer Node | (web services/RMI/CORBA/other protocol) - Presentation Layer Node