118 lines
13 KiB
Markdown
118 lines
13 KiB
Markdown
|
# 开篇词 | 打破认知神话，做接地气的全链路压测
|
|||
|
|
|
|||
|
|
你好，我是高楼。
|
|||
|
|
|
|||
|
|
可能很多人已经认识我了，因为这已经是我在极客时间开设的第三门课程了。这次，我想和你聊聊全链路压测。
|
|||
|
|
|
|||
|
|
回顾从业十几年的经历，我一直在做性能测试、性能分析、性能优化的工作。早年间我在各大测试论坛分享自己的工作经验，并形成了关于性能测试完整的知识链。后来，我开始自己带团队做项目，完整做过40多个项目，团队也从最初的四五个人到300 余人。与我合作过的人都了解，我做性能项目的宗旨就是上线不死，死了不收钱。
|
|||
|
|
|
|||
|
|
2019年，我的第一个课程[《性能测试实战30讲》](https://time.geekbang.org/column/intro/100042501)上线了，2020年，我又开了第二门课程[《高楼的性能工程实战课》](https://time.geekbang.org/column/intro/100074001)。在这两个课程中，我描述了我认为在测试过程中重要的部分，比如整体概念梳理、性能分析思路等。
|
|||
|
|
|
|||
|
|
我希望通过这两个课程，可以抛出一个价值观：**让性能变得有价值。**我希望更多的人知道，性能如果只是停留在“测试”的层面，根本不能发挥它本该具有的价值，“调优”也是非常重要又不可忽视的部分。
|
|||
|
|
|
|||
|
|
对于一个企业级性能项目来说，性能的价值是给出结论数据，判断出系统的最大容量、稳定性运行时长。但是，大部分企业的性能项目做得如同儿戏一般，只有最简单的验证，系统资源大量闲置，而调优的动作几乎没有。当然了，也有可能是因为他们并不知道怎么做。但无论如何，这样的系统匆忙上线，一定会浪费大量不必要的资源。至于一个性能人员能把性能做得多深入，就取决于个人的努力了。
|
|||
|
|
|
|||
|
|
我还提出过一个重要的概念，就是“RESAR性能工程”。“RESAR 性能工程”这个名字是我自己起的，你不用去网上搜索，因为现在还搜不到。它对性能项目过程中的各个具体的动作做了更详细的描述，使之成为可以落地的具体实践。
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
在前两个专栏，我一直强调**把性能从“测试”思维转换到“工程”思维**。这个思维的转变，涵盖了性能项目的全流程，不仅有技术的细节，还有需求、模型、监控、分析的完整逻辑。只有这个逻辑完整了，性能才能做得有价值。
|
|||
|
|
|
|||
|
|
在我看来，全链路压测只是性能容量场景中的一个具体案例。它并没有跑出“RESAR性能工程”的范围。RESAR性能工程中的所有逻辑思维，都将在这个全链路压测的专栏中落地实践。
|
|||
|
|
|
|||
|
|
不过如果你没有看过上一个专栏也没有关系，你可以先看看我在上面给出的思维导图，了解一下它具体分为哪些板块。在项目具体落地的过程中，我也会把每个模块略作介绍，保证不让你有蒙圈的感觉。
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
你可能会问，既然全链路压测的逻辑已经包含在RESAR性能工程里了，为什么还要写一个全链路压测的专栏呢？它和之前的专栏有什么区别和联系呢？让我们先来看一下全链路压测行业的现状。
|
|||
|
|
|
|||
|
|
在网络上可以找得到的全链路文章中，大概可以看到阿里、有赞、饿了么、美团、滴滴、京东、字节、陌陌、达达等企业的技术文章，里面都提到了全链路压测在企业内部的落地。但他们是如何落地的，在细节上我们只能猜测一二。
|
|||
|
|
|
|||
|
|
## 全链路压测行业现状
|
|||
|
|
|
|||
|
|
在性能领域中，很多人看到全链路压测的目标和效果之后，都会觉得这是一套可以上天遁地的完整逻辑。事实是不是这样呢？看看网上能搜索到的信息，它们基本上有这么几个特点：
|
|||
|
|
|
|||
|
|
1. 目标和方案只有摘要级的说明。
|
|||
|
|
2. 全链路压测平台的细节描述宽泛，没有完整的落地细节。
|
|||
|
|
3. 只有大厂的一些笼统资料，但并没有投入成本（人员成本、资金成本、时间成本）的数据。
|
|||
|
|
4. 无架构级全链路改造的细节。
|
|||
|
|
5. 无架构级监控平台范围的细节。
|
|||
|
|
6. 无性能分析逻辑的细节。
|
|||
|
|
|
|||
|
|
因此，在网上看了各种资料之后，你可能还是有很多困惑：首先，不知道自己的企业能不能支撑；其次，不知道应该如何具体实施；再者，不知道投入成本有多大。
|
|||
|
|
|
|||
|
|
在这些问题还没有搞清楚之前，偏偏一些企业的管理者只看效果，觉得这件事情是需要做的，于是安排了相关的任务给具体的实施层。实施层由于没有管理权限、没有成本计算能力、没有技术细节的实现能力，于是越做越觉得坑太大，填不住。只能想各种招儿来应对领导这一看似合理的安排。
|
|||
|
|
|
|||
|
|
举个例子，全链路压测的出发点是对线上的真实系统做改造后直接在线上压测，而一些企业根本不具备这样的条件，所以为了跟上潮流，他们只会做一些小的动作，在线上减少覆盖范围并分段进行压测。但是这个改变，其实完全失去了全链路压测的价值。
|
|||
|
|
|
|||
|
|
实际上，全链路的落地是要经过综合考虑后，公司上下共同努力的结果。从整个全链路项目来看，企业里从老板到最底层的工程师，都会需要参与进来。也就是说，全链路涉及老板、产品经理、架构师、开发工程师、测试工程师、运维工程师等各个角色。
|
|||
|
|
|
|||
|
|
不过，不同岗位的关注点是不同的。老板关注的是，全链路压测带来的业务容量提升和企业利润增长；产品经理要关注的是，业务容量的增长和后续功能的设计；架构师要关注的是，全局架构设计对全链路压测的宏观支撑；开发工程师要关注的是，业务细节和技术细节的改造；测试工程师要关注的是，覆盖住这些改造；运维工程师要关注的是，全链路改造和线上的压测过程对系统整体状态的影响。
|
|||
|
|
|
|||
|
|
如果你的公司打算实施全链路压测，而你刚好处在这些岗位或者对这些岗位有意向，那么我的这门课很可能对你有帮助。因为我对全链路压测是认真的，我要做的就是实战，就是**“把全链路压测拉到地面上”**，让你真正地了解它。
|
|||
|
|
|
|||
|
|
不过，在正式进入课程之前，我还想跟你聊聊几个你可能会关心，但是和技术无关的问题。
|
|||
|
|
|
|||
|
|
### 全链路压测最难的是什么？
|
|||
|
|
|
|||
|
|
全链路压测最难的，到底是什么呢？
|
|||
|
|
|
|||
|
|
是应用改造吗？是压力工具改造吗？是逻辑思维的转变吗？
|
|||
|
|
|
|||
|
|
在我看来，都不是。最难的应该是：**管理协调**。
|
|||
|
|
|
|||
|
|
由于全链路压测涉及到的团队多、系统多、链路长，这就导致了管理成本的迅速增加。
|
|||
|
|
|
|||
|
|
相比较而言，技术的实现就是细节的落地过程，消耗的只是人员和时间成本。
|
|||
|
|
|
|||
|
|
虽然我们这个技术专栏不会涉及管理协调（因为每个企业都有自己的管理逻辑，而且管理主要是和人相关，所以我无法给你一个放到不同企业都可用的管理思路），但你要记住，人员的协调非常重要，千万不可以小看它的影响。
|
|||
|
|
|
|||
|
|
### 全链路压测一定会涉及压力工具的改变吗？
|
|||
|
|
|
|||
|
|
这一点是不一定的。因为全链路压测的出现，是为了响应互联网企业大流量的需求。但是，不是所有的互联网企业都有那么大的容量需求，如果容量需求不大，是不需要改造压力工具的。
|
|||
|
|
|
|||
|
|
那有没有某种工具只是为了全链路压测而存在呢？答案是：没有！
|
|||
|
|
|
|||
|
|
因为压力工具是为了对服务端发送请求而存在的，所以不管你用传统压力工具，还是用现在市面上的所谓全链路压测工具，只要能够按需求对服务端发出请求，那就足够了。
|
|||
|
|
|
|||
|
|
有人说，我的全链路压测是可以基于多个公网上的压力服务器调用的，这一点和传统压力工具有很大的区别。我只能呵呵一笑，你觉得传统压力工具做不到吗？
|
|||
|
|
|
|||
|
|
### 全链路线下压测有没有价值？
|
|||
|
|
|
|||
|
|
因为全链路压测是为了满足线上环境的容量需求，所以所有的全链路相关的动作也都是基于线上环境来讨论的。但是，如果一些企业出于对制度或风险的考虑，不能或不想在线上环境做全链路压测，可不可以把全链路压测的逻辑应用于线下环境的压测呢？
|
|||
|
|
|
|||
|
|
答案当然是：完全可以，但是！是不是就怕看到但是？哈哈，但我还是得说：但是全链路压测如果不在线上做，那就摆脱了环境的限制，摆脱了影响生产系统的风险。
|
|||
|
|
|
|||
|
|
第一，“全链路”这个词强调的改造部分就不需要做了。因为改造的目的是区别压力流量和生产流量，而线下没有生产流量，所以不需要做改造。
|
|||
|
|
|
|||
|
|
第二，如果线下环境的业务流量需求没有线上环境要求的大，那么全链路压测强调的压测工具的分布式改造也就没必要了。
|
|||
|
|
|
|||
|
|
第三，如果线下环境的业务流量需求和线上环境要求的一样大，企业也愿意把线下环境搭建成和线上完全一致，那就完全可以复制全链路线上压测的逻辑。
|
|||
|
|
|
|||
|
|
第四，有人说，换到线下用流量复制的工具来实现线上流量的放大回放，是否也有意义呢？其实这个动作也不是非常有必要，因为如果已经在线下做了，那压力工具完全可以配置出线上的请求比例，用不用流量录制回放的压力工具无所谓，只要能按业务比例实现压力就好。
|
|||
|
|
|
|||
|
|
所以，你看，**全链路线下压测不是没有价值，而是付出的成本似乎不会小**。虽然应用的改造不用做了，但环境就是最大的问题。注意，这里说的环境可不仅是硬件环境堆在那里，架构部署和数据的部分也不简单。如果去除硬件和部署架构，那显然就和以前我们做的性能项目无差了。
|
|||
|
|
|
|||
|
|
## 这个全链路压测专栏会如何组织？
|
|||
|
|
|
|||
|
|
在这个全链路压测专栏中，基于“把全链路压测拉到地面上”的定位，我会这样来组织。
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
我把这个专栏分成了六个部分，分别是核心理论、实践需求、环境准备、场景执行、性能分析和结果报告。在这六个部分中，我会把全链路压测实际落地的过程，真实、详尽地记录下来。目的就是，希望让你看到全链路压测的实现细节，不再把全链路当成神话一样来崇拜。
|
|||
|
|
|
|||
|
|
* 在核心理论模块，我会给你概括一下全链路压测过程中需要的重要逻辑。如：改造部分的逻辑、模拟场景的逻辑等。
|
|||
|
|
* 在实践需求模块，我会对性能项目中的几个重要环节进行详细说明。比如，压测方案设计、梳理核心链路、明确压测范围、数据构造、系统构造方案、性能监控等。
|
|||
|
|
* 在实践环境准备模块中，我会介绍全链路压测实践环境准备工作，对全链路压测项目中，前面的环境初始化环节的实操进行说明。
|
|||
|
|
* 在场景执行模块，我会带着你通过压测平台来实现全链路压测的场景。这里，我们会使用到各种不同的压力工具，比如炒得火热的流量回放工具等。
|
|||
|
|
* 在性能分析模块，我会根据此项目场景执行过程中实际遇到的问题，进行具体的一步步分析，对有价值的性能问题，我会一一记录。
|
|||
|
|
* 在结果报告阶段，我会写一个侧重于全链路压测视角的报告。教你怎么把压测结果以最清晰和高效的方式呈现出来。
|
|||
|
|
|
|||
|
|
在全链路压测项目中，这里面的每个环节都直接决定项目的成败。所以希望你能紧跟我的步伐，把握好每个细节，让项目顺利落地。
|
|||
|
|
|
|||
|
|
最后，我想说，如果成为一名优秀的性能工程师是你的心之所向，如果你不甘于在性能项目中因为知识的匮乏受到白眼，如果你需要可以和其他的任何一个技术岗位平起平坐的机会，如果你希望可以在下面的技术冲突中得到尊重。如果你希望在性能这条路上走得更远，那就与我一起踏上这段旅程，我会把我从业十几年来的经验毫无保留地分享给你。
|
|||
|
|
|
|||
|
|
好了，今天就说到这里。在课程正式开始之前，让我也认识一下你吧！关于全链路压测，你有什么心得，又有哪些积存已久的困惑？欢迎你在留言区和我交流讨论。
|
|||
|
|
|
|||
|
|
希望这个专栏，可以让你找到一些共鸣，助力你的技术和思维能力再攀高峰，我们出发吧！
|
|||
|
|
|