一个应用程序的架构可以变化多端，具体取决于你要开发的应用程序的需求和功能。
创建一个 web 应用程序的时候，你可以构建多个层来完成，一些层是必须的（比如说前端），其它一些则是可选的。
前端 / 客户端:
前端是一个 web 应用程序中最被用户看到的一个层。通常使用 HTML 写网页结构，使用 CSS 写样式，使用 Javascript 写交互脚本和部分功能。当然还有 Adobe 的 Flash 这样的更加偏向后端的技术来构成前端页面的元素。前端用各种技术把网页数据用更好看更加交互性的方式放入用户的浏览器当中，给与用户更好的体验。
从架构的角度来看，在大型的 web 应用程序当中，这些文件（html, css, js）都会被缓存起来；这意味着当 CSS 和 JS 文件从不同的地方引入，比如说 CDN（例如 Akamai 和 Amazon 的云服务或者 Rackspace 的 CDN 或者其他的服务），HTML 文件可以放在各种各样的 “网络加速器”或者反向代理高速缓存（例如：Varnish）上提供访问。
后端 / 服务端：接下来，什么是通常意义上的“后端”（或者视你项目的具体架构而定，一些复杂的 web 应用程序可能是一个后端用清晰的逻辑去渲染前端页面，然后同时有一个更“深奥”的后端处理类似业务逻辑这样比较复杂的逻辑）。
后端通常是你使用的编程语言（不同于 HTML & CSS 这样的 标记语言），比如 PHP, Python, Ruby, Java 或者其它你所喜欢的。后端通常通过项目具体的业务逻辑来决定如何去渲染前端页面。
框架：框架简单的说是一个预先写好的各种工具集合和一些常用功能的脚手架，意味着你可以使用框架的不同部分来实现大部分功能而不用你自己去写。同时，如果你需要写你自己的解决方案，它们可以实现的更简单和更快速，尽可能地防止你重新造轮子。
不同的框架有着特定的对应语言，同时它们的不同之处取决于它们开发者开发思路。
"Ruby on Rails" 是一个 Ruby 的框架，"Django" 是一个 Python 框架，"ZendFramework" 是一个 PHP 框架，"Spring" 是一个 Java 框架，简单地举例了几个。
在战争的硝烟开始之前必须提醒：没有一个框架是最完美的，它们有各自的优缺点。
还有一些前端的框架：比如说 Backbone.js, Spine.js Knockout.js（还有很多）[ 在这里重点提一下：Javascript 也可以作为服务端的脚本语言 ]
后端可能（我说可能，因为它真的要根据你需要的规模和性能而定）会使用缓存层来缓存某些数据从而避免“更深”入堆栈。常用的一些缓存服务器或者缓存产品有 "Memcache" or "Redis" [ Redis 同样可以用作普通的数据存储 ]
基本的流程是你所选择的编程语言可以存储和检索内存中的数据来完成程序间的通信，意味着不需要磁盘的 I/O，这将会使应用非常高速的运转。
为了让大多数 web 应用程序运转起来，它们需要可以能存储数据的地方。一些有名的数据库有 MySQL, PostgreSQL, Oracle, CouchDB, Redis, HBase 等等。
它们各自有着不同的数据保存方式和管理方式，并且拥有不同的特性。一些数据库用表来保存数据（关系数据库），一些则使用键值对应来保存数据。
数据库抽象层：一种创建数据库抽象层的方法是使用 ORM （对象 - 关系映射） - 这层的功能是将代码所需要的数据和数据源本身分离开来 - 以便让你更新操作的时候不会影响到其它。
一个很好的例子是 Java 的 JDO。同时，现有的大多数框架提供常见的数据库有可配置的 ORM，当然，通常情况下每个框架的 ORM 只能在该框架下运行。
服务器 - 软件：
一切应用可以再单独的一台机子上跑，或者是在上千台机子构成的集群上跑 - 这完全根据你计划设计的架构如何 - 这个就是“规模”
服务器扮演的角色就是接受请求，然后运行它。一次运行，可能是数据库查询请求，或者一个动态脚本，或者视请求磁盘上的一张图片，然后返回数据。
知名的 web 服务器有：Apache, Nginx, Tomcat.. 你还可以根据你的需要，组合多个服务器为你服务。
服务器 - 硬件：
所有我们提及的，都需要一个 CPU 来驱动它。最起码的，需要一台普通的电脑，和你平常使用的电脑并无差别，就是 PC 机。可以根据你的需要来确定主机是物理的显示主机还是虚拟的主机 - 但是必须连接到互联网。
注：拙略翻译，敬请见谅，并非全文翻译
原文：
Well first, by looking at your question it seems you have misunderstood the meaning of architecture from a web application point of view. Or maybe we just see it differently. Either way I will try to be as specific as I can both to your question and what I find architecture to be.
I see architecture as flow diagram. From where the user enters all the way down to the CPU of the server and the power cord connected to it. The technologies, methods, and how everything is arranged to form a complete product is what I think about when architecture comes to mind.
I'll give you a top to bottom approach of the *common* stuff around today, while trying to address some of the stuff your brought into the question yourself so you can see where they stand. It's going to be long, but bear with me and hopefully you'll have a firm grasp when you're done reading (I truly hope).
Here we go.
Architecture:
A Web Application architecture can vary greatly depending on the application at hand, its needs, its behavior and of course, the means at hand.
That are a lot of layers you can stack up when building a web application, some are "mandatory" (like a front end, right? you have be to able to see and interact with something), while others, are optional or on a need basis.
Front-end / Client Side:
As you said, the top most visible layer is whats called the Frontend. This is usually written in HTML, CSS for styling, and Javascript for "interactivity" and function. Of course there are more front end technologies available like Adobe's Flash. The data from this layer has to make it to the user's browser which then turns all the code into something beautiful and interactive.
From an architecture point of view, these files would be served up from various cache sources on a large web application; meaning the HTML might be served up from various "web accelerators" or reverse proxy caches (like Varnish ), while the CSS and JS files can be served from a different source like a CDN (like Akamai's, Amazon's CloudFront or Rackspace's CDN or any other)
Back-end / Server side:
Below that, you have what's normally called the "Backend" (or depending how deep your infrastructure is, a front backend: some complex web application might have a backend to render views with a certain logic, and have a "deeper" backend for more complex stuff like business logic).
The "Backend" is where you usually use a programming language (unlike HTML & CSS which are markup languages) such as PHP, Python,Ruby,Java or whatever else you fancy. The backend usually decided how to render the front-end depending on it's business logic.
Frameworks:
This is also where those "Frameworks" you mentioned come in. Think of a framework of a set of prewritten tools and scaffolding to common tasks, meaning you can use various parts of the framework to avoid writing your own. Also, if you do need to write your own solution to something, they can make it easier and simpler for you, making it less necessary to reinvent the wheel.
Each framework is language specific and they vary on how much they impose on the developer.
"Ruby on Rails" is a Ruby framework, "Django" is a Python framework, "ZendFramework" is PHP framework and "Spring" is a Java framework just to name a few.
Before a flame war starts: no framework is better than any other, they all have their advantages and drawbacks [but Django is the best :)]
There are also frameworks for the front-end such as Backbone.js, Spine.js or Knockout.js (there are plenty more) [and it might be a good place to note that Javascript can also be used as a server-side language also]
The backend layer might (I say might, because it really depends on the scale and performance you require) be using a cache layer of it's own to cache certain data to avoid going "deeper" into the stack. Some caching servers/products are "Memcache" or "Redis" for example [yes redis can also be used as a normal data store]
These are basically processes that your language of choice can communicate with that are able to store and retrieve data in memory, meaning no disk I/O is needed making them very fast to work with.
Database:
In order for most web application to function, they need to be able to store data somewhere. That somewhere is usually a database of some sort. Some big name brands and household names are MySQL, PostgreSQL, Oracle,CouchDB,Redis,HBase and the list is pretty endless.
Each one saves data in a different manner and gives different features. Some save tabled data (relational databases) while other saved "paged" data, or even simple key-value pairs.
It really depends on what you need to save and how you want is saved.
Database Abstraction:
Now your code needs to read and write data to the database... this is where the abstraction you were asking about comes into play and this also ties back to the frameworks we talked about earlier.
One way to create an abstraction is to use what's generally called an ORM (Object-relational mapping) - This layer of code is suppose to separate the code needed that data, from the data source itself - thus enabling your to make changes to one without effecting the other.
One great example of this is Java's JDO. Also, most modern frameworks supply their own ORMs with pluggable configurations for common database providers - of course each framework's ORM is for working within that framework alone (generally)
The server - Software:
Now you got everything work, but something needs to be "answering calls" and serving up what you have to offer
Everything could be running on a single machine, or on thousands of separate machines - this really depends on how your architecture is planned, and how much you need it - which is "the scale".
The server's role is to accept the "request" of some action , and run it. Once it runs "it" (could be a database query, a dynamic script or a request for a image on the disk), the sends it back. It serves.
For this, like everything, various vendors exist: Apache, Nginx, Tomcat.. the list is endless. You can also play around with combinations of these various servers on various layers depending on your needs
The server - Hardware:
Everything we talked about, has to be somewhere, a CPU somewhere has to process it.
This is basically a computer, not very different from the one you're using now only it has it's muscles where it needs them.
It can be psychical or virtual depending on your needs - but it is somewhere, in a data center connected to the internet (hopefully) by the internet backbone.
State-full / Stateless:
This isn't so much a "is there a tool for". The way you design and code is what determines if your architecture is stateless or not. This property may also vary between different points of your architecture. For example you might have stateless web servers for your guest visitors, but have state-full requests for your logged in users.
A stateless design is usually easier to scale.
Summary - A final word:
Back to architecture: from all the examples I gave, the technologies you choose and how you put them together is what makes your architecture.
You can mix n' match different technologies and vendors to create various "stacks", you can put up multiple sets of different stacks to combine into one big architecture - the possibilities are literally endless.
I hope I was able to put a little order into the chaos.
原文地址 ： http://www.quora.com/What-does-a-web-application-architecture-include
4922
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
