网络应用程序的N层体系结构模式

Question

我正在寻找服务器端软件的架构模式，尤其是网络应用程序，这些模式在现实世界中被用于很好的理由。这里有一些我能想到的：

• 单服务器：在同一台服务器上的应用程序运行的所有部分（数据库，应用程序，Web服务器侦听端口80等）
• 简单的2 -Tier：数据库在单个服务器“DB”上运行，而“应用服务器”层中的所有其他部分可能包含任意数量的服务器。层通过ODBC等进行通信。这
• ，变化（？我们多少能一一列举）包括单主/多从的DB服务器和多主数据库服务器
• 3层：数据库上一层运行，业务对象和逻辑在第二层上运行，在第三层上呈现，其中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），并且最终的扩展本质上是一个表示/逻辑分离，但是使用异构逻辑服务器，以及演示服务器非常重要。