众所周知，应用的服务状态除了会受到自身稳定性的影响，还会受到流量等环境因素的影响，并且影响面会继续传递到上下游，哪怕一个环节出现一点误差，误差在上下游经过几层累积后会造成什么影响谁都无法确定。
保障服务的可用性和稳定性是技术团队面临的首要任务，也是技术难题之一。在实际生产环境中，用户的访问行为一旦发生，从CDN到接入层、前端应用、后端服务、缓存、存储、中间件整个链路都面临着不确定的流量，无论是公有云、专有云、混合云还是自建IDC，全局的瓶颈识别、业务整体容量摸底和规划都需要高仿真的全链路压测来检验。这里的不确定的流量指的是某个大促活动、常规高并发时间段以及其他规划外的场景引起的不规则、大小未知的流量。
因此，在生产环境里建立起一套验证机制，来验证各个生产环节都是能经受住各类流量的访问，成为保障服务的可用性和稳定性的重中之重。最佳的验证方法就是让事件提前发生，即让真实的流量来访问生产环境，实现全方位的真实业务场景模拟，确保各个环节的性能、容量和稳定性均做到万无一失，这就是全链路压测的诞生背景，也是将性能测试进行全方位的升级，使其具备“预见能力”。
可见，全链路压测做得好，遇到真实环境的流量，系统仅仅只是再经历一次已经被反复验证过的场景，再考一遍做“做过的考题”，不出问题在意料之中将成为可能。
压测的核心要素
实施完整的业务压测，路径很重要。要达成精准衡量业务承接能力的目标，业务压测就需要做到一样的线上环境、一样的用户规模、一样的业务场景、一样的业务量级和一样的流量来源，让系统提前进行“模拟考”，从而达到精准衡量业务模型实际处理能力的目标，其核心要素是：压测环境、压测基础数据、压测流量（模型、数据）、流量发起、掌控和问题定位。
压测环境和压测基础数据
生产环境上基础数据基本分为两种方式：
一种是数据库层面不需要做改造，直接基于基础表里的测试账户（相关的数据完整性也要具备）进行，压测之后将相关的测试产生的流水数据清除（清除的方式可以固化SQL脚本或者落在系统上）；
另一种就是压测流量单独打标（如单独定义的Header），然后业务处理过程中识别这个标并传递下去，包括异步消息和中间件，最终落到数据库的影子表或者影子库中。这种方式详见阿里的全链路压测实践，我们也是选用了这种方式。此外，生产环境的压测尽量在业务低峰期进行从而避免影响生产的业务。
相关阅读：
实施全链路压测的关键点有哪些？全链路压测流程详解
什么是全链路压测?全链路压测怎么做？
sales@spasvo.com
