开篇词 | 打破认知神话，做接地气的全链路压测
高楼
讲述：高楼大小：14.50M时长：15:49
你好，我是高楼。
可能很多人已经认识我了，因为这已经是我在极客时间开设的第三门课程了。这次，我想和你聊聊全链路压测。
回顾从业十几年的经历，我一直在做性能测试、性能分析、性能优化的工作。早年间我在各大测试论坛分享自己的工作经验，并形成了关于性能测试完整的知识链。后来，我开始自己带团队做项目，完整做过 40 多个项目，团队也从最初的四五个人到 300 余人。与我合作过的人都了解，我做性能项目的宗旨就是上线不死，死了不收钱。
2019 年，我的第一个课程《性能测试实战 30 讲》上线了，2020 年，我又开了第二门课程《高楼的性能工程实战课》。在这两个课程中，我描述了我认为在测试过程中重要的部分，比如整体概念梳理、性能分析思路等。
我希望通过这两个课程，可以抛出一个价值观：让性能变得有价值。我希望更多的人知道，性能如果只是停留在“测试”的层面，根本不能发挥它本该具有的价值，“调优”也是非常重要又不可忽视的部分。
对于一个企业级性能项目来说，性能的价值是给出结论数据，判断出系统的最大容量、稳定性运行时长。但是，大部分企业的性能项目做得如同儿戏一般，只有最简单的验证，系统资源大量闲置，而调优的动作几乎没有。当然了，也有可能是因为他们并不知道怎么做。但无论如何，这样的系统匆忙上线，一定会浪费大量不必要的资源。至于一个性能人员能把性能做得多深入，就取决于个人的努力了。
我还提出过一个重要的概念，就是“RESAR 性能工程”。“RESAR 性能工程”这个名字是我自己起的，你不用去网上搜索，因为现在还搜不到。它对性能项目过程中的各个具体的动作做了更详细的描述，使之成为可以落地的具体实践。
在前两个专栏，我一直强调把性能从“测试”思维转换到“工程”思维。这个思维的转变，涵盖了性能项目的全流程，不仅有技术的细节，还有需求、模型、监控、分析的完整逻辑。只有这个逻辑完整了，性能才能做得有价值。
在我看来，全链路压测只是性能容量场景中的一个具体案例。它并没有跑出“RESAR 性能工程”的范围。RESAR 性能工程中的所有逻辑思维，都将在这个全链路压测的专栏中落地实践。
不过如果你没有看过上一个专栏也没有关系，你可以先看看我在上面给出的思维导图，了解一下它具体分为哪些板块。在项目具体落地的过程中，我也会把每个模块略作介绍，保证不让你有蒙圈的感觉。
你可能会问，既然全链路压测的逻辑已经包含在 RESAR 性能工程里了，为什么还要写一个全链路压测的专栏呢？它和之前的专栏有什么区别和联系呢？让我们先来看一下全链路压测行业的现状。
在网络上可以找得到的全链路文章中，大概可以看到阿里、有赞、饿了么、美团、滴滴、京东、字节、陌陌、达达等企业的技术文章，里面都提到了全链路压测在企业内部的落地。但他们是如何落地的，在细节上我们只能猜测一二。
全链路压测行业现状
在性能领域中，很多人看到全链路压测的目标和效果之后，都会觉得这是一套可以上天遁地的完整逻辑。事实是不是这样呢？看看网上能搜索到的信息，它们基本上有这么几个特点：
目标和方案只有摘要级的说明。
全链路压测平台的细节描述宽泛，没有完整的落地细节。
只有大厂的一些笼统资料，但并没有投入成本（人员成本、资金成本、时间成本）的数据。
无架构级全链路改造的细节。
无架构级监控平台范围的细节。
无性能分析逻辑的细节。
因此，在网上看了各种资料之后，你可能还是有很多困惑：首先，不知道自己的企业能不能支撑；其次，不知道应该如何具体实施；再者，不知道投入成本有多大。
在这些问题还没有搞清楚之前，偏偏一些企业的管理者只看效果，觉得这件事情是需要做的，于是安排了相关的任务给具体的实施层。实施层由于没有管理权限、没有成本计算能力、没有技术细节的实现能力，于是越做越觉得坑太大，填不住。只能想各种招儿来应对领导这一看似合理的安排。
举个例子，全链路压测的出发点是对线上的真实系统做改造后直接在线上压测，而一些企业根本不具备这样的条件，所以为了跟上潮流，他们只会做一些小的动作，在线上减少覆盖范围并分段进行压测。但是这个改变，其实完全失去了全链路压测的价值。
实际上，全链路的落地是要经过综合考虑后，公司上下共同努力的结果。从整个全链路项目来看，企业里从老板到最底层的工程师，都会需要参与进来。也就是说，全链路涉及老板、产品经理、架构师、开发工程师、测试工程师、运维工程师等各个角色。
不过，不同岗位的关注点是不同的。老板关注的是，全链路压测带来的业务容量提升和企业利润增长；产品经理要关注的是，业务容量的增长和后续功能的设计；架构师要关注的是，全局架构设计对全链路压测的宏观支撑；开发工程师要关注的是，业务细节和技术细节的改造；测试工程师要关注的是，覆盖住这些改造；运维工程师要关注的是，全链路改造和线上的压测过程对系统整体状态的影响。
如果你的公司打算实施全链路压测，而你刚好处在这些岗位或者对这些岗位有意向，那么我的这门课很可能对你有帮助。因为我对全链路压测是认真的，我要做的就是实战，就是“把全链路压测拉到地面上”，让你真正地了解它。
不过，在正式进入课程之前，我还想跟你聊聊几个你可能会关心，但是和技术无关的问题。
全链路压测最难的是什么？
全链路压测最难的，到底是什么呢？
是应用改造吗？是压力工具改造吗？是逻辑思维的转变吗？
在我看来，都不是。最难的应该是：管理协调。
由于全链路压测涉及到的团队多、系统多、链路长，这就导致了管理成本的迅速增加。
相比较而言，技术的实现就是细节的落地过程，消耗的只是人员和时间成本。
虽然我们这个技术专栏不会涉及管理协调（因为每个企业都有自己的管理逻辑，而且管理主要是和人相关，所以我无法给你一个放到不同企业都可用的管理思路），但你要记住，人员的协调非常重要，千万不可以小看它的影响。
全链路压测一定会涉及压力工具的改变吗？
这一点是不一定的。因为全链路压测的出现，是为了响应互联网企业大流量的需求。但是，不是所有的互联网企业都有那么大的容量需求，如果容量需求不大，是不需要改造压力工具的。
那有没有某种工具只是为了全链路压测而存在呢？答案是：没有！
因为压力工具是为了对服务端发送请求而存在的，所以不管你用传统压力工具，还是用现在市面上的所谓全链路压测工具，只要能够按需求对服务端发出请求，那就足够了。
有人说，我的全链路压测是可以基于多个公网上的压力服务器调用的，这一点和传统压力工具有很大的区别。我只能呵呵一笑，你觉得传统压力工具做不到吗？
全链路线下压测有没有价值？
因为全链路压测是为了满足线上环境的容量需求，所以所有的全链路相关的动作也都是基于线上环境来讨论的。但是，如果一些企业出于对制度或风险的考虑，不能或不想在线上环境做全链路压测，可不可以把全链路压测的逻辑应用于线下环境的压测呢？
答案当然是：完全可以，但是！是不是就怕看到但是？哈哈，但我还是得说：但是全链路压测如果不在线上做，那就摆脱了环境的限制，摆脱了影响生产系统的风险。
第一，“全链路”这个词强调的改造部分就不需要做了。因为改造的目的是区别压力流量和生产流量，而线下没有生产流量，所以不需要做改造。
第二，如果线下环境的业务流量需求没有线上环境要求的大，那么全链路压测强调的压测工具的分布式改造也就没必要了。
第三，如果线下环境的业务流量需求和线上环境要求的一样大，企业也愿意把线下环境搭建成和线上完全一致，那就完全可以复制全链路线上压测的逻辑。
第四，有人说，换到线下用流量复制的工具来实现线上流量的放大回放，是否也有意义呢？其实这个动作也不是非常有必要，因为如果已经在线下做了，那压力工具完全可以配置出线上的请求比例，用不用流量录制回放的压力工具无所谓，只要能按业务比例实现压力就好。
所以，你看，全链路线下压测不是没有价值，而是付出的成本似乎不会小。虽然应用的改造不用做了，但环境就是最大的问题。注意，这里说的环境可不仅是硬件环境堆在那里，架构部署和数据的部分也不简单。如果去除硬件和部署架构，那显然就和以前我们做的性能项目无差了。
这个全链路压测专栏会如何组织？
在这个全链路压测专栏中，基于“把全链路压测拉到地面上”的定位，我会这样来组织。
我把这个专栏分成了六个部分，分别是核心理论、实践需求、环境准备、场景执行、性能分析和结果报告。在这六个部分中，我会把全链路压测实际落地的过程，真实、详尽地记录下来。目的就是，希望让你看到全链路压测的实现细节，不再把全链路当成神话一样来崇拜。
在核心理论模块，我会给你概括一下全链路压测过程中需要的重要逻辑。如：改造部分的逻辑、模拟场景的逻辑等。
在实践需求模块，我会对性能项目中的几个重要环节进行详细说明。比如，压测方案设计、梳理核心链路、明确压测范围、数据构造、系统构造方案、性能监控等。
在实践环境准备模块中，我会介绍全链路压测实践环境准备工作，对全链路压测项目中，前面的环境初始化环节的实操进行说明。
在场景执行模块，我会带着你通过压测平台来实现全链路压测的场景。这里，我们会使用到各种不同的压力工具，比如炒得火热的流量回放工具等。
在性能分析模块，我会根据此项目场景执行过程中实际遇到的问题，进行具体的一步步分析，对有价值的性能问题，我会一一记录。
在结果报告阶段，我会写一个侧重于全链路压测视角的报告。教你怎么把压测结果以最清晰和高效的方式呈现出来。
在全链路压测项目中，这里面的每个环节都直接决定项目的成败。所以希望你能紧跟我的步伐，把握好每个细节，让项目顺利落地。
最后，我想说，如果成为一名优秀的性能工程师是你的心之所向，如果你不甘于在性能项目中因为知识的匮乏受到白眼，如果你需要可以和其他的任何一个技术岗位平起平坐的机会，如果你希望可以在下面的技术冲突中得到尊重。如果你希望在性能这条路上走得更远，那就与我一起踏上这段旅程，我会把我从业十几年来的经验毫无保留地分享给你。
好了，今天就说到这里。在课程正式开始之前，让我也认识一下你吧！关于全链路压测，你有什么心得，又有哪些积存已久的困惑？欢迎你在留言区和我交流讨论。
希望这个专栏，可以让你找到一些共鸣，助力你的技术和思维能力再攀高峰，我们出发吧！
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
这篇文章讨论了全链路压测的重要性以及在企业中的实际应用。作者提出了“RESAR性能工程”概念，强调了性能项目的全流程思维转变，并详细描述了全链路压测的落地实践。文章指出了全链路压测行业现状存在的问题，并探讨了全链路压测在企业中的实施需要涉及到多个岗位的协同合作。此外，作者还讨论了全链路压测中的管理协调和压力工具改变等问题。全文分为六个部分，包括核心理论、实践需求、环境准备、场景执行、性能分析和结果报告，详细介绍了全链路压测的实际落地过程。总的来说，这篇文章对于想要了解全链路压测的读者来说是一份具有实际应用价值的技术指南。
2021-10-1925人觉得很赞给文章提建议
仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《全链路压测实战 30 讲》，新⼈⾸单¥59
《全链路压测实战 30 讲》，新⼈⾸单¥59
立即购买
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(23)
- 最新
- 精选
yungoo流量构造、数据隔离、容量评估和性能管理，这几块是我非常想学习的，课程看来都有涉及，期望深度也够。作者回复: 我们也希望够深入。哈哈。
2021-10-197
夜空中最亮的星三个专栏我都买了，继续跟着老师学习！作者回复: 一起进步。
2021-10-216
future高楼老师，久仰大明。请问现在大厂做的crash平台，移动终端统一日志收集平台，甚至是AI流量性能自动预警这些赋能业务的重型平台越来越多，对一些大型公司来说性能测试貌似变成了技术平台开发，企图把所有操作规范化自动化，而中小公司往往又找不到经验丰富的性能测试，很多性能测试人员的认知来源于书本，缺乏实战的历练，对于这种背景下，性能测试人员最具有价值的核心竞争力是什么呢，在当前又有什么技术是可以作为性能测试的技术壁垒，可以让性能测试这项工作既不会脱离个人的能力范围，又能带来足够多的价值呢。作者回复: 只有技术功底深厚可以是壁垒。 从我接触到的客户来看，赋能平台希望达到的目标和实际的功能差别大部分都是航空母舰和柳叶舟的距离。
2021-10-213- 思辰5全链路压测如何在生产环境不注入代码实现，这个问题我比较好奇
作者回复: 那就直接在网关做流量识别，直接旁路出去呗。
2021-10-193 
萧戏我是一名运维，收到了一个任务，做新项目压测，保证线上不出问题，压力大，就找到了这个课程，希望对我有帮助。加油，开始学习了。作者回复: 性能技术肯定是有用的。技术是不分岗位的。
2022-06-23归属地：北京1
xinzi来系统学习作者回复: 共同学习。
2023-04-23归属地：广东- Geek_d35a95感谢老师
作者回复: 多谢支持。
2023-03-21归属地：四川 
游子请问一下老师，后端提供的接口，很多都是有依赖关系的，A接口的入参，需要B接口的结果，这种情况下，做完整的业务流程压测，有工具推荐吗？还是说需要自己开发呢？作者回复: 几乎所有的测试工具中都有一个功能叫“关联”，就是解决这种情况的。
2022-08-24归属地：北京
LetMeCode老师您好，有个问题咨询下。 登录流程分为调验证码+登录接口，那在测试登录的TPS一起测的时候需要一起测吗，还是让开发把验证码功能关掉只测登录接口。 一起测时好像受限于验证码接口的TPS作者回复: 万能验证码。
2022-05-27
Sam老师，您好！我是自动化测试的，全链路压测，其实为什么要叫全链路？为什么需要全链路呢？有没有形象的比喻？非常感谢🙏作者回复: 形象？ 我不知道你说的形象是怎么个比喻？我还是得学学语文了，你看这样算不算形象？ 我觉得之所以叫全链路，是因为微服务被拆成一块一块的，就像坐火车时穿过一个个城市，如果从北京到上海一直不下车，那就是全链路。如果从济南下车又换了个车，那就叫半链路。 这样可以不？哈哈。
2022-05-192
收起评论
