随着Web 2.0网站的蓬勃发展，如何成功地构建可扩展的Web站点成为网站开发人员必备的技能。本书是Flickr.com的主力开发人员讲解构建可扩展的Web站点的经典之作。本书主要介绍了Web应用程序的概念、体系结构、硬件需求、开发环境的原则及国际化、本地化和Unicode等基本内容，并为解决Web应用程序的数据安全、电子邮件整合、远程服务交互、应用程序优化、扩展、监测和预警、开放API等问题提供了很多简单实用的技巧和方法。这本书涉及的内容十分广博，但核心相当明确，即如何建立安全的、用户喜爱的、可以不断扩展的Web应用程序。任何从事Web应用程序开发的读者都会从中获益匪浅。

前言
第1章：绪论
　什么是WEB应用程序
　如何构建你的WEB应用程序
　什么是体系结构
　怎样开始呢
第2章：WEB应用程序体系结构
　层次化软件体系结构
　层次化技术
　软件接口设计
　从A到B
　软件/硬件的划分
　硬件平台
　硬件平台的增长
　硬件冗余
　网络
　语言，技术和数据库
第3章：开发环境
　三大规则
　使用源码控制 　

Flickr是Web 2．0世界当之无愧的佼佼者。作为Flickr的架构师和主力开发人员，Cai Henderson在Web 2．0开发领域可谓大名鼎鼎。他所著的这本书集知识性、实践性和可读性于一身，一经出版即好评如潮。.
本书中，作者不仅介绍了很多在Flickr开发过程中积累下来的宝贵经验，并且力图将Web开发实践中可能遇到或思考的方方面面的问题、所进行的种种权衡，以及所获得的一些好的解决方案与大家分享。也许在读完本书的那一刻，你会深深地感觉到他已成功地实现了这个目的。
Web2．0时代，虽然Web开发会涉及很多不同的技术和标准，很多人仍然认为构建一个网站是一件比较容易的事，事实却并非如此。
如果你只是要实现一个有着绚丽界面的个人主页或者用户数量有限的小站点，那确实比较容易。如果构建一个每天有数百万流量的Web应用程序，显然就不怎么轻松了。比如，它必须能够为各种语言的用户提供服务，包括中文；它必须能确保用户数据安全和承受恶意的攻击；它必须具备优秀畅通的电子邮件系统；它还必须能用各种方式(包括REST、XML-RPC和SOAP等)和外部的服务交互。这样的系统该如何设计呢?
如果为了给更多的用户提供服务，这样的系统必须进一步扩展。Web开发人员又该解决哪些问题，具备哪些能力呢?显然，开发人员必须具备找出和解决系统瓶颈的能力；必须能够做好系统的设计，让系统能够不断地扩展，最好是能够通过添加硬件(无需再次开发)就可以实现线性的扩展；还需要系统提供完善的监测和警告机制，让系统维护人员能够了解整体的状态，防患于未然。..
应用程序的本质其实就是操作和共享数据，Web应用程序也不例外，只是它们被限定在网页上。作为Web 2．0的一个新特色，公用的APl是许多Web2．0网站成功的秘密武器之一。这些公开的API不仅拓宽了应用程序的受众，更丰富了用户使用方式和用户体验。那么该如何安全有效地为公开你站点的API，并承受公开API可能带来滥用的情形呢?
从上面的种种问题可以看出，Web 2．0站点不是只靠新技术就可以方便快捷地搭建起来的。丰富的开发经验和设计经验、良好的团队合作(书中有一章专门介绍了如何建立良好的开发环境)，甚至需要对硬件一定程度的了解都是构建起一个成功的大规模可扩展的Web 2．0站点所必需的。
本书很好地回答了上述种种问题，并且选用了一些优秀的开源软件搭建起整体技术框架，如MySQL、PHP和Subversion等，为大家提供了一套经济实用的Web站点开发的解决方案。我个人有一些Web开发经验，在翻译本书时也受益匪浅，觉得这是一本特别值得向广大正在或有志于Web开发的人员推荐的好书。
作者丰富的实际经验为本书奠定了坚实的基础。本书涉及的内容广泛，翻译欠缺之处还望大家见谅和不吝指正。此外，感谢在我翻译本书过程中朋友陈黎夫和博文视点各位编辑的帮助指导，以及我太太的支持和理解。...
是为序。
徐 宁
2007年12月于上海

我建立的第一个Web应用是Terrania，访问者可以在网站上创建一个定制的虚拟生物，然后在一个虚拟的世界中跟踪这个生物的成长过程。它会四处游荡，吃些植物(或其他动物)打打仗，或与其他玩家的生物交配。系统汇总生物当天发生的事件，每天两次通过电子邮件发送给玩家。
称之为Web应用可能有些过了，当然，我当时也不会把它这样分类。游戏的核心部分用C++编写，运行在单个机器上，从单个文件加载游戏数据，处理游戏林林总总的事，并将一切再保存到单个文本文件中。当我开始构建这个游戏时，运行时肯定是要成为C／S游戏架构的服务器端的。当时的网络编程中，数据交换非常困难，仅仅为了在服务器与客户端之间交换字符串就需要编写大量的机械代码(当时还没有．NET)。.
Web给应用程序开发人员提供了一个随时可用的平台，该平台可以在网络上传输数据，避免了C／S应用程序的麻烦部分。我们可以按自己喜欢的方式建立服务器，让它完成有趣的工作，而使用简单的HTML建立客户端，可以完成相对来说比较琐碎的工作。Terrania中传统意义上属于客户端的部分现在被移到了服务器端，只需简单地访问原服务器端使用的文本文件。对于“客户端”程序的大部分页面，我们只需将文件加载到内存，解析出这个玩家感兴趣的生物，然后以HTML形式展现一些静态信息。创建一个新的生物只要将一块数据添加到下一个文件的末尾即可，服务器每次运行时，都会读取这个文件，并进行处理，将新生物添加到游戏中。所有的游戏处理逻辑，包括汇报成长状态的电子邮件，都是由服务器组件完成的。Web服务器的“客户端”接口只是简单的C++CGI应用程序，它用几百行的源代码就可以解析游戏数据文件了。
这个系统是相当令人满意的，或许由于当时没有遇到什么问题，所以我没有注意到其局限性。一般来说Web接口会缺乏互动性，但对这个系统，它没造成什么大问题，因为这本就是游戏设计时考虑过的问题。惟一要由玩家进行写操作的就是创建生物的初始部分，之后的游戏对玩家而言就是只读的。另一个没有遇到的问题是并发性。由于Terrania是大型的只读游戏，可能有任意数目的玩家同时生成页面。所有这些写操作都是简单的文件附加操作，比较迅速，因而不会造成长时间轮询等待加锁的情况。此外，游戏玩家也不会多到两个玩家同时读或写。
过了一些年，我才有机会进行一些更加类似于Web应用程序开发的工作。我在一家新媒体办事处工作时被要求修改一个留言板产生的一些HTML输出，该留言板使用了UBB(Ultimate Bulletin Board来自Groupee，Inc．)技术。UBB用Peri编写，以CGI方式运行。应用程序数据条目，如用户账户，以及组成讨论的消息，都以定制格式存储在文本文件中。这个应用程序中的一些网页是动态的，从使用中的文本文件读取数据进行创建。其他页面，如讨论本身，还是文本格式的HTML文件，在需要时由应用程序写入磁盘。这种“写入磁盘”的技巧目前仍然在一些需要低写入／高读取的应用中使用，比如说博客，对它而言，动态产生被读取页面的成本高于将文件写入磁盘的成本(和读相比，写操作可是非常慢的操作)。
UBB的出彩之处在于它是用“脚本”语言Perl写的。源代码无需编译，这大大加快了开发周期，能够更加容易地进行修订，而不用每次修改就得花好多天。它的源代码被组织成三个主要文件：用户实际请求的终端脚本和两个类文件，类文件中包含了工具类函数(并被认真地命名为ubb_library.pl和ubb_library2.pl)。
我为几个商业客户服务时使用了UBB并得到一些相关的经验之后，较深入地参与了留言板“黑客”团体——他们是一群奇怪的人，花费时间为现有的留言板软件添砖加瓦。我和另一个人建立了一个叫做UBBHackers的站点，他后来成为Infopop的程序员，并编写下一个版本的UBB。
早期的UBB并行能力很差，因为它依赖不可移植的文件加锁代码，而这些代码无法在Windows上工作(它也是目标平台之一)。如果两个用户同时回复同一个线程，该线程的数据文件就可能会损坏，并会导致数据丢失。随着系统用户数目的增加，数据损坏和竞争条件的几率也随之增加。对于真正活跃的系统，向磁盘写入HTML文件的操作很快会在文件I／O方面导致瓶颈。从现在的眼光来看，下一步该如何做是显然的，但当时可不是如此。
MySQL 3为Web应用程序带来很多变化。在有MySQL之前，使用数据库来存放Web应用程序的数据可不容易。当时可用的数据库技术如果不是非常昂贵(Oracle)，就是缓慢而难以使用(FileMaker)，或者就是配置和维护复杂得让人难以置信(PostgreSQL)。MySQL3可用之后，事情逐渐发生了变化。PHP 4得到广泛接受， phpMyAdmin项目也启动了。phpMyAdmin意味着Web应用程序开发者不需要FileMaker的可视化设计工具，也不需要学习那些从命令行界面进行控制所需的晦涩的SQL语法，便可以开始使用数据库。即使到现在，我也记不起创建一个表格或者给予一个新用户访问权限的正确语法，但我已不需要记这些东西了。
MySQL为开发者带来并发的能力，让我们可以同时读数据和写数据，而不会无意中损坏数据。随着MySQL的发展，我们将能得到更高的并行能力和更好的性能，远远超出文本文件和写磁盘技术所能达到的极限。通过索引技术，我们可以选出任意的集合数据，并随心所欲地加以排序，而不用把这些数据全部加载到内存中和遍历相应数据结构。当前的Web应用程序还在不断挑战现有的极限，这个目标可以通过所谓的扩展性、功能性和互操作性达成。随着公有API的激增，组合多个程序以创建新服务的能力带来了面向服务的风尚。API服务模型清晰地向我们展现了该如何设计应用程序的体系结构，以获得灵活性和低成本。
当前最大也是最受欢迎的Web应用程序，比如Flickr、Friendster、MySpace和Wikipedia，每天处理数十亿的数据库查询，有超大的数据集合，并且运行在由经济型硬件设备组成的大型硬件平台之上。Google可算作超大型应用程序中的骄子，而其他相对较小(实际上还是规模巨大)的应用程序正在成为下一代应用程序的标杆，被打上了Web2．0的标签。随着读／写交互性的增加网络能力的提高以及开发式的API，下一代的Web应用程序开发将会是非常有趣的。..
这本书讲什么
本书主要内容是Web应用程序设计：对Web应用程序的软件和硬件系统的设计。我们会讨论程序体系结构、开发实践、技术、Unicode和通用的基础性的工作。书中同等重要的是Web应用程序的开发：建立硬件平台的实践和实现我们所设计的软件系统。尽管应用程序设计的原理很好(也是整个过程的基础部分)，但还是要认识到在构建大型应用程序的过程中实现扮演着非常重要的角色，而且要在设计过程中时刻牢记这一点。如果是在设计一些无法构建的对象，那么就无从判断设计是否正确。
本书并不是关于编程的，至少不完全是。和讨论代码片段、函数名称等相比，实际的重点在于探讨构建Web应用程序所需的通用技术和方法。虽然本书确实包含了一些示例代码片段，但他们也仅仅是示例而已。书中大多数示例代码都只能在更大的应用程序中或者在底层框架中使用。
将要探讨的很多内容都和设计应用程序体系结构和构建应用程序的底层框架有关。在Web应用程序领域，底层框架大多是指硬件平台、软件平台、维护和开发实践的组合。我们会考虑如何将它们整合在一起为大型应用程序构建一个无缝的底层框架。
本书中最长的章节(第9章)只谈和应用程序扩展相关的内容：以可扩展性为目的的体系结构的设计方法，以及可以帮助扩展现有系统的技术和技巧。虽然这个领域很难用单个章节进行全面的探讨(即使一整本书也只能覆盖基础部分)，但对那些需求较常见的应用程序我们还是挑选出了一些最为有效的方式方法。但要注意，本书不是针对扩展的详尽指南，除了提到的内容，还有很多东西要学。如果想要一份全面的对可扩展的底层框架的介绍，你可以选择这本书看看，Performance by Design：Computer Capacity Planning by Example(Prentice Hall)。
在本书末尾(第10章和第11章)，讨论的是如何保持Web应用程序长期运行，并提供事件监测和长期统计，以进行容量和性能规划。如果想要创建一个应用程序并且长期管理它，那么监测和警戒是你所需要的核心技能。对于有定制组件的应用程序，或者只是有很多组件的应用程序，设计和构建探测器、监测器的任务往往落在应用程序设计人员的头上，因为他们最了解哪些是需要追踪的，以及什么状态是警戒状态。对于系统中的每个组件，都需要设计出某种方式，来检查它能工作并且在正常工作。
在最后一章，讨论了数据共享技术，还有通过数据订阅地址和读／写API，允许其他应用程序整合我们的应用程序的技术。本书中，我们一直在考虑，在处理我们应用程序中的不同组件时，如何进行组件API的设计，但在最后一章中，则在研究各种不同的方法，来把这些接口以一种安全和可访问的方式展现给外部世界。我们还会看到演化得来的用于数据导出和交互的各种标准，以及如何在应用程序中使用它们。
你需要知道的
本书不适用于刚刚开始构建第一个动态Web站点的人。对于新手已有很多不错的书，因此我们不打算讲述那些基础内容。所以，你得有一些构建动态Web站点或应用程序的经验。至少你应有通过Web页面展现给用户编辑的数据和管理用户数据的经验。虽然本书的重心不在于具体实现，但还是提供了很多实际的示例。要能完全消化这些示例，需要基本编程方面的知识。固然不需要continuation或者参数currying方面的知识，但你至少得有些简单的控制结构和基础的冯·诺伊曼输入一处理一存储—输出体系方面的工作经验。除了示例代码，还要看相当多的基于Unix命令行环境的示例。如果能访问一台Linux机器(或者其他Unix变种)，那会让你的生活轻松好多。有一台可用的服务器让你输入那些命令和代码，会让所有内容都更加容易理解，并且能立即给你实际使用的体会。本书假定读者有命令行的工作经验，书中不会讲解如何启动一个shell，执行一个命令，或杀掉一个进程。如果你在命令行方面是个新手，那在进一步学习之前应该选择一本介绍性的书——命令行的经验对基于Unix的应用程序是基础，即使对基于Windows的应用程序命令行也正变得越来越重要。