三层Web体系结构:单独机器上的层是否有益?

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

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

像许多体系结构问题一样,它可以是一种平衡行为。

当然,将三层Web应用程序拆分为在不同的计算机上拥有每一层的好处之一是,现在您可以分别对应用程序的各个部分进行潜在的负载平衡。例如,您可以让3个Web服务器仅为GUI提供服务,这个“集群”将连接到3个应用服务器的“集群”,所有这些服务器都很好地实现了负载平衡,并被视为Web服务器的单个“实例”。同样,与DAL(数据访问层)的情况类似。

以这种方式分离层还允许对整个应用程序的层进行一定程度的“分离”。这允许每个层的设置不同(即可以使用不同的硬件或不同的操作系统等),并且只要接口保持一致,就不应该出现任何单独的层被更改的问题。

这必然会对软件开发产生影响,因为dal/bll/ui现在是单独的程序集(可能是单独编译的dll或等效程序),并且真正独立 层级 而不仅仅是将代码组织成单独的 层 在一个应用程序/项目中。

在过去,我将Web应用程序的业务层公开为Web服务,而Web GUI完全是针对该服务编写的。这使得该公司可以将产品作为客户可以使用的基于Web的托管解决方案进行销售,同时也可以将对同一产品的访问权作为Web服务进行销售,从而允许客户将产品的功能集成到自己的内部应用程序中(ALA垂直市场解决方案)。

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

根据对整个应用程序的用户实际公开的内容,“较低”层上的安全性可能需要,也可能不需要。如果您只公开Web GUI,则应将较低层配置为不可访问(而不是通过Web服务器),但是,如果您公开“业务层”和Web GUI层,则您将承担保护应用程序多个潜在攻击“表面”的额外负担。

但是,最终,如果您知道不需要负载平衡单独的层,并且您知道不需要切换一个层,或者不需要将业务逻辑与Web UI分开公开,那么这可能比它的价值更大。

除了具有定义良好的接口的模块化软件通常的优点外,三层体系结构将独立地允许根据需求或技术变化升级或替换三层中的任何一层。此外,您还可以拥有许多用于负载平衡的前端服务器。

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

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

我认为通过Web服务包装与数据层的通信是很奇怪的,我不建议这样做。

1. 有现成的标准来访问数据库(我猜你是指一个数据库,如果你谈论一个数据层),它也访问远程数据库(如JDBC,ODBC,…)。所以不需要使用Web服务。

2. 如果使用Web服务,则会出现大量新问题,例如超时、消息完整性、消息安全性或必须处理的可靠消息。这都是潜在的错误源。

3. Web服务在延迟和消息大小方面都有巨大的开销。要获得快速的整体解决方案,Web服务必须粗粒度。例如,webservice必须是整个过程的前端,例如注册学生(保持低消息交换数量),但不能像保存学生的数据那样细化,然后在学生的数据中附加学习程序,然后在学生的数据中附加一些费用的新账单等(这些都是单独的消息交换,但这也是访问数据层时常见的粒度)。

所以,我真的要进行JDBC/ODBC与数据层的通信。在业务层和表示层或第三方应用程序(应用程序集成)之间,Web服务可能真的更有意义。

是的,这是安全应用程序的常见模式。

  - Database Node
        | (database access protocol)
  - Data Access Layer/Business Logic Layer Node
        | (web services/RMI/CORBA/other protocol)
  - Presentation Layer Node     

通常Web服务器暴露在DMZ中,因此需要将BLL/DAL放在另一台机器(节点)中。Web服务被用作“连接协议”。Web服务很难侵入DAL服务器,数据由另一个节点保护。使用Web服务公开的呈现层可以在自由窗体(Java、.NET、Web客户端或桌面应用程序)中实现。

因此,听起来您在一台服务器上有Web和业务逻辑,在第二台服务器上有数据访问代码。这是不寻常的,因为业务逻辑通常与Web服务器分离,并且数据访问代码位于单独的服务器上。这样做的好处是,所有代码逻辑(业务)都将与数据访问代码一起生活在安全区域(而不是面向公共的Web服务器上)。然后,现有的Web服务将向业务逻辑公开API,而不仅仅是数据访问代码。