服务的容量规划

首先什么是容量规划;
    容量规划英文 Capacity Planning。即预先对服务的可支持性，可提供多少服务给服务使用方。

容量规划分为三步：第一步是关键指标定义，第二步是容量指标的获取，第三步才是真正的根据关键容量指标，作出容量在未来一段时期内的趋势分析。关键是掌握这个趋势，并用这个趋势去指导围绕服务进行的一系列工作，包括服务功能升级，服务性能优化，服务器采购等等。

什么才是关键服务指标呢？CPU、Mem算吗？ 按照我们的理解，这些只是基础性能指标，只是服务指标的一部分。服务指标还应该包括请求流量，请求超时情况，以及服务特有的一些指标，如客户广告库大小，用户数据量等。
因此在度量一个服务关键指标的时候，首先要搞清楚，什么东西我最Care。其次要搞清楚本服务到底是一个什么样类型的服务，是CPU密集型的计算服务，还是内存占有型的大数据索引服务，还是网络IO型服务。

在对一个具体服务模块划分其属于什么类型的时候，可以考虑打tag的方式，类似于微博中，我们每个人都有自己的标签， 而且可以有多个标签。我可以是喜欢“电影”的，也可以是喜欢“音乐”的。tag任你选择。这样我们就不会把某个服务模块局限性的划分为某种类型的服务，而只去关注他的这个方面。这样往往会故此失彼。

有了tag过后，我们在后面分析服务指标时，可以优先考虑其第一个tag，甚至还可以对每一个tag类型设定一定的权重，最后统一计算。



最理想的做容量规划的途径是什么？ 那就是完全可能一套与线上一模一样的环境，机器数，拓扑结构，系统配置，程序配置等等都一模一样。然后在其上面克隆真实环境中的流量，再对流量加大，进行预估。（流量加大也是一门艺术，怎么模拟出最真实的流量呢，特别是未来的流量？） 现不说模拟流量的问题，单单是拥有与线上一模一样的环境就是不可能的，机器数就是成本，网络拓扑结构无法真正通过缩小比例进行模拟。

当然系统配置和程序配置的同步，这个在现在看来都已经是很大的问题了。线上环境变更的同时必须也让测试环境改变。   那么测试环境在什么时候去变更为与线上环境一致呢？最理想的状态是线上做了任何变更的同时，立刻被测试环境感知，并且作出同样的改变。其实现在看来，每天凌晨的时候作出一次与线上环境的同步就可以了。


容量测试：
     就是获取整个服务的最大流量。 服务通常分为多个程序模块，每个模块的容量是不一致的，到最后就类似于水桶，整个服务的极限容量取决于最短的那一块板（即短板效应）。 我们可以如何做测试呢？ 我们可以在测试某一个模块的时候，保证其他模块的冗余充足，这样就可以测得该模块的极限承受能力C， C乘以拓扑 就得到了该模块的容量上限值。 同理可以求的其他模块的容量上限，最后就可以得到该服务的容量上线。
     这时也有一个问题，可能该服务还依赖于外部服务， 没有关系，我们紧紧是要测试本服务的容量上线，对于其他被依赖服务，可以暂时认为他们的容量是无穷大，整体上来说容量测试只与本服务自身模块有关。


一个容量测试系统，需要具备的是足够开放，足够可扩展。怎么理解？
足够开放，即你可以提供给外部系统查询，管理容量测试过程，可以触发自动测试，定时测试等。
足够可扩展，要求该测试系统可以普遍应用于同一类型的其他服务，而不需要做太多的改变。也就是开放封闭原则---对扩展是开放的，对修改是关闭的。