全链路压测

https://www.cnblogs.com/imyalost/p/15355660.html

前言

之前断断续续写过一些全链路压测相关的技术文章，很多同学评价还不错。朋友建议我写个系列，基于自己的落地实践经验，对全链路压测做个系统性的梳理总结。
今年跳槽后我的工作重心也偏向了全链路压测和稳定性保障方面的研究，这个时间点写这个系列，也算是对自己过去工作的最好总结。
整体写作规划里，这个系列大概有14篇内容，不排除后期有新的理解和沉淀，会加更。目前草稿写差不多了，大体的更新节奏，应该是一周2篇左右的样子，静等更新吧。

目录大纲

背景：天猫2012双11的痛

全链路压测这个Topic，最初是阿里提出的，背景缘由也很简单，双十一大促嘛。
13年之前，阿里每次为了准备双十一大促系统能平稳支撑，都要花4-6个月准备，然后大促结束后花2个月时间打扫战场。
整个过程，参与的各个团队的同学加起来有将近200人，其中最耗时的点主要集中在机器容量评估和预案梳理以及压测优化方面。
结果2012年双11零点时刻，由于访问量过高，还是出了问题：商品超卖无法发货。这个问题当时还上了央视新闻，可见其影响力。
后来他们内部复盘，一番讨论后，为了避免后续的大促再次出现类似的问题，决定在生产搞压测，这就是现在被很多测试同学所熟知的生产全链路压测的背景由来。

定义：如何理解全链路压测

PS：这里的定义，是我自己基于自己对生产全链路压测的了解和实践总结得来的，仅代表个人观点。
1、什么是全链路压测？
基于实际的生产业务场景和系统环境，模拟海量的用户请求和数据，对整个业务链路进行各种场景的测试验证，持续发现并进行瓶颈调优，保障系统稳定性的一个技术工程。
2、全链路压测解决了什么问题？
针对业务场景越发复杂化、海量数据冲击，发现并解决整个业务系统的可用性、扩展性以及容错性的过程。
3、全链路压测创造了什么价值？

• 技术角度：降低成本、提高服务可用性、技术练兵&团队协作&快速响应；
• 业务角度：提升用户体验、技术更好的服务业务、创造更多业务价值。

差异：传统压测和全链路压测

记得刚开始学习性能测试相关知识的时候，我一直有个疑问：性能测试可以对测试工程师本人和企业带来什么价值？
随着不断学习成和工作中的实践以及和很多测试同学交流，我总结出了如下几点优点和潜在价值：

• 提升测试工程师的技术能力；
• 提升对系统架构和业务逻辑的了解；
• 提升测试工程师在职场和求职市场的竞争力；
• 提前发现系统潜在的不稳定因素，提高线上系统稳定性；
• 更精准的容量评估和容量规划，降低系统的硬件成本和维护成本；
• 保障系统在大促秒杀等场景和峰值流量冲击下的稳定性，助力业务目标达成；

随着互联网行业不断发展，系统架构越发复杂，业务场景越发多样化，对性能测试的要求也越来越高，传统压测方式已经无法满足业务和技术的发展需要。
相比于传统的压测方式，全链路压测作为性能测试领域新阶段的最佳实践，它们的差异如下：

思考：解决差异带来的不稳定

传统压测和生产全链路压测的主要区别，概括来说可以分为如下四个点：

• 环境问题：主要是机器配置、节点数量以及一些参数配置方面（线程池、JVM）；
• 成本问题：单独的性能测试环境，机器成本和维护成本较高，生产在这方面几乎是0成本；
• 真实性问题：硬件配置差异、数据差异、中间件配置差异等，都可能导致流量预估和压测结果偏移；
• 数据流向问题：测试环境大多都是单接口单链路压测，数据流转性无法保证，数据多样性也存在部分问题；

那么，要解决差异带来的不稳定因素，最终的选择就是生产全链路压测：

挑战：如何落地生产全链路压测

虽然全链路压测解决了传统压测过程中的种种痛点，可以为线上性能评估提供更多详实的参考建议。但在落地过程中，全链路压测依然要解决很多问题，主要有如下几点挑战：

1、链路梳理
现在大多数企业都是采用微服务架构来设计系统，且业务场景多样化，导致了系统架构异常复杂。
要覆盖所有压测范围内的场景，就需要对涉及的所有应用及其调用关系进行梳理。目前业内还没有较好的链路梳理工具，导致这个过程需要人肉来梳理，耗时且费力。
2、数据隔离
生产全链路压测最重要的一点是避免对生产数据造成污染。业内常见的做法有如下两点：

• 压测数据写入正式库表，然后通过特殊的字段进行清理（业务改造成本大，清理风险高，耗时久）；
• 采用影子库表，压测流量数据进行影子库表，在不对生产数据造成污染的情况下进行压测；

3、避免业务侵入
在全链路压测落地过程中，有一点必须考虑到的是业务部门的接受能力。如果要通过技术框架改造或者采用数据标记的方式来实现，势必会对生产业务造成一定影响（要改造是需要大量资源和时间的）。
4、性能定位分析
全链路压测是在生产环境进行，压测过程中，除了要防止数据污染，完善的监控体系和实时的可视化链路追踪也是很重要的一点。
不同企业在监控体系方面的建设都不一样，要进行全面详细的流量评估，需要有完善的监控平台来进行各维度的数据采集和展示。
在整个压测链路中，实时的可视化链路追踪能实时的观察到每个调用链路的具体信息，对问题的快速发现和定位有重大的帮助。
还要考虑到不把生产服务压挂。因此需要一套完整的机制来保证，压测在正常实施的同时，不对生产服务应用造成影响。
5、更多挑战
全链路压测是在生产环境进行，压测过程中，要考虑不对生产服务造成影响。因此需要一套完整的机制来保证，压测在正常实施的同时，不对生产服务应用造成影响。

流程：生产全链路压测落地实践

生产全链路压测的整个流程，大致可分为三个环节，每个环节的主要事项如下：

能力建设：生产压测能力演变历程

生产全链路压测的本质，是个能力建设的技术工程，不是一蹴而就的。整体的演变历程大致如下：

1、需求驱动压测
这个阶段的主要特点是被动式响应压测需求，效率低，无法快速定位性能问题，结果对线上没太多参考价值。
2、性能体系建设
这个阶段主要是性能测试体系的建设过程，比如日常版本压测和性能基线性能回归等。
3、线上风险识别与熔断
到了这个阶段，就需要线上有一定的监控报警体系和风险熔断能力。
4、生产只读业务链路压测
只读场景相对来说技术难度没那么大，可以通过这个阶段来做到技术练兵。
5、生产流量数据隔离能力
上面提到了数据安全隔离，这也是生产全链路压测最大的一个技术挑战。
6、生产部分业务链路压测
全链路的覆盖场景根据业务不同要覆盖的范围和难度也不一样，建议先从非核心业务开始落地做试点验证。
7、生产全链路压测
通过上面几个步骤，从基础的能力建设、体系建设，到线上的监控能力、只读场景练兵以及数据隔离到试点验证，最终才能达到生产核心链路全链路压测的过程。

最后

以上内容主要是对全链路压测的背景及落地实践和演变过程做个介绍，后续的系列文章会针对每个环节进行讨论和说明，敬请期待。
建了一个全链路压测沟通交流群，扫描下方二维码即可进群交流。

转载请注明出处，商用请征得作者本人同意，谢谢！！！
分类: 性能测试
好文要顶 关注我 收藏该文

老_张
关注 - 9
粉丝 - 3840
+加关注
6
0
«上一篇： 碎片式的技术笔记
»下一篇： 全链路压测(2)：方案调研和项目立项
posted @ 2021-09-30 10:37 老_张 阅读(5199) 评论(9) 编辑 收藏 举报

前言

全链路压测从零开始系列的第一篇文章介绍了全链路压测的背景、定义、和传统压测的差异以及如何解决差异带来的不稳定性，
落地要面临的挑战和完整的压测实践流程以及长期的能力建设演变，算是对全链路压测有了一个比较系统和全面的介绍。
本篇是系列的第二篇，从这篇文章开始，我会基于自己的个人落地实践经验，给大家分享从零开始落地全链路压测，要做哪些事情，以及这个过程中遇到的挑战、踩过的坑以及该如何解决这些问题。

申报立项

一般来说，像生产全链路压测这种复杂的需要多个技术团队参与的复杂技术项目，在企业内部都会有一个项目申报和评估立项的过程。

项目申报

下面是一个项目申报的模板，大家可以参考下：

评估立项

项目申报后，就是多方评估是否立项的环节，在这个环节，主要有如下几件事：

1. 目前存在的问题是否真的有这么严重？
2. 这些问题如果不解决是否会对业务造成影响？
3. 做这件事，能否解决目前存在的问题？
4. 做这件事，要投入的时间资源和对业务及团队的价值，有多大？
5. 这件事的优先级有多高？

调研评估

在项目正式启动前会有个调研环节。这里的调研主要指的是基于自身当前所处阶段及面临的问题和实现生产全链路压测之间的差异，以及如何解决差异的解决方案。
我个人总结下来，方案调研可以分为如下四个阶段：

看：大厂都是怎么做的？

全链路压测是个技术复杂度比较高的跨团队的技术项目，最初也是大厂的自留地。
在调研方案时候，有必要看看大厂都是如何做的，避免走太多弯路。前面提到了落地生产全链路压测的几个挑战，下面我从这几个挑战点来做个梳理对比，帮大家快速的了解，大厂是如何做的。

PS：针对上表的一些术语和“/”内容，这里做个说明。
1、链路梳理
现在大多数企业都是采用微服务架构来设计系统，且业务场景多样化，导致了系统架构异常复杂。
要覆盖所有压测范围内的场景，就需要对涉及的所有应用及其调用关系进行梳理，手工来梳理，耗时且费力。
上面提到的几家大厂的鹰眼啊Mtrace系统之类的，实际上都是基于分布式链路追踪工具自研或二次开发的。
分布式链路追踪工具，推荐开源的Jaeger，Jaeger是Uber推出的一款开源分布式追踪系统，兼容OpenTracing API。
分布式追踪系统用于记录请求范围内的信息，例如，一次远程方法调用的执行过程和耗时。是排查系统问题和系统性能的利器，同时在链路梳理方面，能提高很多效率。
Jaeger的UI相较于Zipkin更加直观和丰富，还有则是sdk比较丰富，go语言编写，上传采用的是udp传输，效率高速度快。

• Github地址：jaegertracing/jaeger
• 官方地址：Jaeger: 开源分布式端到端链路追踪系统

2、数据隔离

• 流量染色：对于单服务来说，识别压测流量只要在请求头中加特殊压测标识即可，HTTP和RPC服务是一样的。
• 影子库表：核心思想是使用线上同一个数据库实例，包括共享数据库实例中的内存资源，因为这样才能更接近真实场景，只是在写入数据时会写在另一个“影子库表”中。大概原理如下：

3、避免业务侵入
如果要通过修改业务应用或者采用数据库表数据标记的方式来实现，势必会对生产业务造成一定影响（要改造需要大量资源和时间）。
4、性能定位分析
全链路压测的初衷还是为了发现并解决系统在峰值流量冲击下的稳定性问题，因此性能定位分析的工具和完善的监控体系是必备的。一般在企业级技术监控领域，大体分为五种类型的监控：

• 基础监控：包括带宽、CDN、服务器CPU、Memory、DiskIO、Network、Load5等指标；
• 指标监控：服务+接口维度，常见指标有QPS、TPS、SLB、RT、99RT、timeout、activethreads等指标；
• 业务监控：拿电商来说，常见的有同比下单量、支付量、履约率、DAU、GMV、支付取消率等多重指标；
• 链路追踪：如上面提到的Jaeger，是排查系统问题和系统性能的利器，同时在链路梳理方面，能提高很多效率；
• 舆情监控：主要指对外部的一些讯息的监控，比如某APP突然挂了、下不了单、有BUG可以刷单、客诉等一些列对企业或者品牌不利的因素，便于快速处理甚至公关；

5、服务安全保护
全链路压测是在生产环境进行，压测过程中，要考虑不对生产服务造成影响。因此需要一套完整的机制来保证，压测在正常实施的同时，不对生产服务应用造成影响。一般都会通过熔断和流量干预的机制来保证。

听：SaaS服务商怎么说？

国内全链路压测的SaaS服务商，目前只有2家：数列科技和perfma。这里以我比较熟悉的数列的SaaS产品举例子，他们的全链路压测产品主要优势有如下几点：

• 业务代码0侵入：在接入、采集和实现逻辑控制时，不需要修改任何业务代码；
• 链路自动梳理：仅需部署客户端，无需对应用进行任何改造，就可以看到所有的服务调用关系，快速理解系统架构，并且通过链路架构图可以详细了解链路经过的应用、缓存、中间件、DB，甚至第三方的API，每条链路的所有走向都一目了然；
• 数据安全隔离：在不污染生产环境业务数据情况下进行全链路压测，可以对写类型接口进行直接的性能测试；
• 安全性能压测：在生产环境进行性能压测，对业务不会造成影响；
• 性能瓶颈快速定位：性能测试结果直接展现业务链路中性能瓶颈的节点；

而且今年他们已经将自己的全链路压测产品开源了，并且支持多环境压测，下面是他们的压测多环境支持流程图：

Github地址：开源全链路压测平台Takin

做：小范围接入改造看效果

看完大厂是怎么做的，以及SaaS服务商的产品，接下来就是要进行小范围验证了。一般进行小范围接入改造，主要有如下几点需要注意：

• 环境：如果有多套测试环境，可以选择一套使用率较低的，否则建议临时单独搭建一套缩容的环境进行改造接入以及测试验证；
• 业务：前期在调研验证阶段，建议选择核心业务对应的应用服务来进行验证，这样更方面了解具体的效果是否达到预期（当然，在落地阶段，刚开始建议选择非核心业务）；
• 资源：这里主要指人力资源，在项目立项后，建议有专门的人手资源来做这件事，否则项目很容易延期甚至无疾而终，在工作产出考核上，也不太好；

评：自研或SaaS产品的ROI

经过上述三个阶段的调研和验证，这里需要对项目最终的整套解决方案做一个选型确定：是选择自研还是SaaS服务商的全链路压测产品。
从我个人的落地实践经验和了解来说，无论是自研，还是选择SaaS服务商，需要考量的因素主要有如下几点：
1.研发能力：一般来说，大厂或者中大型独角兽公司，研发能力和资源相对会比较强，且出于造轮子和KPI的目的，选择自研是相对来说比较好的方案。
当然对于中小型企业来说，研发能力和资源会弱一些，这种情况我建议还是选择三方服务商的SaaS服务或者开源产品，性价比会更高一些；
2.业务接受能力：如果是自研，特别是选择改造业务代码的方案时，一定要考虑到业务的接受能力。因为每次变更都会对线上带来新的不稳定因素，且改造占用的时间和资源会和业务需求迭代有所冲突。
如果是中间件层面改造或者采用的是无侵入的SaaS产品及开源产品，那么相对来说这个矛盾就仅限于技术团队内部；
3.项目预算投入：这里的预算包括时间、风险、需要投入的人力物力等。
4.ROI(投入产出比)：实际上一个项目到了最后，要不要做的最终考虑因素就是投入产出比，以更低的风险和成本解决更大范围的严重问题，永远是优先级最高的。

总结

本篇主要对全链路压测的项目立项和调研环节要考量的点以及业内的一些方案&SaaS及开源产品做了介绍。
下一篇开始，会介绍落地实践过程中具体要做的一些事情，包括工具选型、流量评估等，会结合具体的业务场景来为大家分享如何从零开始的落地全链路压测。
建了一个全链路压测学习沟通群，感兴趣的可以扫码进群一起交流学习。

转载请注明出处，商用请征得作者本人同意，谢谢！！！