1 背景

某年某月的某一天，有这样的一段对话：

老板: 咱们线上容量是多少?
小强: 额，不太清楚
老板: N天后，我们的流量将增大M倍，系统能抗住吗?
小强: 可能扛不住吧，不过我们可以扩容
老板: 扩多少?
小强: （拍脑袋）double一下吧

“double一下”是否可以解决问题？存在多大的浪费？如何有效评估系统容量来解决这个窘境?

在这里引出一个系统容量的概念。系统容量，指系统在有冗余的情况下的极限服务能力，可以理解为是水池的水位。当水位超过警戒线的时候，需要对系统进行横向/纵向的调整。

系统容量需要预留冗余，是因为我们要保证在部署、网段故障、机房故障时，线上服务依旧是可用的。

综上，可以得出公式：系统容量 = 单实例极限容量 * 当前实例数 * 冗余度

2 流行的方案

1. jmeter
2. 扩大单个实例的流量
3. tcpcopy

2.1 jmeter

构造测试数据，进行接口级测试，观察服务表现

优点：灵活，可对特定接口进行针对性压测
缺点：很难模拟真实的流量场景（线上的接口太多，各接口的流量比例不同）

2.2 扩大流量

通过调整权重或缩减集群规模，将线上流量压到单个服务实例上，观察服务表现

优点：真实
缺点：在压力过大时可能造成服务质量下降，影响用户使用。

2.3 tcpcopy（推荐）

拷贝线上流量，对旁路环境进行压测

优点：真实，不会影响用户
缺点：需要准备完整的旁路环境

3 性能指标

不管采用什么样的压测方案，我们需要知道压到什么程度就是“极限”了。
对于在线类服务，最关注的是服务的响应时间，可以是所有接口的平均响应时间，也可以是某些接口的平均响应时间。

由于压测环境不是线上真实的服务器，需要单独搭建一整套供压测的环境。
建议按线上的部署比例进行等比例缩放压测环境的实例数。