前言 之前断断续续写过一些全链路压测相关的技术文章,很多同学评价还不错。朋友建议我写个系列,基于自己的落地实践经验,对全链路压测做个系统性的梳理总结。 目前草稿写差不多了,大体的更新节奏,应该是一周2篇左右的样子,静等更新吧。 目录大纲 背景:天猫2012双11的痛 全链路压测这个Topic,最初是阿里提出的,背景缘由也很简单,双十一大促嘛。 定义:如何理解全链路压测 PS:这里的定义是我基于自己对生产全链路压测的了解和实践总结得来的,仅代表个人观点。 1、什么是全链路压测? 基于实际的生产业务场景和系统环境,模拟海量的用户请求和数据,对整个业务链路进行各种场景的测试验证,持续发现并进行瓶颈调优,保障系统稳定性的一个技术工程。 2、全链路压测解决了什么问题? 目前业内还没有较好的链路梳理工具,导致这个过程需要人肉来梳理,耗时且费力。 2、数据隔离 生产全链路压测最重要的一点是避免对生产数据造成污染。
——来自百度百科 本篇文章要说的全链路压测SOP,实际上就是我在实践全链路压测的过程中,对实践经验和教训的一个总结。 全链路压测(1):认识全链路压测 全链路压测(2):方案调研和项目立项 全链路压测(3):技术改造和测试验证 全链路压测(4):全链路压测的价值是什么? 全链路压测(5):生产全链路压测实施全流程 全链路压测(6):确认范围和识别风险 全链路压测(7):核心链路四问 全链路压测(8):构建三大模型 全链路压测(9):容量评估和容量规划 全链路压测(10) :测试要做的准备工作 全链路压测(11):聊聊稳定性预案 全链路压测(12):生产压测必不可少的环节 全链路压测(13):高可用和性能优化 再加上本篇的生产全链路压测SOP思维导图,就是整个系列的内容。 最后,重申一下我对全链路压测的部分认知: 全链路压测是一个技术工程,而非单纯的测试手段; 全链路压测只适用于部分企业和业务类型,而非一个银弹; 全链路压测的落地并非一蹴而就,需要较好的技术基础设施建设做保障
前言 前面的几篇文章从生产全链路压测的定义,内部立项和技术调研,聊到了测试验证以及全链路压测的对企业业务和技术团队的价值,算是整体上的构建一个认知的概念。 从这篇文章开始,会进入具体的落地实践环节。 这篇文章中,我会介绍生产全链路压测的落地实施全流程,即每个环节要做什么事情。 四大阶段 如果将生产全链路压测作为一个阶段性的技术项目来看,全链路压测从开始到项目结束,需要经过四个阶段。 整体的实施流程图如下所示: 接下来我来为大家解密,生产全链路压测落地实施,在不同的阶段都会做哪些事情。 筹备阶段 确定业务范围 一般来说线上实施线上全链路压测之前,要明确本次压测需要验证的业务范围。 核心业务定义 出问题会影响其他业务链路; 流量较高且出现问题会影响整体业务目标的达成; 核心项目定义 前面提到了生产全链路压测是个复杂的技术项目,那么如何定义这种技术项目呢?
RpcID RPCId用链路调用顺序来递增。 阿里云相似产品:Tracing Analysis 效果图: ? image.png
--全链路跟踪 sleuth zipkin --> <dependency> <groupId>org.springframework.cloud</groupId > <artifactId>spring-cloud-starter-zipkin</artifactId> </dependency> 2.编写yml文件 spring
Zipkin是SpringCloud官方推荐的一款分布式链路监控的组件,使用它我们可以得知每一个请求所经过的节点以及耗时等信息,并且它对代码无任何侵入,我们先来看一下Zipkin给我们提供的UI界面都是提供了哪些信息 zipkin首页为我们提供了对于调用链路的搜索查询及展示的功能 ? 第二个选项卡里提供了历史数据的导入功能 ? 第三个选项卡里展示了各个微服务之间的关系 ? 我们再次回到首页,我们点开一个调用链路之后就会看到此次链路调用的详情 ? 现在我们点开详情中的一个service,可以看到此次调用在这个微服务中的详细信息。 ? <artifactId>spring-cloud-starter-netflix-eureka-server</artifactId> </dependency> 2. 2.
作者:vivo 互联网前端团队- Yang Kun本文是上篇文章《Node.js 应用全链路追踪技术——全链路信息获取》的后续。阅读完,再来看本文,效果会更佳哦。 本文主要介绍在Node.js应用中, 如何用全链路信息存储技术把全链路追踪数据存储起来,并进行相应的展示,最终实现基于业界通用 OpenTracing 标准的 Zipkin 的 Node.js 方案。 2.2 zipkin 架构官方文档上的架构如下图所示:为了更好的理解,我这边对架构图进行了简化,简化架构图如下所示:从上图可以看到,分为三个部分:第一部分:全链路信息获取,我们不使用 zipkin 自带的全链路信息获取 ,我们使用 zone-context 去获取全链路信息第二部分:传输层, 使用 zipkin 提供的传输 api ,将全链路信息传递给 zipkin第三部分: zipkin 核心功能,各个模块介绍如下: 三、Node.js 接入 zipkin3.1 搞定全链路信息获取这个我在 《Node.js 应用全链路追踪技术——全链路信息获取》 文章中,已经详细阐述了,如何去获取全链路信息。
前言 前面的文章介绍了全链路压测的落地实施全流程,其中有个环节我特别提到了它的重要性,同时这也是本篇文章的主题:核心链路梳理。那什么是核心链路?为什么要确定核心链路?如何进行核心链路梳理? 梳理核心链路的目的又是什么?这篇文章,我会给你答案。 什么是核心链路? 之前在一些线下沙龙分享或者线上直播时候,很多同学都会问我一个问题:什么是核心链路?好像这个词有种魔法,很难让人去理解。 这么说比较拗口,再直白一些就是:哪些接口会影响用户下单支付,哪些就是核心链路。 下面附一个常见的电商企业核心链路流程图,供大家参考。 为什么要确定核心链路? 流量模型 我在前面的文章《生产全链路压测实施全流程》中有提高转化技术指标的一个案例,这里再次回顾下: 客单价为500,单日GMV为10亿,那么支付订单量为10亿/500=200W; 假设日常支付订单量为 文末回顾 这篇文章主要聊了全链路压测在备战阶段最重要的一件事,核心链路梳理。其中提到了流量模型相关的内容,下篇文章,我会以全链路压测过程中需要梳理的三大模型为主题,为大家介绍它们。
在开始真正的介绍落地实践过程以及相关案例之前,我想和大家聊聊,我对全链路压测的一些认知,即:全链路压测在技术团队中的定位,以及它的价值是什么。 业务和技术是什么关系? 全链路压测对稳定性保障的价值 聊了这么多,回到文章顶部,我所要表达的内容,全链路压测的价值是什么? 通过生产全链路压测,可以串联稳定性保障的全流程,解决线上系统稳定性保障面临的种种挑战,它所带来的价值如下: 总结回顾 这篇文章介绍了我对技术和业务关系的理解,线上稳定性保障面临的挑战以及全链路压测在其中的价值 ,通过前面的几篇文章,从认识全链路压测到项目立项以及技术调研和测试验证,我试图从另一个视角来为大家揭秘全链路压测的另一面。 下篇文章,我会为大家介绍,全链路压测落地实践的整体流程。
生产环境全链路性能测试体系建设之路主要包括生产测试流程规范建设、生产测试工具平台建设、生产测试实施团队建设、落地实施细则。本文主要聊一聊生产测试工具平台建设。 其中导出/导入规则是从应用维度全量导入或导出配置规则,启用/禁用规则是针对单条数据进行操作,不影响其他规则。有规则变更成功无须重启应用,但需发布变更才能生效。 三、链路分析平台具有链路分析能力,下面分别讲解平台上关于链路分析的配置项。首先是链路查询。它支持应用、实例、服务、请求结果、耗时、返回行数和开始时间等维度查询链路。其次是调用树。 对于常态化项目,做好流程规划把控,考虑可能影响项目实施的生产环境的变化因素,例如:接口变化影响测试实施,系统变化影响测试范围,系统应用组件变化造成数据污染,系统中间件变化造成测试链路变化。
前言 全链路压测从零开始系列的第一篇文章介绍了全链路压测的背景、定义、和传统压测的差异以及如何解决差异带来的不稳定性,落地要面临的挑战和完整的压测实践流程以及长期的能力建设演变,算是对全链路压测有了一个比较系统和全面的介绍 国内全链路压测的SaaS服务商,目前只有2家:数列科技和perfma。 ,就可以看到所有的服务调用关系,快速理解系统架构,并且通过链路架构图可以详细了解链路经过的应用、缓存、中间件、DB,甚至第三方的API,每条链路的所有走向都一目了然; 数据安全隔离:在不污染生产环境业务数据情况下进行全链路压测 总结 本篇主要对全链路压测的项目立项和调研环节要考量的点以及业内的一些方案&SaaS及开源产品做了介绍,下一篇开始,会介绍落地实践过程中具体要做的一些事情,包括工具选型、流量评估等,会结合具体的业务场景来为大家分享如何从零开始的落地全链路压测 建个一个学习群,关注回复全链路压测进群。
什么是全链路监控? 2、如何了解每一个应用的性能指标,并对系统容量进行合理的规划? 3、当系统出现故障或异常的时候,如何第一时间发现问题、定位问题、解决问题? 这3个关键诉求的核心挑战,都来源于应用之间复杂的链路。 ,为全链路监控提供了理论指导。 我们只需要知道,优秀的全链路监控组件会尽可能的遵循 OpenTracing 标准,以获得更好的通用性以及扩展性。 可选方案 ---- 全链路监控组件如何获得链路相关的信息呢? 构建多语言全链路监控体系 ---- 除了Java语言外,ARMS还提供了PHP探针,PHP应用接入ARMS后,能够拥有和Java应用同样的全链路监控体验。
面临的挑战 除了上面所说的技术层面的问题,要开展全链路压测,还面临如下的几点挑战: ①、由于全链路压测涉及的系统及场景较多,因此需要跨团队沟通、跨系统协调改造,公司体量 越大,这一点难度就越大; ②、全链路压测涉及的系统较多 不过全链路压测的优点也很明显,比如:优化联络薄弱环节可以提高系统的可用性,容量规划可 以节省成本,提高效率。 开展前的准备工作 在开展全链路压测之前,我们需要做哪些准备工作? 因此需要通过监控分析等手段,得到日常流量场 景、峰值流量场景下各系统的流量以及配比,进行一定的放大,来作为全链路压测的流量参考模 型; ④、数据处理:全链路压测通常在生产环境进行,所以防止数据污染是必须考虑的问题 要开展全链路压测,那么一个合理高效可用的压测管理平台,是很有必要的,参考了很多全链路 压测的设计思路,我个人的想法中全链路压测平台的架构设计,主要由以下几部分组成: ①、Controller:主要任务为压测任务分配 具体的架 构设计图,可参考京东的全链路军演系统ForceBot的架构设计,如下图: ? 完成了上面的工作,接下来就可以开展全链路压测的工作了。
何为全链路测试? 个人认为,链路可以分为业务链路和调用链路,调用链路主要指从请求发起方到结果返回所途径各种服务/中间件产生的路径,可以理解为单系统下的某一功能模块。 而业务链路则是多个业务关联的场景组合产生的链路调用集合,例如淘宝添加购物车->提交订单->支付这个场景,所以全链路必然包含多个业务关联场景涉及的调用链路。 全链路下自动化成本更高,因为全链路用例涉及到多域的流程编排,处理服务间各种异常重试情况(超时、网络异常), 各域的输出断言,这无疑大大增加一条用例开发成本。 综上,我们要正确看待全链路测试,不能迷信于全链路测试,觉得全链路测试通过就没啥问题了。 要知道,全链路测试更多从业务角度出发,不能覆盖所有潜在异常场景,二者可以相辅相成,但对于日常自动化回归,我认为做好域内测试自动化才是底盘,全链路自动化没什么必要!
目前,链路追踪组件有Google的Dapper,Twitter 的Zipkin,以及阿里的Eagleeye (鹰眼)等,它们都是非常优秀的链路追踪开源组件。 链路追踪(Dapper) 当业务程序代码在线上运行时,实例A、实例B、实例C,他们直接可能从上到下依次调用,为了能很好的监控程序的调用链路,我们需要对调用链路进行追踪监控。 测试结果:hi1 链路追踪:7dfd98e8-c474-461c-87b9-1da3bf6072c2 org.itstack.demo.test.ApiTest.http_lt2 测试结果:hi2 链路追踪 :7dfd98e8-c474-461c-87b9-1da3bf6072c2 org.itstack.demo.test.ApiTest.http_lt3 测试结果:hi3 链路追踪:69cdf9d3-1f42 5362dd7ea140 org.itstack.demo.test.ApiTest.http_lt2 测试结果:hi2 链路追踪:69cdf9d3-1f42-4cf6-8d80-5362dd7ea140
除此之外,Zuul还提供了全链路追踪的功能,通过在请求头中添加相关信息,可以跟踪一个请求从发起到响应的整个过程,帮助我们定位问题。 实现原理 在Zuul中实现全链路追踪需要用到Sleuth和Zipkin,Sleuth是Spring Cloud提供的用于生成和管理Trace Id的工具,而Zipkin是一个分布式跟踪系统,用于收集和查询 tracing表示开启全链路追踪功能,sleuth表示使用Sleuth进行Trace Id的生成和管理,web表示启用Web的相关配置,client表示启用Zuul作为客户端的相关配置。
全链路追踪系统就是为了解决微服务场景下的这些问题而诞生的。 一般在链路的入口应用中生成traceId和spanId,在后续的各节点调用中,traceId保持不变并全链路透传,各节点只产生自己的新的spanId。 六、总结与展望 全链路追踪系统包含几大部分:链路采集SDK、数据处理服务、用户产品。SDK部分比较偏技术。 用户产品主要考验的是设计者对用户需求的把握,全链路追踪可以做很多事情,产品上可以堆叠出很多功能,怎样能让用户快速上手,简洁而又易用是链路追踪产品设计的一大挑战。 未来一段时间,有赞全链路追踪会围绕以下几个方面继续演进: 赋能有赞云:给有赞云开发者用户提供有容器应用的链路追踪能力; 开源协议支持:数据模型与链路追踪API迁移到OpenTracing协议上,支持更多新语言的快速追踪
java/technologies/javase/javase7-archive-downloads.html#jdk-7u80-oth-JPR) apache-tomcat-8.0.36.tar.gz 2、 tomcat_pid() { echo `ps -fe | grep $CATALINA_BASE | grep -v grep | tr -s " "|cut -d" " -f2` 31mTomcat is not running\e[00m" fi return 0 } user_exists(){ if id -u $1 >/dev/null 2> 我在原本默认的端口前都加了2,下面是替换的shell命令 #【注意】最后一条是将tomcat的私有ip开放,需要将localhost替换成本机的ip,我本机的网卡是默认的,如果你本机的网卡不是eth0, tomcat_pid() { echo `ps -fe | grep $CATALINA_BASE | grep -v grep | tr -s " "|cut -d" " -f2`
上图是常见的微服务的框架,4 个实例,2 个 MySQL、1 个 Redis。 我们要拿到整个完整的链路,包括精确的响应时间,访问的方法、访问的 circle,访问的 Redis 的 key等,这些是我们在做分布式追踪的时候需要展现的一个完整的信息。 然后你的日志里会有 skywalking 调用链的 ID ,这个调用链的信息和这些日志是精确绑定的。 Skywalking 支持多种实现,目前提供是 H2 和 Elastic Search ,Elastic Search 主要用于生产 H2 。 也就是说当 A 应用调 B 应用的时候,即使 A、B 应用不属于同一个系统的监控,但是它们都有分布式链路的追踪能力,他们这个链路是有办法让大家串起来的。
2、OpenTelemetry可扩展性架构 OpenTelemetry 的可扩展架构意味着库/插件作者可以使用 API 仪器化他们的代码,当这些工件在实现 OpenTelemetry SDK 的服务或应用程序中使用时 2、采集器 OpenTelemetry Collector 是一个可选的中间代理,基于其,可以运行它来接收、处理和导出遥测数据。 以下是解决方案所采取的步骤,以及它在此过程中生成的数据: 1、使用 API 检测我们所构建的代码,告诉系统组件要收集哪些指标以及如何收集它们 2、使用 SDK 汇集数据,并将其传输以进行处理和导出 open-telemetry/oteps - 项目的增强建议 open-telemetry/opentelemetry-proto - OTLP 的 Protobuf 定义 2、