4-Tier (用于N-Tier)架构的示例？

Question

最近，我的一个朋友问我关于N层架构的问题，我能够用例子向他解释关于1层、2层和3层架构。但是当我想给出超过3层的例子时，我被卡住了。我在谷歌上搜索并寻求帮助，但找不到任何像样的例子。

它被命名为N-tier的事实让我认为“N”可以是从1开始的任何数字，但我找不到任何4或5层的例子。

有没有人可以分享一些涉及3层以上的N层架构的例子？

Answer 1

1. 基础服务:例如数据库、目录服务、文件和打印服务、硬件抽象。这一层越来越多地被称为CORBA域层:一种应用服务器，例如JavaEE，包括platform.
2. Business、DCOM对象。提供业务功能，使用SOA和PHP层增加:例如，Java Servlets/ Micro-services.
3. Presentation。这一层将越来越多地包含WebServices作为业务层的代理和适配器services.
4. Client层:瘦客户端(如浏览器上的HTML页面)和富客户端(如Java和Flash.

• In Java EE )通常将业务域层划分为数据访问(实体Bean)和业务服务(会话Bean)。
• 在企业SOA (Service Oriented Architecture)中企业服务总线(Enterprise Service Bus)通常作为第1层和第2层之间的附加层存在。它可能是平台配置的一部分。<代码>H216
• 在Mashup中，您可以在第3层和第4层之间设置聚合层。

被称为N-Tier的转变反映了从旧的客户端-服务器到第一个3-Tier然后是4-Tier的越来越组件化的体系结构。层的定义特征是具有分离关注点的清晰定义的接口。

Answer 2

​

​

五分钟前，我读了一篇关于这个https://www.nginx.com/blog/time-to-move-to-a-four-tier-application-architecture的文章

客户端是你读取Api的地方，或者你的应用程序后端是你组装它的地方。数据聚合..要么通过json/xmls从外包的东西或查询您的数据库，最后服务层是您实际在数据库上查询，或运行大数据功能，或从google读取GPS位置和地图……这就是我在这种情况下的看法。它简单地将数据层分为三层。

但是这个N层模型是完全抽象的，所以你可以拆分你的基础架构，直到你只有一些逻辑上的原子部分。仍在划分之前的结构。

Answer 3

我倾向于不那么抽象和更实用的解释，来回答这个问题：“我如何以及为什么要将我的系统拆分成层，以及我将它们放在服务器上的什么位置？”

本质上，当你创建一个使用数据库的简单网站时，你已经有了3层“开箱即用”：

• 数据层-数据库。但是，如果您使用的是短暂的内存缓存或文件系统，那么我们可能会争论是否可以将其视为“层”或not.
• application层-在server(s).
• presentation (或客户端)层上执行的代码-在客户端机器上执行并将结果呈现给client

的代码

现在，我们如何获得第四层？

最有可能的是，不需要拆分客户端层。它在客户端的设备上，我们希望使其尽可能简单和高效。

我们可以拆分数据层吗？我见过一些系统使用API围绕数据库、Azure blobs、文件系统等来创建一些可以被认为是一个层的子系统。但是，这仍然是相同的数据层(也称为基础服务层)，还是我们可以将其视为一个单独的实体？如果我们将其分开，它是否会与我们的数据库在同一物理(或虚拟)服务器上，这样我们就可以保护数据不会被直接访问？

然而，在大多数情况下，被拆分的是应用层。

其中一部分仍然被命名为应用层。它将成为内部API web应用程序，并位于可访问数据库的安全区域中。任何人都不能直接访问数据库，只能通过这个应用层。

另一部分通过某种连接(HTTP客户端等)成为应用层API的消费者。消费者可能被称为表示层(令人困惑-它不是和客户端层一样吗？)，即使它本身只有JSON，没有任何用户友好的格式。

但随后问题出现了:在哪些情况下，我们开发人员可能想要使我们的生活复杂化，并将我们的web应用程序划分为表示层和应用层，而不是将它们作为层保留在同一个web应用程序中？

对于严重的工作负载，单独的应用程序层可能有利于可伸缩性，或者可能是安全要求，以拒绝数据库连接到向用户公开的web服务器(即使是intranet服务器)。

我看到一些雄心勃勃的项目从一开始就走上了4层，然后因为过度设计而咒骂自己。您必须跟踪这些内部连接、安全性、身份验证令牌，控制套接字(不在每个请求上打开新的HTTP连接)，避免因不小心创建全局HTTP客户端实例而意外共享多个并行请求的数据等。