1 背景
某年某月的某一天，有这样的一段对话：
老板: 咱们线上容量是多少?
小强: 额，不太清楚
老板: N天后，我们的流量将增大M倍，系统能抗住吗?
小强: 可能扛不住吧，不过我们可以扩容
老板: 扩多少?
小强: （拍脑袋）double一下吧
“double一下”是否可以解决问题？存在多大的浪费？如何有效评估系统容量来解决这个窘境?
在这里引出一个系统容量的概念。系统容量，指系统在有冗余的情况下的极限服务能力，可以理解为是水池的水位。当水位超过警戒线的时候，需要对系统进行横向/纵向的调整。
系统容量需要预留冗余，是因为我们要保证在部署、网段故障、机房故障时，线上服务依旧是可用的。
综上，可以得出公式：系统容量 = 单实例极限容量 * 当前实例数 * 冗余度
2 流行的方案
- jmeter
- 扩大单个实例的流量
- tcpcopy
2.1 jmeter
构造测试数据，进行接口级测试，观察服务表现
优点：灵活，可对特定接口进行针对性压测
缺点：很难模拟真实的流量场景（线上的接口太多，各接口的流量比例不同）
2.2 扩大流量
通过调整权重或缩减集群规模，将线上流量压到单个服务实例上，观察服务表现
优点：真实
缺点：在压力过大时可能造成服务质量下降，影响用户使用。
2.3 tcpcopy（推荐）
拷贝线上流量，对旁路环境进行压测
优点：真实，不会影响用户
缺点：需要准备完整的旁路环境
3 性能指标
不管采用什么样的压测方案，我们需要知道压到什么程度就是“极限”了。
对于在线类服务，最关注的是服务的响应时间，可以是所有接口的平均响应时间，也可以是某些接口的平均响应时间。
由于压测环境不是线上真实的服务器，需要单独搭建一整套供压测的环境。
建议按线上的部署比例进行等比例缩放压测环境的实例数。
