大促之前全链路压测原理

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

这个是将生产环境的配置完全克隆一份出来，进行压测，这种方案可以得到有效的数据信息，但是成本非常高

• 随着业务量的不断增长，考虑到线下测试结果的准确性，开始尝试生产压测，这种压测手段，我们称之为引流压测，事实上没有真正的模拟放大压力进行测试，而是一种通过缩小在线服务集群数的方式来放大单机处理量。比如一个业务系统的集群有100个节点，将其中90个节点模拟下线或转发流量到剩余的10个节点上实施压测。
• 缺点：引流压测的弊端在于，DB承受压力不变，上下游系统的压力不变。压测结果仅能代表单个应用的性能，但往往无法识别链路和架构级的隐患，而且在引流过程中倘若出现异常或突如其来的业务高峰，很容易造成生产故障。

随着微服务架构的流行，服务按照不同的维度进行拆分，一次请求往往需要涉及到多个服务

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

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

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

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

• 为什么需要容量规划

  什么时候增减机器、保障系统稳定性、节约成本

• 容量规划四步走
  1. 业务流量预估阶段：通过历史数据分析未来某一个时间点业务的访问量会有多大
  2. 系统容量评估阶段：初步计算每一个系统需要分配多少机器
  3. 容量的精调阶段：通过全链路压测来模拟大促时刻的用户行为，在验证站点能力的同时对整个站点的容量水位进行精细调整
  4. 流量控制阶段：对系统配置限流阈值等系统保护措施，防止实际的业务流量超过预估业务流量的情况下，系统无法提供正常服务流量控制阶段：对系统配置限流阈值等系统保护措施，防止实际的业务流量超过预估业务流量的情况下，系统无法提供正常服务

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

• 保证系统稳定性：可能提前预估系统存在的各种问题，提前模拟高并发场景，有备无患。
• 请求链路追踪，故障快速定位：可以通过调用链结合业务日志快速定位错误信息。
• 精准的容量评估：能够定位到最需要扩容的服务，帮助公司用最低的成本满足业务的性能要求
• 真实的性能验证：能够在生成环境以最真实的环境来验证系统的真实性能。
• 数据分析，优化链路：可以得到用户的行为路径，汇总分析应用在很多业务场景。

• 首先应该将核心业务和非核心业务进行拆分，确认流量高峰针对的是哪些业务场景和模块，针对性的进行扩容准备。
• 梳理出对外的接口：使用MOCK（模拟）方式做挡板。
• 千万不要污染正常数据：认真梳理数据处理的每一个环节，确保 mock 数据的处理结果不会写入到正常库里面

• 数据的真实性和可用性：可以从生产环境完全移植一份当量的数据包，作为压测的基础数据，然后基于基础数据，通过分析历史数据增长趋势，预估当前可能的数据量
• 数据隔离：千万千万不要污染正常数据：认真梳理数据处理的每一个环节，可以考虑通过压测数据隔离处理，落入影子库，mock 对象等手段，来防止数据污染

使用分布式压测的手段来进行用户请求模拟，目前有很多的开源工具可以提供分布式压测的方式，比如JMeter、nGrinder、Locust等。

整体架构如下主要是对压测客户端的压测数据染色，全链路中间件识别出染色数据，并将正常数据和压测数据区分开，进行数据隔离，这里主要涉及到mysql数据库，RabbitMQ，Redis，还需要处理因为hystrix线程池不能通过ThreadLocal传递染色表示的问题。

架构图：

1. 涉及的系统太多，牵扯的开发人员太多，不容易调解
2. 模拟的测试数据和访问流量不真实
3. 压测产生数据未隔离，影响生产环境

1. 探针的性能消耗

   APM组件服务的影响应该做到足够小
   服务调用埋点本身会带来性能损耗，这就需要调用跟踪的低损耗，实际中还会通过配置采样率的方式，选择一部分请求去分析请求路径。在一些高度优化过的服务，即使一点点损耗也会很容易察觉到，而且有可能迫使在线服务的部署团队不得不将跟踪系统关停。

2. 代码的侵入性

   即也作为业务组件，应当尽可能少入侵或者无入侵其他业务系统，对于使用方透明，减少开发人员的负担。
   对于应用的程序员来说，是不需要知道有跟踪系统这回事的，如果一个跟踪系统想生效，就必须需要依赖应用的开发者主动配合，那么这个跟踪系统也太脆弱了，往往由于跟踪系统在应用中植入代码的bug或疏忽导致应用出问题，这样才是无法满足对跟踪系统“无所不在的部署”这个需求。

3. 可扩展性

   一个优秀的调用跟踪系统必须支持分布式部署，具备良好的可扩展性，能够支持的组件越多当然越好，或者提供便捷的插件开发API，对于一些没有监控到的组件，应用开发者也可以自行扩展。

4. 数据的分析

   数据的分析要快 ，分析的维度尽可能多，跟踪系统能提供足够快的信息反馈，就可以对生产环境下的异常状况做出快速反应。分析的全面，能够避免二次开发。

做到微服务和中间件的染色标志的穿透

通过压测平台对输出的压力请求打上标识，在订单系统中提取压测标识，确保完整的程序上下文都持有该标识，并且能够穿透微服务以及各种中间件，比如 MQ，hystrix，Fegin等。

需要能够实时监控服务的运行状况以及分析服务的调用链，我们采用skywalking进行服务监控和压测分析