之前在接到一个项目需要进行重构，原来的老系统处于安全与维护性查的原因要进行替换。这个时候有一个问题来了那么就是老系统虽然不好，但是磕磕绊绊的也支撑了近10亿的访问量，虽然这个访问量来源的准确性也有待考证。
那么在这样的情况下，我们新设计的系统，要至少保证系统的稳定性是好的，系统的抗压能力是强的，这样就需要确定几点，目前我们的新系统的稳定性如何？抗压性如何？部署多少台机器或者说节点才能够支撑原有的量级，后续请求量上升到多少需要进行扩容，每次扩容的标准又是多少？
因为之前的系统并没有详细对这些进行规划，也没有一些详细统计。所以在新系统中要去参考以前历史的访问量很难做到。那么一般会是说从业务方那边去了解这些信息，但是业务方给的信息又是比较模糊或者不全面的，只能给到最近几天的一个估算请求量，这个的数据参考价值不大。
在没有相关指标的情况下，就需要自己去挖掘与判断，并给出一定的标准。
请求量评定的做法：
1.根据业务方评估出来的请求量Q/10(小时)*3600=（平均）QPS,因为一天24小时，主要的交易一般是集中的活跃的一定时间点内，所以在小时计算上做了缩减。
2.平均QPS做了简单确认后，还需要考虑高峰期的峰值，根据以往业务的相关经验来估算，大概是5倍的量。
根据以上两点，我们获得了目前新系统集群需要支撑的平均QPS、和峰值的QPS。这个时候我们需要确认目前新系统单点能支撑多少QPS？我们能有多少机器来搭建新系统？
第一个值得获取就需要我们用性能压测的方式来获取，这里我们使用的JMETER进行压测，并不断调整和优化（这里也遇到了很多坑，后面文字会说如果返现并填坑的）。当然这个调优标准一个是QPS，另一个就是业务方需要的响应时间。当时我们的要求是响应时间在30ms以下。那么在RT确认的情况下，单点机器所能跑的最大的QPS也就基本上确定了。
根据单机的QPS值和总体集群的QPS就很容易能计算出来我们需要多少节点了。
本文出自 “海上雪鹰” 博客，请务必保留此出处http://mickelz.blog.51cto.com/4276333/1842357
原文地址：http://mickelz.blog.51cto.com/4276333/1842357
