Architecture 有人能解释一下5层架构吗？

我试着在网上寻找一个关于5层架构的好解释。但是，我没有找到任何好文章。我了解3层和4层体系结构，但是5层在我的脑海中并不存在。有人能解释一下，或者举个例子吗？ 谢谢

表示层（浏览器或其他表示应用程序）

图层（视图模型）

业务逻辑/域逻辑（服务/域层）

数据访问层（数据库访问逻辑等）

数据存储层（数据库引擎或类似）

---

其中一些东西在物理上比其他东西更容易分离。表示和数据存储通常是分开的，业务逻辑有时是分开的，但不太经常。数据访问和视图模型很难从业务逻辑层中分离出来，而且在很大程度上毫无意义。

我想您指的是5层架构。首先，我们应该先定义5层体系结构，然后再开始5层体系结构

五层体系结构 分层是在应用程序中实现的逻辑分离。它与N-Tier有关系，但我们将在稍后讨论：

1）演示文稿 这就是向用户显示应用程序的方式。您可以将其视为应用程序的外观。但它与UI层非常相似，当今世界随着JavaScript（客户端呈现解决方案，如React、Angular等）的改进，这种分离可能看起来不准确，但仍然有意义，让我继续：

2）UI 这就是解释用户交互的地方。当用户单击submit按钮时会发生什么情况，数据是如何发送到服务器和检索的？如果您想一想我们以前使用的服务器端呈现，我们都在解释这些内容并返回用户完全准备好的HTML页面，但今天使用客户端呈现，所有这些工作都是在JavaScript的帮助下在用户浏览器中完成的。所以，如果使用客户端渲染，您可以考虑现在Presentation+UI是在用户服务器（电话、pc等）中完成的。如果用户的服务器只负责显示数据，那么现在表示层在那里，而UI层在我们的服务器中

3）业务逻辑 这是我们负责数据验证的地方（即使您在客户端进行验证，我们也应该在服务器端进行验证，因为我们从不信任客户端）、操作、安全、处理、数据库查找等。这些责任可以在UI端和数据访问之间共享，具体取决于操作的安全范围

4）数据访问 在这里，您可以抽象插入、删除等需要在数据库上执行的操作（数据存储级别）。它有点像数据库和应用程序之间的接口

5）数据存储 这是数据库服务器的归属。这是数据访问层的实现，它通过心理方式在服务器上插入、删除数据等

五层体系结构 现在，根据应用程序的需要，您应该定义权衡：

• 你想要实现什么
• 您希望缩放多少
• 您可以接受的延迟是多少

如果您实现了低延迟，并且不打算被太多用户使用，那么您可以从1层开始。在下面的演示中，请记住，业务逻辑层可以在任何层中完成，只要出于安全原因，也可以在客户端（表示层/UI层）中使用一些通用/简单的业务逻辑，这可能会提高服务器的性能。此外，您可以根据使用服务器端或客户端渲染将UI层放在更高/更低的层中，但我们在上面讨论了总体思路：

一层

所有层都属于一个物理位置。就像一个安装在用户数据库上且不请求任何其他外部系统的游戏一样，它在用户服务器上有自己的数据库，所有逻辑都在那里实现

两层 假设您希望中央数据库管理，而所有其他部分都可以保持用户服务器的状态，就像他在手机上玩游戏一样，但数据存储在我们的服务器中

到目前为止，您具有性能优势。如果您需要支持更多的用户，并且需要比您需要的更高的安全性，那么可扩展性

三层 除了微服务（可能是另一个讨论主题），这是最常用的体系结构之一。表示和UI位于用户的服务器（客户机）上，业务逻辑和数据访问属于应用程序服务器，数据存储位于另一台服务器上

但是现在你的用户请求跳转了更多层，这将增加你的网络延迟。正如前面所说的，它是关于权衡的。现在，您也开始享受缩放带来的好处，如：

因此，根据您的应用程序需求、安全级别、延迟限制、用户数量等，您可以将其划分为更多层，这就是其名称为N-Tier的原因

工具书类

• 专家C#3006业务对象-Rockford Lhotka

• 软件架构模式-MarkRichards

---

我目前正在学习《数据库系统基础》（Pearson出版的第七版，通过搜索引擎作为免费pdf电子书提供良好的可用性）一书。书中有一章介绍了DBMS客户机-服务器、2/3/n-tier-体系结构。看看这本书，你可以得到更多关于单层/多层架构之间差异的信息

自从电信网络的使用量迅速增长以来，3/n层架构模型变得越来越流行。对于分布式云服务平台解决方案（针对那些必须处理大数据的公司），4层和5层Architechutre解决方案受到欢迎

大型公司（如社交媒体公司Facebook）可能会使用分散的解决方案