怎么有效做水平扩容？
系统往往存在不可确定性，因为你无法从当前稳定的状态来判断或者认定系统未来也是稳定的。世界是复杂的，系统具有不可稳定性的状态。这样的案例比比皆是，如某云计算服务厂商大规模瘫痪等等案例。对质量交付团队而言，最大的挑战应该是如何可以让系统持续地具有可稳定的状态。虽然系统具有不可预知性和随机性，现实的情况往往是底层服务出现不稳定性导致上层应用不可以正常地使用，此时往往或者是大多数时候认为是测试没有测试到位导致产生的问题。如假设底层支付的服务出现资源瓶颈，最终导致正常的支付流程出现问题，某些管理者会很偏见的认为质量交付团队没有把某些支付测试场景验证到位而导致的问题。
质量交付团队首先需要思考的是系统的稳定性验证是否是属于质量交付团队的工作范畴呢？答案是肯定的，对质量交付团队而言，系统的功能性、可用性、稳定性、安全性、易用性等都是属于质量交付团队的工作内容。质量交付团队需要使用混沌工程等技术来验证系统的稳定性，以及在系统出现异常的情况下具备应急方案的工作流程与技术解决方案。稳定性体系涉及技术栈知识体系与验证方案居多，本文章主要详细地阐述下水平扩容与水平缩容的验证策略与思考点。
对底层服务而言如果给予太多的计算资源，这就涉及资源的浪费，如果给予的资源太少这又导致系统随时可能处于瓶颈当中从而影响客户的使用。所以很多时候对系统的计算资源会给到一个能够满足大多数客户使用的计算资源，这个数据的得来从两个方面而来，一个是通过容量规划的验证方案得出的数据，第二是在主观经验上得来的，而且很多时候后者相对而言是比较多的，根据客户运行的计算资源以及历史出故障等经验教训上给服务给出合理的计算资源，这样的计算资源数据可以说能够满足95%客户使用的应用场景，毕竟这些数据都是经过了时间的证明。但是不能肯定的说满足客户所有的应用场景，那么这些无法满足的部分，就需要系统具备可弹性的能力。简单的说就是让系统能够在出现资源瓶颈的情况下，能够具备水平扩容的能力，而且这个过程中对客户而言是无感知并且能够平滑的实现资源的水平扩容。
如针对一个预算的服务它的副本数是四，那么需要让预算服务具备可伸缩的弹性，能够满足在计算资源出现瓶颈的情况下实现水平扩容的能力，同时又满足在计算资源利用率低的时候又可以进行水平缩容从而达到计算资源的有效利用。
在怎么有效做性能测试中详细地阐述了性能测试的模型与性能测试过程中需要关注的不同中间件的指标，这里就不再进行详细地阐述了。性能测试技术方案需要考虑的点很多，优先级高的还是业务场景与性能测试的目标。针对水平扩容与水平缩容而言，它的思想也是一致的，需要确定使用哪些场景来进行验证水平扩容与水平缩容，以及它的目标是什么？在这里目标其实可以总结为“让系统具备可伸缩的弹性，系统在水平扩容与水平缩容的过程中业务能够正常的使用”，那么这点就是它的目标。简单的总结就是系统伸缩的时候业务完全可以正常的使用并且是无感知，对用户不会造成任何的影响。它的测试策略可以从如下几个维度来进行思考，具体汇总点如下。
- 验证单副本情况下系统的承载能力(包含了DB资源、响应时间、吞吐率、服务资源使用率、MQ未消费数据等数据)
- 验证二个副本情况下是否是单副本系统承载能力的二倍(验证的策略其实很简单，比如单副本情况下每秒并发量是100，那么二个副本使用每秒并发200，最后针对各个资源数据进行环比对比看是否是二倍，如单副本情况下吞吐率是20/s，二个副本情况下是否是40/s，当然还有其他维度的数据），这里需要特别强调的是之所以验证这点是需要知道服务增加一个副本数的情况下，它的计算资源是呈倍数增加还是具体数值是多少，需要对这个数据有清晰的认识，因为计算资源最后都是算力之间的计算
- 在常规副本情况下(如预算服务平常副本数是4，可以按这个副本数来)进行水平扩容验证是否可以达到无感知平滑地实现计算资源的扩容(如从副本数4增加到副本数是6的时候，这个过程中期望的目标是执行的任务可以正常地执行，而且系统的计算资源进行了增加。针对计算资源计算模式如单副本是每秒并发100，副本数为4的时候每秒并发是400，那么需要验证副本数水平扩容到6的时候，可以使用每秒并发600来进行验证)。
- 在常规副本情况下验证水平缩容情况是否可以成功(判断的标准依然是业务不受任何的影响)
需要特别强调的是水平扩容与水平缩容的判断标准会有不同的指标和依据，但是最核心的是业务可以正常的使用作为最核心的依据来进行判断，理由是验证资源的伸缩目标是保障业务可以正常的使用。当然也需要在水平扩容与水平缩容的过程中关注MQ的未消费数据积压、队列堵塞数、MQ状态等指标。期望的目标就是在资源进行伸缩的过程中业务、涉及到的中间件都是正常和用户无感知。
针对水平扩容的验证策略，需要在结果中反馈出单副本的计算能力、多副本情况下计算能力是否是单副本计算能力的N倍(如三副本计算能力是否是单副本计算能力三倍)、水平扩容与水平缩容是否可以平滑地进行资源的伸缩。往往在性能测试结束后，大家其实并不关心性能测试的过程，只会关心最初性能测试方案中关于性能测试的目标是否达到目标，以及达不到目标的理由是什么？