2.7 容量规划
容量规划可以检查系统处理负载的情况，以及系统如何随着负载的增加而扩展。做容量规划有很多方法，包括研究资源极限和因素分析。本节还包括了扩展的解决方案，包括负载均衡器（load balancers）和分片（sharding）。关于这个专题的更多内容，参见The Art of Capacity Planning [Allspaw 08]。
针对某一应用程序做容量规划，这对制定其量化的性能目标是有帮助的。第5章的前半部分有关于这一内容的讨论。
2.7.1 资源极限
该方法是指研究在负载之下会成为系统瓶颈的资源，步骤如下：
1.测量服务器请求的频率，并监视请求频率随时间的变化。
2.测量硬件和软件的使用。监视使用率随时间的变化。
3.用资源的使用来表示服务器的请求情况。
4.根据每个资源来推断服务器请求的极限（或用实验确定）。
开始时要识别服务器种类，以及服务器所服务的请求种类。例如，Web 服务器服务HTTP请求、NFS 服务器服务NFS 协议请求（操作）、数据库服务器服务查询请求（或者是命令请求，把查询作为子集）。
下一个步骤是判断请求会消耗哪些系统资源。对于现有系统，与资源使用率相应的当前请求率是可以测量出来的。先推断出哪个资源先达到100%的使用率，然后看看那时候请求率会是怎样的。
对于未来的系统，可以用微基准测试或者负载生成工具在测试环境里仿真要施加的请求，同时测量资源的使用情况。给予充足的客户负载，你能够通过实验的方式找到极限。要监视的资源如下。
● 硬件：CPU 使用率、内存使用、磁盘IOPS、磁盘吞吐量、磁盘容量（使用率）、网络吞吐量。
● 软件：虚拟内存使用情况、进程/任务/线程、文件描述符。
比如，你现在正在看的系统当前每秒执行1000 个请求。最繁忙的资源是16 个CPU，平均使用率是40%，你预测当CPU 处于100%使用情况时会成为工作负载的瓶颈。问题就变成了：在那时每秒的请求率是多少？
每个请求的 CPU% = 总的 CPU% / 请求总数 = 16 x 40% / 1000 = 每个请求消耗 0.64% CPU
每秒请求最大值 = 100% x 16 CPU / 每个请求消耗的 CPU% = 1600 / 0.64 = 每秒 2500 个请求
在CPU 100%忙碌时，预测请求会达到每秒2500 个。这是一个粗略的最好估计，在达到该速率之前可能会先碰到其他的限制因素。
上述做法只用了一个数据点：应用程序1000 的吞吐量（每秒的请求数）和设备40%的使用率。如果监视过一段时间，可以收集到多个不同的吞吐量和使用率的数据值，这样就可以提高估计的精确性。图2.20 所示的是处理数据并推断应用程序吞吐量最大值的一个可视化方法。
图2.20 资源极限分析
每秒2500 个请求的性能足够吗？回答这个问题需要理解什么是工作负载的峰值，通常按每日的访问来显示。对于既有系统而言，只要你监视过一段时间，就应该会有峰值是什么样的概念。
想象一下一台Web 服务器每天处理100 000 次网站点击。这看起来可能挺多的，但平均下来，差不多每秒只有一次请求——并不多。然而，可能100 000 次网站点击的大多数都发生在新内容更新后的一秒，那样的话峰值就很高了。
2.7.2 因素分析
在购买和部署新系统时，通常有很多因素需要调整以达到理想的性能。这些调整包括磁盘和CPU 的数目、RAM 的大小、是否采用闪存设备、RAID 的配置、文件系统设置，以及诸如此类的事情。一般是用最小的成本来实现需要的性能。
对所有可能的组合做测试，可以决定哪个组合具有最佳的性价比。但是，真这样做的话很快就会失控：八种两个可能的因素就需要256 次测试。
解决方法是测试一个组合的有限集合。基于对系统最大配置的了解有下面这么一个方法：
1.测试所有因素都设置为最大时的性能。
2.逐一改变因素，测试性能（应该是对每一个因素的改动都会引起性能下降）。
3.基于测量的结果，对每个因素的变化引起性能下降的百分比以及所节省的成本做统计。
4.将最高的性能（和成本）作为起始点，选择能节省成本的因素，同时确保组合后的性能下降仍满足所需的每秒请求数量。
5.重新测试改变过的配置，确认所交付的性能。
对于八种因素的系统，这个方法只需要十次测试。
举个例子，对一个新的存储系统做容量规划，需要1GB/s 的读取吞吐量和200GB 的工作数据集。最高的配置可以达到2GB/s，需要四个处理器、256GB 的RAM、两个双口10GbE 的网卡、巨型帧，而且不启用压缩和加密（启用这两点会降低性能）。换成两个处理器，性能会降低30%，换成一块网卡下降25%，非巨型帧下降35%，加密下降10%，压缩下降40%，减少90%的DRAM 会使得工作负载无法全部缓存。考虑到这些性能下降和对应的成本节省，能满足要求的最高性价比的系统是能够计算出来的，结果是系统带有两个处理器和一块网卡，能够满足吞吐量的需要：预估是2×(1 - 0.30)×(1 - 0.25) = 1.04 GB/s。测试一遍这套配置会是明智的举措，以防这些组件放在一起使性能和所预期的不同。
2.7.3 扩展方案
要满足更高的性能需要，常常意味着建立更大的系统，这种策略叫做垂直扩展（vertical scaling）。把负载分散给许许多多的系统，在这些系统前面放置负载均衡器（load balancer），让这些系统看起来像是一个，这种策略叫做水平扩展（horizontal scaling）。
云计算把水平扩展更推进了一步，云计算构建在许多较小的虚拟化系统之上而不是构建一个整个的系统。当用户购买计算来处理所需要的负载时，云计算能够提供更好的颗粒度，支持系统小规模且有效的扩展。与企业的大型机（包含支持承诺合同）相较而言，云计算没有一开始的大型的申购，在项目的早期也不需要严格的容量规划。
一个常见的数据库扩展策略叫做分片（sharding），把数据切分成一个个逻辑组件，每个组件由自己的数据库（或冗余的数据库组）来管理。举个例子，用户数据库可以根据顾客名字按字母范围来划分成几个。
扩展性设计很大程度上取决于你需要处理的负载和你所选用的应用程序。关于这方面的更多内容，可以参考 Scalable Internet Architectures [Schlossnagle 06]。