做服务运维的人员除了解决各种杂七杂八的问题之外，还要时刻的关注业务的增长和服务的容量问题。

要对容量有一个准确的评估并不容易，要考虑的因素比较多，突发的情况也比较多，另外有些时候容量的增长并不是一个线性的过程。

以下是我对容量规划的一些体会

首先是要对系统的构架有足够的熟悉，明确的知道系统的扩展瓶颈在那里，以互联网产品来说大部分的扩展瓶颈都是在DB上，这种情况下，DB的扩展能力就是容量规划的一个极限。从构架上来说，分库分表，增加Cache层都是提升DB扩展能力的手段，使其扩展更趋向于线性。

其次，对整体系统和单一系统进行压力测试和容量测试，找到最大承载和最佳承载。

最后，要建立一个业务数据和系统能力间的关系公式。假定业务数据是日活跃用户(DAU)，以Web服务来说，每秒请求数(RPS)就是一个很好的指标做参照。使用RPS比上DAU得到一个RPS/DAU的比率，再结合之前测试的最佳承载，就可以得出值得参考的容量规划。现实情况要更加复杂，特别是有些业务系统涉及的因素比较多，就要拿到多个因素的比率，以其低点为参照。比如DB，在关注存储容量的同时还要关注请求数以及响应速度等多个指标，所以关系公式也就要考虑多个因素进去，按每个因素算出容量，再取其中的最大值。

容量规划本身是一个参考值，估算的精确非常有助业务的发展和成本的节约。同时他作为一个参考值又需要不断的根据业务特点和构架变化作出调整。

Last modified on 2012-08-07