构建Web应用程序可能是相当容易的，但要构建可扩展的Web应用程序却比较困难。在小规模时可以正常工作的技术和技巧，在规模增大后却可能会失败。要避免将来浪费大量的时间和精力，应该预先考虑好扩展的问题，这样能确保构建小规模程序时工作良好，而且也能够进一步处理大流量的应用程序，不必将体系结构推倒重来。
一个中等大小的Web应用程序，每天要服务于一千万个页面，还需要处理百万级的用于Ajax交互的请求（假定应用程序需要某种API，这个我们待会再谈）。一天一千万个页面，即需要每秒支持116个页面，根据具体的流量情况，在高峰期还可能达到它的两倍或者三倍。如果平均下来每个页面有10个数据查询，那就是每秒超过1000个查询（QPS），高峰期是3 000QPS。对于一台机器而言，这可是很多数据库流量，那么，应该怎么设计系统来达到这个速度，还要能进一步扩展它，并且提供可靠性和冗余？
设计可扩展的系统要基于一些我们将要讨论的核心原则，我们还要研究用于扩展应用程序的各个部分的具体技术。
The Scaling Myth
扩展和可扩展性一直都是Web应用程序开发人员的热门话题。每当需要构建服务于大量人群的Web应用程序时，扩展就成了问题：怎样才能支持一百个用户？一千个？一百万个？一亿个？虽然扩展很久以来就是个热门话题，但对它的深入理解却很缺乏。在开始讨论如何设计可扩展的应用程序之前，需要明确定义所谓的“可扩展”。
What Is Scalability
可扩展性有时被定义成“具备可扩展性的系统或组件，可以很容易被修改以适用于问题域”。这个定义非常模糊，让人困惑。其实可扩展性很容易定义。一个可扩展的系统有三个简单特性：
1.系统能够容纳使用率的增加
2.系统能够容纳数据集的增加
3.系统可维护
在深入这些具体条目之前，先谈谈可扩展性不是什么，消除在当前Web开发中常见的一些谬误。
可扩展性不是指原始速度。性能和可扩展性是不同的问题。你很容易就可以有一个不可扩展的高性能系统，虽然反过来的情况并不常见——一个系统可以扩展，那么你总能通过扩展它来提高性能。一个系统在1000个用户和1 GB数据的情况下非常快，并不意味着它是可扩展的，除非它能够在10倍当前用户和10倍当前数据的情况下仍然保持现在的速度。
可扩展性跟用不用Java无关。用任何语言任何工具构建的系统都能变得可扩展，虽然不同语言和工具造成的相对难度肯定会是个问题。Java近来和可扩展性走得如此之近，以至于很多人把两者当成是相同的。再重复一次：不用Java就可以构建一个可扩展的应用程序。类似的，编译语言不是设计可扩展系统的必要条件。本地代码，即时编译，和编译过的字节码虚拟机能做到又好又快，但那是性能问题，而不是可扩展性的问题。不管怎么说，这一段可不是专门为了打压Java的。使用Java来创建可扩展的应用程序完全是可能的，只是说具体实施语言和系统的可扩展性之间的关系很小。
实际上，可扩展性跟使用特定的技术完全无关。另一个常见的误解是XML是可扩展性的核心——这完全是胡说。XML对互操作性很有用，但互操作性和可扩展性两者不是一回事。你可以拥有既不读也不写XML的可扩展的程序。在James Clark想出这个特别的缩写之前，可扩展的系统早就存在很久了。
可扩展性有时被描述成是页面逻辑和业务逻辑的分离，就像我们在第2章中讨论的那样。虽然这是一个很崇高的目标，而且有助于系统的维护，但它也不是必需的。我们能创建这样的可扩展系统——使用PHP，只包含一个层次，没有XML，没有Java，甚至速度也不快：
<?php
sleep(1);
echo "Hello world!";
?>
我们提供的示例“系统”速度不快——它总需要花一秒钟来响应。然而，它很好的满足了三条可扩展性标准。可以通过增加更多Web服务器来容纳更多流量增长，而代码无需任何改动。能够容纳数据集增长，因为根本就没有任何存储的数据。代码也是非常易于维护的，没有哪个训练过的程序员是不知道如何维护它的——例如，让它改说“Hello there”。
Scaling a Hardware Platform
说到扩展体系结构的两种主要策略时，是从硬件的角度讨论提高性能的方法的。在项目初期，硬件看起来总是很昂贵，但随着时间地推移，软件成本变得昂贵得多（到一定程度，对于超大的应用程序而言，两者角色又会交换）。因此，构建应用程序时，应该想法让它能够不需要或者很少需要软件就能扩展；买更多的硬件，使用更多硬件来扩展要更好一些。
接着的问题就是“应该构建可纵向扩展还是可横向扩展的应用程序？”，这两个术语的含义有时可能互换，所以先定义一下。简单的说，可以纵向扩展的系统需要相同硬件的一个更为强大的版本来扩展（抛弃原来的硬件），而可以横向扩展的系统需要当前硬件的复制品来进行扩展。实际上，对于大型应用程序而言，两者中只有一个是有实际意义并且有成本效益的。
Vertical Scaling
垂直扩展的原则很简单。开始的设置非常基础——可能就是一台Web服务器和一台数据库服务器。当机器性能不足时，用更加强大的机器替换它。新机器能力不足时，用另外一台机器替换它。这台机器能力也不足时，就买一台更加强大的机器。如此反复。
Horizontal Scaling
水平扩展内在原则上和垂直扩展相似——不断添加更多的硬件。不同于垂直扩展模型的地方在于，增长时不需要超级强劲的机器，而只需要很多常规的机器。从一台常规的机器开始，其能力不足后添加第二台。然后添加第三台、第四台，等等。直到有上万台服务器（就像当前最大的应用程序那样）。