N-tier architectural patterns for web apps

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开发者_JS百科 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?

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:

1. Load balancers
2. Reverse proxies
3. Web/app servers
4. Database servers

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.