Web 应用程序的 N 层架构模式
我正在寻找服务器端软件的架构模式，特别是网络应用程序，这些模式在现实世界中已经得到了很好的使用。以下是我能想到的一些：
- 单服务器：应用程序的所有部分都在同一服务器上运行（数据库、应用程序、监听端口 80 的 Web 服务器等）
- 简单的 2 层：数据库在单个服务器“DB”上运行，所有其他部分在“应用程序服务器”层中运行，该层可能包含任意数量的服务器。各层通过 ODBC 等进行通信。
- 其中，变体（有多少种？我们可以列举它们吗？）包括单主/多从数据库服务器和多主数据库服务器
- 三层：数据库运行在一层，业务对象逻辑运行在第二层，演示运行在第三层，其中 1 和 2 通过 ODBC 进行通信，2 和 3 通过某种形式的远程调用（例如 RMI）进行通信。
- 我似乎从一些演示中回忆起，在某一时刻，eBay 有一个架构让应用程序层生成 XML，然后在单独的层中将其转换为 HTML。这是常见的还是奇怪的？
- 许多网络应用程序使用 memcachedb 等来加快速度。一组缓存服务器可能是另一层？
您能帮我列举其中一些模式，或者指出描述某些模式的地方吗？
I'm looking for architectural patterns of server-side software, particularly web apps, that have been used for good reason in the real world. Here are some I can think of:
- single-server: all parts of the app run on the same server (database, app, web server listening to port 80 etc.)
- simple 2-tier: database runs on single server "DB", all other parts in an "appserver" tier, which may contain any number of servers. The tiers communicate via ODBC or such.
- of this, variations (how many? can we enumerate them?) include single-master/multiple-slave DBs servers, and multi-master DB servers
- 3-tier: database runs on one tier, business objects and logic run on a second tier, presentation on a third tier, where 1 and 2 communicate via ODBC and 2 and 3 via some form of remote calls (e.g. RMI)
- I seem to recall from some presentation that at one point, eBay had an architecture that had an app tier generate XML, which then was transformed into HTML in a separate tier. Is that common or an oddity?
- a bunch of web apps use memcachedb or such to speed things up. A set of caching servers are arguably another tier perhaps?
Could you help me enumerate some of these patterns, or point to places where some have been described?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您可能会喜欢已有十年历史但仍然相关的经典构建大型 E - 使用 Apache 和 mod_perl 的商业网站。它们的层级是：
这仍然是大型站点的蓝图。即使是更大的网络规模的网站也可能需要一些更神秘的东西，但这甚至是理解它们的基础。
请注意，他们使用 mod_perl，这意味着他们的 Web 服务器就是他们的应用程序服务器。如果您当时使用 Java，您将运行应用程序服务器作为 Web 服务器后面的一层（“Web 服务器”我指的是 Apache，处理 HTTP 解析、TLS 和静态文件；获取和携带，但不逻辑），并将它们与AJP连接起来。今天您可能仍然这样做，但您更有可能只使用应用程序服务器作为 Web 服务器（即根本没有 Apache，只有 JBoss 或类似服务器）。应用程序服务器现在足够坚固，可以做到这一点，并且您可以依靠反向代理和内容分发网络来完成大部分的获取和传输。
至于缓存层，反向代理是应用程序服务器前面的缓存层，但它们使用联合缓存在应用程序服务器计算机上进行应用程序级缓存（今天您将使用 memcached 或类似的缓存）。我认为今天这仍然是一个可行的选择。我认为没有理由将应用程序层服务器划分为专用应用程序和缓存服务器；我很想知道这样做的理由。
我不认为在应用程序层中拆分表示和业务逻辑是一个真正成功的想法。有些项目可能会这样做，但我想是因为他们有建筑宇航员负责，而不是出于任何充分的理由。也就是说，通常有一个应用程序层大量使用更靠后的服务层（我猜这就是 SOA），其最终扩展本质上是表示/逻辑分离，但具有异构逻辑服务器，并且演示服务器非常负责。
You might enjoy the decade-old but still relevant classic Building a Large-Scale E-commerce site with Apache and mod_perl. Their tiers were:
This is still the blueprint for large-scale sites. Even larger web-scale sites may need something more arcane, but this is the foundation for understanding even them.
Note that they used mod_perl, which means their web servers were their app servers. If you were using Java at that time, you would have run the app servers as a tier behind the web servers (and by 'web servers' i mean Apache, handling HTTP parsing, TLS, and static files; fetching and carrying, but no logic), and connected them with AJP. You might still do that today, but you would be more likely to just use the app servers as your web servers (ie no Apache at all, just JBoss or similar). App servers are now solid enough to do this, and you can rely on the reverse proxies and a content distribution network to do most of the fetching and carrying anyway.
As for a caching tier, the reverse proxies are a caching tier in front of the app servers, but they did app-level caching on the app server machines, with a federated cache (you'd use memcached or similar for this today). I think that's still a viable option today. I don't see a reason to partition your app-tier servers into dedicated app and cache servers; i'd be interested to hear of reasons to do that.
I don't think splitting the presentation and business logic in the app tier is an idea that ever really took off. Some projects probably do it, but i would imagine because of they have architecture astronauts in charge, rather than for any good reason. That said, it is common to have an app tier that makes heavy use of service tiers further back (this is SOA, i guess), and the ultimate extension of that is essentially a presentation/logic split, but with heterogenous logic servers, and the presentation server very much being in charge.