Web 应用程序的 N 层架构模式

Question

我正在寻找服务器端软件的架构模式，尤其是 Web 应用程序，这些模式在现实世界中有充分的理由使用。以下是我能想到的一些：

• 单服务器：应用程序的所有部分都运行在同一台服务器上（数据库、应用程序、监听端口 80 的网络服务器等）
• 简单的 2 层：数据库在单个服务器“DB”上运行，所有其他部分在“appserver”层中，可以包含任意数量的服务器。这些层通过 ODBC 等进行通信。
• 其中的变体（有多少？我们可以列举它们吗？）包括单主/多从数据库服务器和多主数据库服务器
• 三层：数据库运行在一层，业务对象和逻辑运行在第二层，表示层在第三层，其中1和2通过ODBC通信，2和3通过某种形式的远程调用（例如 RMI）
• 我似乎从一些演示中回忆起，eBay 曾经有一个架构，其中应用层生成 XML，然后在单独的层中将其转换为 HTML。这是常见的还是奇怪的？
• 一堆网络应用程序使用 memcachedb 或类似的东西来加快速度。一组缓存服务器可以说是另一层吗？

你能帮我列举一些这些模式，或者指出一些已经描述过的地方吗？

Answer 1

您可能会喜欢已有十年历史但仍具有相关性的经典 Building a Large-Scale E-commerce site with Apache and mod_perl。他们的等级是：

1. 负载平衡器
2. 反向代理
3. Web/应用服务器
4. 数据库服务器

这仍然是大型网站的蓝图。更大的网站规模可能需要更神秘的东西，但这是理解它们的基础。

请注意，他们使用了 mod_perl，这意味着他们的 Web 服务器是他们的应用服务器。如果您当时使用 Java，您将在 Web 服务器后面运行应用程序服务器（“Web 服务器”是指 Apache，处理 HTTP 解析、TLS 和静态文件；获取和携带，但没有逻辑），并将它们与 AJP 连接起来。您今天可能仍然这样做，但您更有可能只使用应用程序服务器作为您的 Web 服务器（即根本没有 Apache，只有 JBoss 或类似服务器）。应用服务器现在已经足够稳固，可以做到这一点，您可以依靠反向代理和内容分发网络来完成大部分获取和传输。

至于缓存层，反向代理是应用服务器前面的缓存层，但它们在应用服务器机器上进行应用级缓存，使用联合缓存（您可以使用 memcached 或类似的缓存）今天）。我认为今天这仍然是一个可行的选择。我认为没有理由将您的应用层服务器划分为专用的应用和缓存服务器。我很想知道这样做的原因。

我不认为在应用层中拆分表示和业务逻辑是一个真正成功的想法。有些项目可能会这样做，但我想是因为他们有建筑宇航员负责，而不是出于任何充分的理由。也就是说，通常会有一个应用层大量使用更靠后的服务层（我猜这是 SOA），其最终扩展本质上是表示/逻辑拆分，但具有异构逻辑服务器，并且演示服务器非常负责。