1、通过监控规划容量
监控的方法有很多，最简单的就是利用一些系统命令，如用df命令来查看磁盘使用率，然后每天出报表，通过查看报表运维人员监控系统压力及容量，当逼近系统压力上限时，发出报警，提醒扩容。
这种方法不能作为主要的监控手段，仅用来辅助监控之用，毕竟监控是为了实时了解系统的状态。
在监控系统中我们都会设置报警阀值，在监控图中我们都会看到逼近报警阀值的紧迫程度。如果接近了阀值，运维人员便开始扩容。
扩容的前提是压力趋近于模块的极限，如某模块每秒最大处理的请求数（qps）是300个，当实际qps接近于250左右时就要考虑扩容了。如果判断模块已经接近了最大处理极限呢？一种方法是在程序的日志文件中增加请求处理时间的字段，这样针对每个请求的处理时间我们便清楚看，如果任何页面的处理时间太长的话就要考虑扩容了。这里所说的处理时间并不固定大小，还是要根据业务场景结合，如果页面是消耗CPU资源，在不考虑阻塞的情况下，该页面的处理时间就不应该太大，最大不超过几百毫秒，如果该页面功能和存储或外网相关，就要相对长一点，超过1秒是很正常的。
2、通过压力测试规划容量
为了获得系统的容量，可以让运维人员搭建一套线下的测试环境，通过压力测试并结合监控来找出系统的极限值。最常见的压力测试工具有ab(Apache Bench)额Jmeter，LoadRunner。
如果集群中原本有10台服务器，先去掉其中的4台服务器，只让剩下的6台服务器提供服务，测试人员通过观察机器压力负载或日志输出的信息等手段来判定服务的稳定性。如果服务正常的话，继续从集群中下掉一些服务器，直到服务器压力越来越大，线上业务报错为止。
3、通过经验预估容量
利用监控系统，找到近期内的最大流量作为未来短期内的流量预估，如果在当时的流量压力下系统运行正常的话，可以使之作为新的容量参考。可以将半个月内的最大流量峰值作为未来一个月内的评估流量，如果该峰值下系统工作正常，这通常表明未来一个月内是不需要扩容的。
4、按比例扩容
还有一种估算的方法下，按照原有系统的负载情况下按比例扩充，当然这全是假设在理想的线性情况下。
如果目前流量是每天1200万PV，各个子系统的平均容量是40%，一般情况下为了系统稳定都不会把容量用尽（100%），都会预留20%左右的buffer，因此，认为80%便是极限利用率了。80%减去40%后还剩下40%，也就是说目前系统还能承受一倍的流量，也就是2400万PV算是极限了。更是预估新的流量压力是十倍的话，至少将原有系统的规模扩充为原来的5倍。
5、通过回归方程规划容量
容量规划的关键就是找出系统可承载的最大压力，然后根据极限压力再做部署规划，话说的容易，其实这往往是最困难的压力。服务器的性能是不好估量的，看不到摸不到，其容量只能通过实际测试才能得到，而且大多数情况下各个机器的性能是不一致的，一台服务器的容量数据不能作为其他机器的标准，总之各个服务器都有自己的极限容量。
容量评估就是用现在的数据预估未来的变化。
