全链路压测
生产环境的全链路压测应该怎么做？答案都在这里了 - 知乎 (zhihu.com)
二十问全链路压测干货汇总(上)全网最全 - 知乎 (zhihu.com)
为什么需要全链路压测
在线式，压测并不是针对业务的全链路来展开的，而是采用了逐个击破的原则，即生产环境中的单机或者单系统进行独立压测。单系统独立压测模拟海量请求主要有俩种方式。
- 根据设计的压力来直接模拟大量的并发调用
- 先获取线上真实流量请求，然后经过数据清洗再回访模拟大量并发调用
单系统独立压测的弊端在某大型活动例如秒杀放开的瞬间，从CDN、网关接入、前端、缓存、中间件、后端服务、数据库整个交易链路都会面临巨大的访问压力，这个时候系统服务除了受自身的影响外，还依赖于其他关联系统的影响，并且该影响会一直蔓延，只要有一个节点出现故障，那么故障在上下游系统经过层层累加后造成的影响将难以追溯。
现阶段的全链路压测在真实的生产环境上以真实的量级去模拟真实的业务操作，并以此来衡量系统的实际承载能力，或者找出系统的瓶颈点。这样的好处是在大促前夕就能在线上环境进行真实模拟，以此改进修复自身系统的不足，从而保障系统在流量的冲击下保持稳定。随着近几年的电商不断发展，一些如“双11”“双12”“618”等等大促日如雨后春笋般冒了出来，于是基于真实的生产环境来模拟海量的并发用户请求和数据，就显得十分必要了。
全链路压测能解决什么问题
随着移动互联网、云计算、物联网等技术的不断发展，应用架构也变得更加离散和复杂，一个应用的高稳定性不仅需要自身系统的稳健，同时也更加依赖网络、第三方服务的质量，而这些外部的"不确定"因素让稳定性变得更加"不可控"。在这种"不可控"的复杂环境中，如何保障高并发条件下的应用性能稳定性，需要解决以下问题：
1、高流量下的系统稳定性不足，如易崩溃、卡顿等问题；
2、新代码上线的性能基线比对，如RT、CPU load、数据库性能比对等；
3、不知道该如何合理配置机器配置和数量，多配或少配等问题；
4、系统日常运行不稳定，时不时宕机、服务不可用等问题；
5、代码变化频繁，几经易手后，架构混乱、难梳理等问题；
6、对于运行的情况不清楚，不知道当前性能健康程度如何的问题；
当然全链路压测的过程中显然不止这些问题，以上列举的六点可能是大多数客户关心的，仅作示例参考
以物流行业的订单链路来说，通常会包含渠道下单、调度、开单、建包&解包、分拣、装车、补码、派送等环节。而全链路压测的主要作用就是通过模拟超大流量冲击链路上的这些节点，观察链路在流量峰值时的表现和故障情况，来发现链路流程上的瓶颈或性能问题。
什么样的公司需要全链路压测？
既然全链路压测功能这么强大，那如何确定自己的公司是否需要做全链路压测呢？如果你的企业遇到过以下问题之一，就可以考虑引入全链路压测：
(1) 压力测试一直在做，但是每到大促活动，各种问题依然频繁发生；
(2) 需求正常迭代完成，并测试通过，上线后又出现各种各样的系统故障 ；
(3) 无法正确评估需要的机器资源，只能“重要的多给点，不重要的少给点”的经验之谈；
(4) 性能团队尽职尽责，但是性能问题依然层出不穷；
(5) 每次压测完的报告，看似内容详尽，但很多无法针对性的查出问题并给出解决方案。
也可以从场景层面来考虑是否需要做全链路压测：
1.1 新系统上线场景：准确探知系统承载能力，防止刚上线被用户流量冲垮。新系统上线一般会遇到以下两个问题：(1) 新系统能够支持多大的并发流量访问，是否需要增加机器来满足用户流量(2) 新系统性能是否满足预期，是否影响用户体验
这两个问题如果没有很好的解决会造成严重的影响，举个例子：某知名电商双十一推出一款网红产品的秒杀业务，想通过秒杀来吸引一波流量，结果双十一当天功能刚上线就系统宕机，消费者各种投诉、网上各种舆论，至此这家电商到现在在没搞过此类秒杀业务。
1.2 峰值业务稳定场景：流量激增情况下，比如像双十一这样的大促，系统如果没有做好相关的准备，很容易被用户流量冲垮，导致公司业务受损，目前业内普遍通过全链路压测提前模拟流量激增场景，来增强系统的承载能力。
1.3 系统容量规划场景：成本优化，对系统进行精细化的容量规划。无论是新系统上线还是大促场景，都会遇到容量规划的问题，目前容量规划更多是结合平常系统性能表现以及预计用户流量按照经验去规划，但这种规划一般无法做到精准容量评估，一种是评估多了，造成机器浪费，一种是评估少了造成线上故障，对业务造成影响。
1.4 系统可用性探测场景：探测系统的可用性，提升系统的整体服务能力和吞吐量。全链路压测另外一个典型用场景就是通过模拟真实的用户流量压力，去探知系统的性能瓶颈，从而提升系统的整体服务能力和吞吐量，提升用户体验。
全链路压测可以给企业带来什么价值
2.1 保障重大活动的系统稳定性避免公司业务和声誉因为技术故障受到损失，为技术团队赢得业务团队的尊重。
2.2精准的容量评估帮助公司用最低的成本满足业务的性能要求
2.3重大项目重构切换前的性能验证避免上线切换后持续的性能故障，快速渡过不稳定期。系统重构是IT部门场景的技术更新的方法，每次上线都需要经历一段阵痛期，期间性能问题、业务故障频发，用户投诉频繁。通过全链路压测可以在正式切换前完全解决性能问题；配合自动化的用例梳理和人工验证，可以极大程度降低业务故障。两者配合使用，可以快速的渡过不稳定期，提升用户体验。
2.4端到端的全链路巡检，第一时间发现故障并快速定位问题
目前常见的监控体系都是通过一些间接的指标来判断是否有故障发生（比如通过CPU利用率、内存使用率、应用的错误日志数量、业务单量和基线的对比等等方式），间接的方式会产生大量的误报，造成告警麻痹症，真的故障发生后不一定能第一时间引起重视。
通过全链路压测提供的数据隔离功能，可以在线上通过压测流量验证真实的业务接口是否能正常工作。这种方式可以直接在用户发现业务故障前，相关人员第一时间知晓。配合链路的监测分析功能，快速定位问题应用所在。
该方法在客户真实环境中比传统监控方法平均提前7分钟发现故障，告警正确率是传统告警方式的几十倍。
2.5建立公司的性能运营体系，将运动式的性能优化演化为自发的日常性能优化很多公司都有运动式或者故障驱动的性能优化经历，比如马上要双十一，总监牵头开始性能优化；有人管的时候性能表现很好，一旦没人牵头做性能优化的事情，又会有很多性能问题被暴露出来。这样的方式通过优化效率很低，投入还大。
2.6通过全链路压测的方式，配合目标制定、绩效和工单系统。自动化的全链路压测可以日常化的排查性能瓶颈，通过工单将问题直达负责人，极大的提升性能优化的效率，将性能问题控制在萌芽状态。
全链路压测如何做容量规划
容量规划的工作，一般是由企业内资深的专家承担，这是一个复杂有难度的工作，需要熟悉系统、强技术能力、了解容量规划的方法等。
但企业即使有这样的人，也无法保障生产环境机器容量规划一定合理，主要原因是现在的系统业务和技术架构的复杂度已经远远超出了大脑能够掌控的范围，无法进行有效的容量评估。既然无法进行有效的容量评估，那我们有没有什么新的工具和思路来解决这个问题呢？
数列科技的全链路压测产品解决这个问题的思路为：(1) 通过系统当前的单机容量、依赖关系数据、业务的期望容量等数据，经过容量评估模型计算初始的容量(2) 设置业务期望容量，通过全链路压测的方式验证容量是否合理(3) 调整不合理的链路节点容量(4) 重复2、3步骤，直至用最小成本可以达成业务期望容量
除此以外，基于产品化的全链路压测，可以进一步做到高频的日常容量评估和管理：(1) 对资源不足的应用尽早增加资源避免用户体验较差的情况发生(2) 对资源过剩的应用尽早削减机器，降低硬件和维护成本
另外目前市面上还有一些基于AI算法模型搭建的容量评估方案，比如数列科技的解决方案核心思路是将日常IT系统中各种性能数据进行收集归类，聚合分析然后建立对应的容量规划模型，之后就可以根据模型去做容量规划，然后使用全链路压测去验证，这样效果更佳。
如何确定业务核心链路边界
如何确定业务核心链路一直是全链路压测前期准备工作的核心，这里需要注意的是：核心链路是指在精力有限的情况下，必须要保障好的链路，意味着需要投入更多的硬件资源、更多的工程师、出现问题是需要优先处理的。
核心链路不仅要考虑到技术层面，还需要使用自动的架构梳理能力来确定，因为人为梳理费时费力还容易出错。将详细的依赖数据清洗合并完成后，技术和对应的业务部门共同标记核心的业务功能点，再根据核心功能点和系统的依赖数据来确定最终的核心链路。
一般有符合以下三种情况的，可以考虑确定为核心链路：(1) 链路出现问题会对企业业务造成重大影响的链路，比如对业务造成损害、品牌损害等(2) 链路出现问题会对用户（如消费者）造成重大影响的链路，比如电商购物APP(3) 跟公司阶段考核（如KPI）挂钩的业务链路，比如订单团队肯定要保障订单链路的稳定。
另外核心链路其实一直都在变化的，主要体现在：(1) 系统功能一直在增加、修改，对应的系统依赖也必然变化，所以核心链路的边界也是变化的
(2) 核心链路是跟随业务场景变化的，比如在双十一前几年购物地址列表不是核心链路，因为大家双十一的购物习惯是给自己家买；这两年大家喜欢在双十一期间给父母和朋友买商品，于是切换购物地址就需要加入核心业务功能中。
如何构建全链路压测模型？
全链路压测：影子库与影子表之争-阿里云开发者社区 (aliyun.com)
由于使用了影子、库表的方式，直接使用市场价压测也并不代表能获得与真实业务完全一致的压测环境，里面还涉及到堆压测数据模型的建立，要保证压测流量和正式流量保持一致，影子库表与生产环境保持一致，这里的一致包含几个方面
数据量一致通常是数据库，搜索索引等数据量的变化会导致响应时间变化的中间件，如果使用影子库来替代正式库，那么需要全量拷贝一份正式库的全量数据来保证压测结果，一些无法直接使用正式库数据的情况。
诸如新业务上线/正式库数据增减变化大/业务增长迅猛需要增加数据量等情况，则需要根据目标数据量以及业务特征构造压测数据来准备数据脚本。一些只读的链路涉及的库/表，可以根据压测时间/压测目的/压测量等因素评估是否可以直接使用正式库作为压测库。
数据分布一致数据在使用的时候会有频繁访问/操作的热点数据，几乎不会用到的历史归档数据。两者在mq/缓存/数据库的分布比例会影响接口的读写操作性能，需要根据生产的实际情况构建压测数据模型。
数据操作一致对于缓存，定时处理的一些数据，构造数据的时候要注意数据失效/刷新/定时处理的批次和每批数据处理量的大小。
影子库
针对于影子库方案，是同一个实例上建立对应的影子库。用户服务挂载的全链路压测探针获取到流量标之后进行相应的旁路处理，如果是影子流量，那么影子连接池中获取影子链接供业务侧使用，从而将压测流量产生的数据旁路到对应的影子库中，以此达到数据和生产库隔离的效果，从而避免了压测流量产生的数据对生产库造成污染。
影子表
如图 2 所示，类似影子库方案，针对影子表方案，是在同一个实例上的同一个数据库上建立对应的影子表。用户服务挂载的全链路压测探针获取到流量标之后进行相应的旁路处理，如果是影子流量，那么，探针会针对本次的 DB 调用进行 SQL 解析和替换，从而将压测流量产生的数据旁路到对应的影子表中。
方案对比
性能
机器规格：4c8g
并发规格：需同时模拟正常和压测流量两种类型的流量，这里以 2:8 的比例进行划分，以便于模拟业务流量低峰期进行生产环境全链路压测。
- 正常流量：200 并发
- 压测流量：800 并发
这里主要从服务所在的主机和所用的数据库实例两方面的监控去分析。其中，应用监控主要以 CPU、内存和平均 RT 三个指标分析。数据库实例监控从连接数、QPS 两个指标的维度进行分析。
从以上两种方案不同维度的指标对比可以看出，影子表方案对 CPU 的消耗略高，这和该方案的实现方式有关。
稳定性
谈到稳定性，可以从数据源实例的连接数规格、容量规格、IOPS、网络流量等方面进行分析。
针对影子库方案。由于是在同一个实例上建立不同的数据库，所以如果不考虑数据库实例能够达到最大连接数上限，理论上影子连接和正常连接时相互独立的，执行时互不影响。
针对影子表方案，由于是在同一个实例上的同一个数据库上建立了不同的数据表，那么这里就要考虑业务侧的连接池配置了，因为影子流量涉及到的 DB 操作和正常流量涉及到的 DB 操作，所用的数据库连接，均来源于同一个连接池，所以如果压测量级较大的时候，是比较容易出现连接池连接瓶颈的。
成本
根据表格中的内容，这里主要以冗余成本和数据迁移成本进行说明，具体如下：
- 冗余成本
针对影子库方案，为了保证全链路压测评估结果的精准度，我们需要在同一个实例上做全量的库迁移操作，包括表结构和表数据，这会带来一个比较明显的问题，成本比较高，所有的基础只读表（此类型的表不会有写操作）均要冗余一份，无法达到复用的目的，所以对于中大型企业来说，是难以接受的。
针对影子表方案，是在同一个实例上的同一个数据库上建立影子表。那么就可以复用生产库中的基础只读表，只需对写表进行建立影子表即可。影子表方案在一定程度上降低了数据冗余所带来的成本消耗。
- 数据迁移成本
从压测的主流程来说，分为压测前、压测中、压测后。其中，数据准备是处于压测前这一阶段的，压测成功与否，和数据准备这一环节密切相关。数据迁移的过程需要将某张数据表所关联的其他表字段同时做迁移，这一过程是比较复杂和耗费精力的。所以，具体选择哪种方案，需要结合业务数据的复杂程度来评估。
总结
综上，具体选择以上两种方案中的哪一种，其实仅靠一个指标判断是不够的，要结合以上多个指标以及具体的业务场景来进行综合评估的。下面针对两种典型的场景来说明应该如何选择适合自己方案，以下意见仅供参考。
场景 1：在涉及到的读表比例高于写表、并且整库迁移成本较高的情况下，推荐选择影子表方案，在一定程度上可以减少复杂的数据迁移带来的成本。
场景 2：在涉及到的写表比例高于读表，同时生产库实例容量较为充足的情况下，推荐选择影子库方案，在一定程度上降低了梳理、配置的成本。
如何构造压测流量
全链路压测需要最大程度的模拟正式环境下的流量，我们需要考虑几个问题，比如请求数据如何构造，以及请求数据的多样化等。
举个例子，我们压测【下单】链路，需要尽可能模拟真实用户的下单情况，比如流量要与真实用户分布类似来自全国各地，以及购买各式各样的商品，还有访问下单的不同渠道，有时候甚至需要考虑用户的终端设备等。目前数列科技ForceCop在构造压测流量主要有两种方式：
第一种人工构造压测并发量不大的时候，比如并发只有几百，这种情况建议通过编写sql从数据库中导出一批线上数据，然后对这批数据进行清洗，去除敏感信息，比如客户地址、客户账号等信息，然后根据数据去准备压测脚本。
当压测并发量很大，比如并发上万，此时建议通过将数据同步到大数据平台，通过MapReduce任务的方式去清洗、导出数据。
可能有人会问为什么选择从线上环境导出压测数据呢？因为真实业务数据代表的是真实发生的业务，数据之间的关系也已经生成，通过这种方式构造的压测数据能够最真实地还原业务场景并且构造数据的效率也能够大大提升。
第二种录制回放录制回放就是收集某个时间段的正常业务数据，然后通过清洗敏感信息，最后加上压测标记去运行，达到最高程度的模拟正式业务场景，确保数据的真实性、多元化，以及场景覆盖的完整性。
压测如何构建监控体系
全链路压测监控体系是由基础监控，应用监控、业务监控三部分构成。7.1 基础监控是指压测产品或者压测应用系统的集群基础性能监控，比如CPU性能、磁盘性能、网络性能等。
7.2 应用监控是指从应用层对应用的性能、进行实时监控、分析，比如端到端链路调用节点性能情况。
7.3 业务监控是指在站在业务角度的监控，它是由一些列业务指标构成，这些业务指标有特定的业务含义，比如5分钟内交易订单成功率持续为0。整个全链路压测过程中，开发人员在压力发起之后紧盯基础监控、应用监控、业务监控大盘，任何监控如有异常，第一时间执行对应的紧急预案，确保压测正常运行。
如何保证数据的隔离性
先来说说为什么需要做数据隔离，如果不做隔离会有什么风险？答案是数据不隔离会导致数据统计出错，还有对线上业务造成严重的影响。那也有小伙伴会说，数据物理不隔离，业务系统兼容下不就可以了吗？
但其实业务系统兼容压测数据也是一种数据隔离，我们称之为“压测数据逻辑隔离”，IT系统要实现这种逻辑隔离，基本上每一个接口都要针对压测数据进行工作量巨大的兼容改造，并且后续发布新接口或者修改老接口也需要持续兼容改造。
否则一旦某环节出现问题就会对系统造成重大隐患。因此我们在生产环境做压测，一定要做数据隔离，下面是我们数列科技的压测产品大体结构如下图：
ForceCop的视线思路主要为以下几个步骤
- 流量染色
构造压测流量时，将压测标记加入到压测流量中进行染色，比如页面发起的http请求，我们会在http请求的消息头里加入压测标记。
- 压测标记传递
当压测流量流经业务链路时，会经过很多事先被值如果压测探针的应用。当压测流量经过这些应用时，会被应用里的探针识别出来，并且会携带这些压测标记传递下去。比如经过Dubbo服务时，探针会把压测标记放到Dubbo的上下文中
- 压测数据存储
压测流量最终会持久化到数据库、缓存、消息中间件等，当压测探针识别到压测流量要持久化，就会将压测流量持久化到对应的影子区域。比如数据库会持久化到影子库或者影子表中、消息会写到影子topic中。
如何调用部分链路或第三方外部链路的服务？
在全链路压测过程中会遇到很多场景，其中部分链路与第三方外部链路的场景比较典型，以我们数列科技实践过的案例得出以下结论：
部分链路压测
部分链路压测是指整条链路中因为特殊原因某一个应用不能参与压测，比如遇到负责这个应用的团队忙于业务需求，暂时无法参与压测，遇到这类型情况怎么去落地压测呢，我们一般会采用挡板+后期压测的套餐来解决。
挡板其实就是常说的mock功能，如下图所示，【应用2】因为特殊原因不能参与压测，但【应用1】和【应用3】不能因为【应用2】不参与就不能压测，在调用【应用2】处增加挡板就可以顺利保证其他应用正常压测，未来【应用2】可以做压测时，去掉挡板，统一进行压测就ok了。
外部链路压测
外调链路压测是指压测链路中涉及到调用其他供应商提供的系统，比如第三方支付或者一些短信服务之类的，如果第三方愿意配合，我们就按照正常压测去进行就ok，但一般情况下第三方不太愿意配合，遇到这类型场景，我们怎么解决呢？
这类型场景我们会采用挡板的套餐来解决，将调用第三方的接口mock掉，模拟第三方的耗时以及返回结果来确保压测能够正常进行，比如像支付宝这样的支付服务，支付宝肯定不会配合我们去做压测，我们只能通过挡板去模拟压测。
