时过境迁，搭建 Web 应用连“轮子”都要自己做的时代已经过去了，如果你需要构架一套小型或者是中型的 Web 站点，现在已经不需要为服务器、机架、托管和安装系统而操心，选择一家优秀的网格托管技术提供商，再搭配一个构架在“云端”的虚拟存储服务（如果有大量数据存储的需求），挑选你自己最擅长的 Web 应用开发技术和前端呈现技术，最后再实现当下流行的各种 Widget 和 Social 接口，就能将自己的 Web 服务武装到牙齿了，而且噱头十足。
Dion Hinchcliffe 先生在他的《Tips for Building Next Generation Web 2.0 Applications》一文中为这些应用架构做了清晰的总结，indigo 将他的图稍作了一些更加概括性的调整。
新一代 Web 服务的四层架构：基础层、应用层、分布层 和 社会层
next-generation-web-infrastructure
1. 基础层（3rd Party Web Infrastructure）
除非你有自己的机房或者数据中心，不然我们的数据就都是交给第三方托管的。按照旧有的托管概念，选择服务商，托管设备，所有的应用逻辑都在这些设备里面完成，计算、存储、数据库全部自己解决，需要大量的设备和维护人员，现在这些基础的逻辑服务可以完全交给不同的第三方公司通过网格托管（Grid Hosting）和云计算（Cloud Computing）服务来帮你实现。
我们可以把基础层想象成那些第三方已经实现好的程序模块，它们更像是操作系统提供给我的系统功能一样，程序运行空间、磁盘读写服务、CPU 调用接口和各种 IO 服务。
通过传统的网格托管，例如 3Tera 的 AppLogic，还有 MediaTemple 的 Grid-Service，在一定程度上不用为系统的分布式和访问负载担心，直接想服务提供商购买额外的负载能力就行。OpenID 可以实现统一的身份验证，现在 Google 和 Yahoo 的帐户都能进行这种认证；Amazon 的云计算服务 S3、SimpleDB 和 EC2 分别提供了虚拟的存储、数据库和应用计算托管的服务，还有 Google 最近推出的 AppEngine，你只需要将程序代码部署到这个 Web 应用容器之中，就能够使用 Google 完善的分布式网络架构了（感觉这是 Google 最伟大的一个项目了）。所以说，现在搭建一个 Web 服务最核心的技术需求已经能够完全在这些第三方的平台中完成。当然，像第三方的搜索服务（Google Coop）、地图服务（Google Maps）、消息队列服务（Amazon SQS）、即时通讯服务（Google Talk），我们也都能够将其作为基础功能整合成为自己服务的一部分。
2. 应用层（Application）
Web 服务的业务逻辑和实现方法都在应用层解决，它们在基础层提供的虚拟程序空间里面运行。套用最经典的程序开发模型——文档视图模式（MVC），应用层就是要来实现 Web 服务的数据模块（Model）、控制模块（Controller）和呈现模块（View）。
Ruby 和 Python 这两个小巧灵活的动态语言现在成了实现新一代 Web 应用的新宠，很多出色的 Web 应用都通过 Ruby on Rails 框架来实现（例如 Twitter 和 37Signals 的所有服务），同时 Python ＋ Django 则成为了 Google AppEngine 的首选开发框架，在这种新构架之下，编程语言的开发效率，灵活性和运行平台的支持度成为了关键因素，我们需要实现的更像是基础服务的粘合剂，通过快速的组装来提供应用，而不用去考虑语言的执行效率和语言自身有多么完美。
在数据端，MySQL 仍然是 Web 应用的主流数据库系统，但现在很多复杂的业务都被基础层所封装，Rails 和 Django 框架中的数据对象模型正在被广泛采用，提高开发效率并简化查询方式是大家使用的主要动力，当然还有像 SimpleDB 和 AppEngine 这种虚拟服务的推动作用。
在用户前端，浏览器是绝对的标准和主流，因此支持好 HTML，Javascript 和 Web 标准就不会有任何访问的障碍和方向性的选择错误，如果还需要更酷的效果，Adobe 的 Flash 会是个不错的选择，至于 Microsoft 的 Silverlight 嘛，革命尚未成功，同志还需要努力。
3. 分布层（Distribution）
新的 Web 站点和服务将不再是信息的孤岛，对外暴露自己的数据显得尤为重要，Web 应用就像生物组织内的细胞，它们获取来自外界的能量，同时也产生能量输送给整个生物体。分布层就像 Web 服务的接口，其他的 Web 服务可以通过这些标准接口接入进来，自己的内容也可以输出给其他服务。
有一点需要牢记，想让自己的服务在今后的互联网中有立足之地，开放你的接口吧，不管是 REST 流的还是 SOAP 派的，因为除了人在访问你的网站之外，还有大量的机器和服务程序对你的应用感兴趣，让自己的服务成为别人业务逻辑的一部分之后，基本算是成功了（看看 flickr 是如何开放成为全球最大的照片托管服务的）。那些开放的 APIs 是被动的等着来访问，你还需要主动出击，通过 RSS、ATOM 和 Ping 这种特性来通知其他服务你更新了内容。
各种页面嵌入的 Widgets 和电脑桌面与手持设备使用的 Gadgets 也是输出服务内容必备选项，Widget 的形式更容易被其他的 Web 服务整合，例如 iGoogle 和 Blog 的 Sidebar 上。让数据能够更加方便的输出，同时也提供给第三方数据输入的机会，这是在“分布层”应该做的最重要的事情。
4. 社会层（Social）
无论什么样的 Web 应用，最终都需要有人的参与，人与人之间的行为相互影响，自然就形成了社会效应，不管参与人数的多少还是服务规模的大小，在这个架构的最上层，就是要平滑的实现 Web 用户之间的信息流通，所以我们称其为“社会层”。
经过多年的进化，社会化的标配应用形式已经成型，Blog（文字的、图片的和视频的都算），论坛 和 各种 Wiki 形式的内容分享，它们像网站的内容骨架，无论何时都可以考虑使用这几种应用形式。现在还多了 twitter 方式的 MicroBlog 和 facebook 形式的 WebIM，也许今后会成为网站标配的一部分。
Social 的思想已经深入人心，只要有用户登录和身份的网站就会好友关系（Friends List），好在 Google 已经为大家准备好了 OpenSocial 标准和 FriendConnect 服务，还有 facebook 的 Connect 服务，这两个公司致力于维护用户身份的唯一和好友关系的统一，无论在哪个网站上登录，你就是你，你的朋友也都是那些老朋友，不用重复填写档案信息，也不用重复添加好友，很理想，很完美主义 …
不管是 Google 帮还是 facebook 派，或者始终特立独行，社会性的 Web 服务都需要有好友关系、用户档案（Profile）和用户活动流（Activity Stream），在还没有行业标准的情况下，可以使用 Google 的 OpenSocial 格式来输出和提供接口。这些用户的数据会被订阅，被聚合网站读取，或者被其他的服务分享，拥有这些数据的人就会更乐于推荐和使用你的服务，所以让用户的数据在不同的服务之间流动起来，这个才是网站社会化的精髓所在。
除了技术架构之外…
当然，构建优秀的 Web 应用，只靠清晰的技术架构是远远不够的，你需要对 Web 2.0 有深刻的理解，熟悉 Web 2.0 的编程思想、知道 如何激发网络效应 、利用好集体智慧，还需要拥有优秀的团队，适合新网络应用的 产品开发方法 和 简单易行的处事方法（Getting Real 一些比较好），最后还需要一点点运气和机会。
这篇文章是根据 Dion Hinchcliffe 先生在 Web 2.0 Expo ’08 大会上的关于 “Building Next-generation Web 2.0 Applications” 议题的整理。大家对下一代 Web 应用架构有什么建议或者想法，都可以在这里留言交流 
如果您订阅了 “indigo 的 数字镜像” 或者经常访问，点击这里就可以加入 indigo 的 friend connect，成为小站的一名成员，让 indigo 和大家都认识一下浏览器前面的你 …
通过 RSS 来订阅 indigo 的更新
Google Reader 阅读
通过鲜果来阅读
通过抓虾来阅读
用 IM 软件接收更新
