全链路压测专题---1、全链路压测的思想和方案-灵析社区

全链路压测是高并发系统上线前的基础步骤，下面我们来学习下全链路压测的思想和方案

全量路压测的意义

上图是 2012 年淘宝核心业务应用关系的拓扑图，还不包含了其他的非核心业务应用，所谓的核心业务就是和交易相关的，和钱相关的业务。这张图大家可能看不清楚，看不清楚才是正常的，因为当时的阿里应用数量之多、应用间关系之混乱靠人工确实已经无法理清楚了。

在真实的业务场景种，每个系统的压力都比较大，而系统之间是有相互依赖关系的，单机压测没有考虑到依赖环节压力都比较大的情况，会引入一个不确定的误差。这就好比，我们要生产一个仪表，每一个零件都经过了严密的测试，最终把零件组装成一个仪表，仪表的工作状态会是什么样的并不清楚。

链路压测方案刨析

线下压测

顾名思义就是在测试环境进行压测，且是针对一些重点项目这种测试手段，因为测试环境硬件资源以及压测数据与线上差别太大并且服务间依赖关系错综复杂，测试环境很难模拟且不够稳定，压测出来的数据指标参考价值不大，难以用测试环境得出的结果推导生产真实容量。

预生产环境压测

这个一般是将生成环境的硬件以及软件同步复制到与生产环境一份，然后对服务内部的外部调用接口进行拦截，然后进行压测这样可以评估出来生产环境的真实容量以及达到压测的目的，但是成本非常高，需要将生产环境的硬件完全的复制一份，部署的时候需要同步的在预生产环境进行部署，以及压测代码的更改。

流量转发压测

随着业务量的不断增长，考虑到线下测试结果的准确性，开始尝试生产压测，这种压测手段，我们称之为流量转发压测。事实上没有真正的模拟放大压力进行测试，而是一种通过缩小在线服务集群数的方式来放大单机处理量。比如一个业务系统的集群有100个节点，将其中90个节点模拟下线或转发流量到剩余的10个节点上实施压测。

流量转发压测的弊端在于，DB承受压力不变，上下游系统的压力不变。压测结果仅能代表单个应用的性能，但往往无法识别链路和架构级的隐患，而且在引流过程中倘若出现异常或突如其来的业务高峰，很容易造成生产故障。

全链路压测

随着微服务架构的流行，服务按照不同的维度进行拆分，一次请求往往需要涉及到多个服务。互联网应用构建在不同的软件模块集上，这些软件模块，有可能是由不同的团队开发、可能使用不同的编程语言来实现、有可能布在了几千台服务器，横跨多个不同的数据中心。因此，就需要一些可以帮助理解系统行为、用于分析性能问题的工具，以便发生故障的时候，能够快速定位和解决问题，但是他的缺点也很明显就是需要的技术难度很高，需要克服流量染色，数据隔离，日志隔离，风险熔断等技术难题，因位在生产环境压测，所以控制不好风险也是非常高的。

所以，在复杂的微服务架构系统中，几乎每一个前端请求都会形成一个复杂的分布式服务调用链路。一个请求完整调用链可能如下图所示：

四种压测方案对比

全链路压测概述

什么是全链路压测

基于实际的生产业务场景、系统环境（生产环境），模拟海量的用户请求和数据对整个业务链（通常是核心业务链）进行压力测试，并持续调优的过程。

解决什么问题

解决在业务场景越发复杂化、海量数据冲击下系统整个业务链的可用性、服务能力的瓶颈，以及容量规划等问题。

精确的容量规划

为什么需要容量规划

容量规划的目的在于让每一个业务系统能够清晰地知道：什么时候该加机器、什么时候应该减机器？双11等大促场景需要准备多少机器，既能保障系统稳定性、又能节约成本。

容量规划步骤

1、业务流量预估阶段：通过历史数据分析未来某一个时间点业务的访问量会有多大；

2、系统容量评估阶段：初步计算每一个系统需要分配多少机器；

3、容量的精调阶段：通过全链路压测来模拟大促时刻的用户行为，在验证站点能力的同时对整个站点的容量水位进行精细调整；

4、流量控制阶段：对系统配置限流阈值等系统保护措施，防止实际的业务流量超过预估业务流量的情况下，系统无法提供正常服务流量控制阶段：对系统配置限流阈值等系统保护措施，防止实际的业务流量超过预估业务流量的情况下，系统无法提供正常服务。

进行全链路的性能监控

全链路性能监控从整体维度到局部维度展示各项指标，将跨应用的所有调用链性能信息集中展现，可方便度量整体和局部性能，并且方便找到故障产生的源头，生产上可极大缩短故障排除时间。

保证系统稳定性：可能提前预估系统存在的各种问题，提前模拟高并发场景，有备无患。

请求链路追踪，故障快速定位：可以通过调用链结合业务日志快速定位错误信息。

精准的容量评估：能够定位到最需要扩容的服务，帮助公司用最低的成本满足业务的性能要求真实的性能验证：

能够在生成环境以最真实的环境来验证系统的真实性能。

数据分析，优化链路：可以得到用户的行为路径，汇总分析应用在很多业务场景。