65 lines
8.2 KiB
Markdown
65 lines
8.2 KiB
Markdown
|
# 结束语 | 做能落地的全链路压测项目
|
|||
|
|
|
|||
|
|
你好，我是高楼。
|
|||
|
|
|
|||
|
|
历时四个多月，正文超过15万字，环境搭建部分超过13万字，在不知道熬了多少个夜之后，28万字终于码完了，全链路压测专栏也到了尾声。这个专栏写得很辛苦，相信你读起来也不轻松，有不少同学跟我说专栏内容太难，哈哈没办法，不难还能叫全链路压测么。
|
|||
|
|
|
|||
|
|
## 为什么要写这个专栏？
|
|||
|
|
|
|||
|
|
其实一开始啊，我是非常拒绝写一个全链路压测专栏的，因为它没有超过我之前专栏中写的RESAR性能工程的逻辑。但是我们 7DGroup 小组内部讨论的时候，左泽位同学和李文同学都非常积极，他们都希望能把这样一个热点技术话题给完整地写出来。最后我被说服了，我们讨论出了几个要写的理由：
|
|||
|
|
|
|||
|
|
1. 网上并没有一套完全可落地的全链路压测技术实现，仅有的资料也只是蜻蜓点水似的宏观的方案描述。这一点其实无可厚非，毕竟都是公司内部的资产，每一个字拿出来都是要经过层层审核的。公司需要对内部资料保密，同时也要保证技术先进性。但是这种又要体现公司技术牛逼，又半遮半掩的分享姿态实在是让人感觉不到诚意。而我们如果能够尽已之力把好的技术分享出去，消除这层知识壁垒，我觉得算是好事一桩了。
|
|||
|
|
|
|||
|
|
2. 全链路压测的技术方向是个热点话题，大家也都希望能够了解更多细节，所以应该能获得一些关注度。这一点我是持保留态度的，因为我知道文艺片卖好不卖座的道理。虽然这个话题很热，但实际上全链路线上压测要求企业内部各方的协调。哪怕到现在专栏写完了，我也认为要想落地全链路压测，除了专栏当中的技术内容，还有其他很多方面需要准备。
|
|||
|
|
|
|||
|
|
3. 多多少少有那么点技术人的执念，觉得这样一个好话题却到处都找不到一个完整的落地逻辑，太可惜了。网上总把全链路吹成“保障生产的核武器”，但看过之后你却根本不知道核武器的组成物质是什么，让人有种隔靴搔痒的感觉。
|
|||
|
|
|
|||
|
|
|
|||
|
|
鉴于此，我们决定写这个专栏。同时呢，我们决定全部使用开源产品，让你不仅能看懂，还可以动手实践；如果你想在公司内部推广，成本也可以降到最低。
|
|||
|
|
|
|||
|
|
## 专栏的质量靠的是细节的考究
|
|||
|
|
|
|||
|
|
这个专栏不是我一人之功，而是我们 7DGroup 小组之力。从一开始讨论到决定要写这个专栏，再到觉得写不出来，面临断更的危险，再到最后写出来，这四个月，我们就像在坐过山车一样，还是24小时无休的那种。
|
|||
|
|
|
|||
|
|
在专栏筹备过程中，我们买了云服务器，这一点是个上个专栏不一样的。上一个专栏中，我们是自己弄了一个机架、几个物理刀片机、交换机，然后从物理层开始搭建。而这一次，为了重点体现上层应用的部分，我们直接用了云服务器，这个成本两万打不住。性能项目就是这样，环境的成本是从来都不能敷衍的。
|
|||
|
|
|
|||
|
|
我们是拿一整个系统来做的改造，从这个专栏的内容中你也可以看到，这就是一个完整的性能项目记录，而不是一个只有理念或者套话的凑字之作。在写的过程中，我们从来都不考虑字数，而是考虑如何把过程体现得更完整，这导致我们最终交付的文稿字数比预期多了60%，这真是加量不加价了。
|
|||
|
|
|
|||
|
|
全链路压测专栏的重中之重在于改造，所以我们花了大量的篇幅在具体的改造上。写作的过程中，我们也会去查当前的技术市场上都有哪些技术实现，不仅与现在很多大厂做全链路压测的朋友们沟通，还会把他们的技术方案拿出来讨论对比。也就是说，不仅要都了解，还要做落地对比，争取使用最为合理的技术实现。这个过程是痛苦的，通常比了很久才能有一篇产出。
|
|||
|
|
|
|||
|
|
我还记得有一次在咖啡厅，我们在讨论日志改造那一篇的内容。当时已经写完了一个版本，不过只写了逻辑，并没有具体的落地代码实现。但是我觉得还是不能这样写，这种虚头巴脑的东西写了没什么意义。于是我们立即决定重写一篇，那一天我们三个人用7个小时合作完成了一篇新的日志改造文章，把落地思路和代码实现都写了出来。
|
|||
|
|
|
|||
|
|
就是在细节上一次次的纠结才有了专栏最终呈现的样子，这也是我们技术能力范围内最好的样子了。
|
|||
|
|
|
|||
|
|
## 如何落地全链路压测
|
|||
|
|
|
|||
|
|
聊完专栏的诞生过程，我们可以再看看后续的行动。如果你想在公司内部推广全链路压测，首先要考虑两方面的问题。
|
|||
|
|
|
|||
|
|
1. 时间成本：这个时间成本主要是技术改造的落地时间、以及和各部门、上下级沟通的时间。这其中，沟通的成本又会远大于落地的时间成本。
|
|||
|
|
请不要因为领导一句口头上的支持，就盲目去找各团队沟通。你需要非常具体的授权，需要所有人都知道你在做这件事情，并且每个人都不是支持的角色，而是全链路项目中的一员。在大部分企业中，做全链路压测的配套改造，不是技术上难不难的问题，而是部门间的沟通问题。有的部门一上来就表示拒绝承担更多的工作量，再加上一些领导的懒政风格，问题就变得很不好解决了，这是非常现实的事情。
|
|||
|
|
2. 人力成本：从技术角度来看，全链路压测花在改造上的人力成本并不会很多，你从专栏中估计也能看出来。如果手快的话，我们这样6个系统，应该不会超过1人月，而高级工程师的角色参与要超过4-5个人月，管理角色至少1个人月。当然，前提是所有的权限都在这些人的管控范围之内，他们能处理的内容包括运维、开发、测试、分析、架构等。如果你的系统比较多，并行处理应该也不会有大的时间成本差异，只是人月数会等比例递增。
|
|||
|
|
|
|||
|
|
有了时间和人力成本的考量之后，具体的技术实现我都已经在专栏中给你展现了，我还把源码链接放在了[第25讲](https://time.geekbang.org/column/article/467606)，你完全可以跟着专栏的逻辑去做具体的落地实践。如果后面还有精力的话，我们会尝试把全链路的改造整理成一个SDK，开源出来给所有人使用。
|
|||
|
|
|
|||
|
|
在全链路压测方案的设计上，你可以参考下图中标红的部分。
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
这些部分的实现都是需要部署能力和开发能力的。如果你是一个纯做测试的，而且也没有开发功底，可能看这个专栏会觉得比较难理解。这其实不是技术思路上的差异，而是对性能工程理解上的差异。
|
|||
|
|
|
|||
|
|
在我看来，测试人员已经不能再守着测试工具本身，我们还要扩展自己的知识体系。不然不仅测试做不好，性能分析更是做不到。
|
|||
|
|
|
|||
|
|
从性能工程的角度思考，我认为你需要的技术功底要包括下面这些内容。
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
当一个团队有了上面的实现方案，又有了技术的支撑，落地全链路压测就是轻而易举的事情了。
|
|||
|
|
|
|||
|
|
当然了，我在开篇词和正文中也反复说过，要不要推广全链路压测一定要结合企业现状，我们不能做事倍功半的事情。
|
|||
|
|
|
|||
|
|
我希望通过专栏中实际的改造落地过程，给你展现全链路压测真正的技术难点，把全链路压测的神话拖到地板上摩擦。全链路压测从来都不是法外之地，它也必须遵从性能工程的逻辑。当然，也希望你跟我一样，可以从每个技术细节中体会性能艺术的壮阔和性能分析的博大精深。
|
|||
|
|
|
|||
|
|
[](https://jinshuju.net/f/uO5dGy)
|
|||
|
|
|
|||
|
|
这门课到这里就彻底结束了，感谢你能坚持学完，也希望它能够让你重新认识和了解全链路压测。接下来就看你的了。再见！
|
|||
|
|
|