最近，为应对日益增长的业务要求，一直忙于进行系统优化。前几天，系统终于上线，正式开始运行了，我这才有时间来总结一下。

背景

我负责的这个系统是公司的收银系统，公司所有需要进行支付的业务都会接入这个系统。由于历史原因，之前的收银系统一直和其他的业务部署在同一台机器上，这就导致业务系统和收银系统经常出现相互影响的情况。比如之前有一次，一个业务做活动，订单量暴增，大量支付请求发送到收银系统，一时间收银系统所在机器CPU使用率上升到90%多，结果导致同台机器上的其他业务也无法正常使用了，最后不得以只能通过扩容才暂时解决了这个问题。

优化

1、迁移收银台，独立部署

虽然，上面我们通过扩容暂时解决了问题，但治标不治本，而且还浪费资源，因为订单暴增，CPU使用率突然上升的根本是因为收银系统要处理的请求突然增加。因此，要彻底解决这个问题，我们需要迁移收银系统，要将其与业务系统分开，独立部署。

2、数据库使用多实例

我们将收银系统与业务系统分开独立部署后，收银系统和业务系统不再相互干扰了，但是我们运行了一段时间后，又发现新的收银系统面临了一个新的问题——系统QPS太低。通过压测发现，在数据库单实例的情况下，即使增加WEB机器，最大的QPS也只能达到3443/s，能处理的订单数最多也只有860单/s，这对于业务2000单/s的要求显然是无法满足的。

为解决这个问题，我们选择使用MySQL多实例，我们想通过提升MySQL的QPS，来提升收银系统处理订单的能力。我们从1个实例开始，先后测试了在相同数量的WEB机器下2个、3个、4个MySQL实例的性能情况。通过对比发现，随着MySQL实例的增加收银系统处理订单的能力在不断增加，当MySQL实例数量为4的时候，订单处理量超过了2000/s。

从上面的这一连续的测试结果看，通过增加MySQL数据库实例数量来提升收银系统的QPS，进而增加收银系统的订单处理能力是可行的。

3、WEB机器自动扩容

上面只是我们的测试方案，但实际上不可能无限增加太多MySQL数据库实例。综合考虑，我们把MySQL数据库实例数固定为4，然后再通过动态增加WEB机，来达到相同效果。我们使用的是阿里云的扩容功能，扩容规则如下：

当CPU连续超过70%，每6分钟（2m+2m+2m=6m）左右会逐步触发扩容加机器，当加到最大实例数（10台）就不会再扩容了。当CPU连续低于50%，每6分钟（2m+2m+2m=6m）左右会逐步触发扩容减机器，当减到最小实例数（6台）就不会再回收了。

通过上面一系列操作，最后收银系统终于完成了将QPS从300提升到6000的目标。