SOP思维导图 SOP的目的 从实践经验的角度出发,生产全链路压测在技术实现上没有太多新花样,但要在不同的业务和企业落地,就各有各的实践路径。 写这篇全链路压测SOP的目的,主要是基于如下几点因素考量: 阐述我对生产全链路压测的一些思考和认知; 提供一个全链路压测从零开始落地的实践路径; 提出落地过程遇到的问题和背后原因及我是如何解决的; 系列文章回顾 全链路压测(1):认识全链路压测 全链路压测(2):方案调研和项目立项 全链路压测(3):技术改造和测试验证 全链路压测(4):全链路压测的价值是什么? 全链路压测(5):生产全链路压测实施全流程 全链路压测(6):确认范围和识别风险 全链路压测(7):核心链路四问 全链路压测(8):构建三大模型 全链路压测(9):容量评估和容量规划 全链路压测(10) :测试要做的准备工作 全链路压测(11):聊聊稳定性预案 全链路压测(12):生产压测必不可少的环节 全链路压测(13):高可用和性能优化 再加上本篇的生产全链路压测SOP思维导图,就是整个系列的内容。
前言 前面的几篇文章从生产全链路压测的定义,内部立项和技术调研,聊到了测试验证以及全链路压测的对企业业务和技术团队的价值,算是整体上的构建一个认知的概念。 从这篇文章开始,会进入具体的落地实践环节。 这篇文章中,我会介绍生产全链路压测的落地实施全流程,即每个环节要做什么事情。 四大阶段 如果将生产全链路压测作为一个阶段性的技术项目来看,全链路压测从开始到项目结束,需要经过四个阶段。 整体的实施流程图如下所示: 接下来我来为大家解密,生产全链路压测落地实施,在不同的阶段都会做哪些事情。 核心业务定义 出问题会影响其他业务链路; 流量较高且出现问题会影响整体业务目标的达成; 核心项目定义 前面提到了生产全链路压测是个复杂的技术项目,那么如何定义这种技术项目呢? 文末回顾 本篇文章介绍了生产全链路压测落地实施的全流程,当然由于细节太多,很多内容无法描述的很清楚。部分事项为什么要这么做的原因,我会在后续的系列文章中一一为大家拆解和讲解。
生产环境全链路性能测试体系建设之路主要包括生产测试流程规范建设、生产测试工具平台建设、生产测试实施团队建设、落地实施细则。 生产环境测试实施团队建设为了达到质量共建的目的,加强各供应商质量共建意识,本文对生产测试项目的角色分工做详细介绍。 总结各个角色相应的职责,如下表所示生产环境测试的重点在实施环节,实施顺利与否关键在于各团队工作衔接是否顺利以及每个人的职责是否明确。 生产环境测试实施团队建设注意事项?在生产环境进行测试,尤其是涉及到关键业务系统时,团队建设与管理至关重要。以下是实施团队建设和管理的一些注意事项:明确目标和范围:确定测试的目标、预期结果以及成功标准。 通过遵循这些指导原则,可以帮助你建立一个高效的生产环境测试实施团队,从而提高测试的质量和成功率。阅读后若有收获,不吝关注,分享,评论留言等操作!!!
生产环境全链路性能测试体系建设之路主要包括生产测试流程规范建设、生产测试工具平台建设、生产测试实施团队建设、落地实施细则。 2)生产全链路性能测试体系规范落地阶段 首先,为保障生产测试安全高效,通过调研、评估、改造功能验证测试、试点、生产压测6大步骤,逐步完成生产全链路性能测试体系落地。 使用上,基于全链路压测平台,对探针部署、项目创建、目标制定、脚本编写、链路管理、场景执行、调优定位与分析、输出报告的整个项目实施流程进行培训。 原理上,介绍全链路压测平台的核心原理、数据流转情况、数据计算方式,帮助测试人员日常使用平台。最后,对平台培训进行结果验收考核。 最后,进行生产测试SOP培训。 调研核心链路系统的业务场景是否有生产环境测试需求,若没有生产测试需求,可在线下环境做性能测试验证;若有需求,对系统的技术架构进行调研,判断是否需要做到数据隔离,若不需要,可通过只读场景测试来实现,若需要
生产环境全链路性能测试体系建设之路主要包括生产测试流程规范建设、生产测试工具平台建设、生产测试实施团队建设、落地实施细则。 生产环境测试实施落地实施细则一、生产测试项目实施“六步“细节第一步,核心链路调研。本步主要目的是识别测试的核心链路,构造真实场景模型。 根据实际业务情况,通过Charles工具获得核心交易主链路接口,根据接口详情初步理涉及的业务应用服务。 此步骤涉及细节项包括核心接口的链路机理,识别每个接口的核心调用链路和链路上的远程调用、数据库调用、缓存调用、队列调用等信息,在全链路压测平台完成所有远程调用白名单、影子库、影子级存、影子队列等配置,并通过数据库在源库和影子库的落库情况确定影子流量业务功能的完整性和中间件改造的兼容性 在测试实施阶段,若被测服务是Java服务,则可以使用平台探针,利用平台做全链路监控和测试;若非Java服务,则利用内部的监控平台,做数据汇总。在结果产出阶段,对测试结果进行汇报和解读。
Takin是基于Java的开源系统,可以在无业务代码侵入的情况下,嵌入到各个应用程序节点,实现生产环境的全链路性能测试,适用于复杂的微服务架构系统。 局部性:传统性能测试有时会在生产环境的单一局部服务实施,或者只压测读类型的接口,但局部高可用不代表整体链路的高可用。 [Takin界面] 在生产环境进行性能压测是公认的最优解决方案,但这也是一件极具挑战性的事情,容易污染现网的数据库、日志等数据,进行生产环境测试数据清理时操作复杂且危险性高,为此,生产环境全链路压测技术应运而生 Takin作为首款生产环境全链路压测开源产品,可以较大程度地帮助企业降低生产全链路压测平台的开发复杂度,在无业务代码侵入的情况下,获得链路治理、数据隔离、性能瓶颈定位等生产压测核心能力。 三个部分各司其职,为业务提供无代码侵入的、常态化的生产环境全链路压测服务。
生产环境全链路性能测试体系建设之路主要包括生产测试流程规范建设、生产测试工具平台建设、生产测试实施团队建设、落地实施细则。本文主要聊一聊生产测试工具平台建设。 其中导出/导入规则是从应用维度全量导入或导出配置规则,启用/禁用规则是针对单条数据进行操作,不影响其他规则。有规则变更成功无须重启应用,但需发布变更才能生效。 三、链路分析平台具有链路分析能力,下面分别讲解平台上关于链路分析的配置项。首先是链路查询。它支持应用、实例、服务、请求结果、耗时、返回行数和开始时间等维度查询链路。其次是调用树。 四、工具平台服务化基于公司内的项目性能测试经验,提炼生产性能测试的阶段性工作的细节,形成指南和规范,各项目组根据业务需求可申请生产测试服务支持。 对于常态化项目,做好流程规划把控,考虑可能影响项目实施的生产环境的变化因素,例如:接口变化影响测试实施,系统变化影响测试范围,系统应用组件变化造成数据污染,系统中间件变化造成测试链路变化。
定义:如何理解全链路压测 PS:这里的定义是我基于自己对生产全链路压测的了解和实践总结得来的,仅代表个人观点。 1、什么是全链路压测? ; 数据流向问题:测试环境大多都是单接口单链路压测,数据流转性无法保证,数据多样性也存在部分问题; ---- 那么,要解决差异带来的不稳定因素,最终的选择就是生产全链路压测: 挑战:如何落地生产全链路压测 目前业内还没有较好的链路梳理工具,导致这个过程需要人肉来梳理,耗时且费力。 2、数据隔离 生产全链路压测最重要的一点是避免对生产数据造成污染。 流程:生产全链路压测落地实践 生产全链路压测的整个流程,大致可分为三个环节,每个环节的主要事项如下: 能力建设:生产压测能力演变历程 生产全链路压测的本质是能力建设的技术工程,不是一蹴而就。 7、生产全链路压测 通过上面几个步骤,从基础的能力建设、体系建设,到线上的监控能力、只读场景练兵以及数据隔离到试点验证,最终才能达到生产核心链路全链路压测的过程。
实施落地效果可以从3个方面介绍:质量数字化建设成果、生产全链路性能测试体系建设成果、线下测试体系建设成果。 一、质量数字化建设成果截至2023年6月份底,企业的特色性能测试体系初步建成,全链路压测平台接入供应商项目组超过20个,测试执行项目超过60个,脚本产出超过400个,场执行超过4000场。 二、生产全链路性能测试体系建设成果(1)核心链路场景测试效率提升首先,参照生产测试落地规范通过生产环境核心链路交易的多次测试,明确各个供应商在生产测试的职责边界,沉淀性能测试资产数据,使得测试周期从3周缩短到 最后,核心链路生产环境性能测试降本增效减少服务器资源成本投入,测试环境只使用生产环境的四分之一配置,复用生产环境进行测试,而不是搭建与生产环境等比配置的测试环境,减少硬件成本投入。 (2)生产测试服务化测试部门基于核心链路项目的测试,已沉淀和提供项目组相关指南及规划,目前和新业务项目组做持续优化探索中。三、线下测试体系建设成果测试团队进行性能测试有规范可以参考。
RpcID RPCId用链路调用顺序来递增。 阿里云相似产品:Tracing Analysis 效果图: ? image.png
--全链路跟踪 sleuth zipkin --> <dependency> <groupId>org.springframework.cloud</groupId
Zipkin是SpringCloud官方推荐的一款分布式链路监控的组件,使用它我们可以得知每一个请求所经过的节点以及耗时等信息,并且它对代码无任何侵入,我们先来看一下Zipkin给我们提供的UI界面都是提供了哪些信息 zipkin首页为我们提供了对于调用链路的搜索查询及展示的功能 ? 第二个选项卡里提供了历史数据的导入功能 ? 第三个选项卡里展示了各个微服务之间的关系 ? 我们再次回到首页,我们点开一个调用链路之后就会看到此次链路调用的详情 ? 现在我们点开详情中的一个service,可以看到此次调用在这个微服务中的详细信息。 ?
作者: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; 假设日常支付订单量为 文末回顾 这篇文章主要聊了全链路压测在备战阶段最重要的一件事,核心链路梳理。其中提到了流量模型相关的内容,下篇文章,我会以全链路压测过程中需要梳理的三大模型为主题,为大家介绍它们。
在开始真正的介绍落地实践过程以及相关案例之前,我想和大家聊聊,我对全链路压测的一些认知,即:全链路压测在技术团队中的定位,以及它的价值是什么。 业务和技术是什么关系? 生产环境全链路压测,就是目前业内的最佳实践。 硬件成本 前面聊到了容量评估和容量规划,这和硬件成本有什么关系呢?可能很多同学都不知道,现在的互联网企业,最大的成本支出都是哪些? 全链路压测对稳定性保障的价值 聊了这么多,回到文章顶部,我所要表达的内容,全链路压测的价值是什么? 通过生产全链路压测,可以串联稳定性保障的全流程,解决线上系统稳定性保障面临的种种挑战,它所带来的价值如下: 总结回顾 这篇文章介绍了我对技术和业务关系的理解,线上稳定性保障面临的挑战以及全链路压测在其中的价值 ,通过前面的几篇文章,从认识全链路压测到项目立项以及技术调研和测试验证,我试图从另一个视角来为大家揭秘全链路压测的另一面。
前言 全链路压测系列到这里,已经是第十二篇文章了,整个系列大概有14篇的样子,预计这个月会更新完毕。 因为全链路压测严格来讲,并不是一个单纯的测试手段,而是一整套团队协作和稳定性保障的技术体系。 当然,这个系列文章叫做叫做生产全链路压测,那肯定少不了在线上生产环境的压测实践。 这篇文章,为大家介绍下在生产环境都是如何开展压测的,以及压测过程要注意哪些事项。 在生产环境开展全链路压测,相对于测试环境来说风险和成本都是比较大的。 当然,由于成本和风险问题,全链路压测本身只适合部分企业,而非一个放之全行业通用的技术银弹。即使在少部分落地了生产全链路压测的企业来说,常态化的全链路压测也是很难的。 下面是一个在电商企业双11大促时候的生产全链路压测实施过程,仅做示例参考。 执行压测和问题处理 生产压测其实和我们日常的压测没有太多区别,也是需要经过多轮的压测实施和问题分析定位优化才能完成。
oraclejdk-docker-image 2.oraclejdk-skywalking-docker-image 3.apollo-skywalking-pro镜像 (4).apollo&skywalking生产级容器化 -6:skywalking-6.4.0生产级别容器化 2.阿里云&kubernetes&微服务生产实践-1:apollo架构-1 (2).前置说明 本例相对于官方做了如下几处改动: 1.修改基础镜像为oracle-jdk 2.基础镜像增加skywalking-agent的支持,通过configmap中的配置参数来决定在启动apollo服务的时候是否开启链路追踪。 (4).apollo&skywalking生产级容器化 笔者提供生产级的配置文件,位于: https://github.com/hepyu/k8s-app-config/tree/master/product /standard/apollo-skywalking-pro 注意本例配置中pv默认是本地存储,生产环境需要改为云存储。
3.2 重复造轮子 目前榜单商品生产链路强依赖搜索,由搜索实现商品圈选及排序,搜索榜单商品生产方式单一,无法满足榜单圈选/排序规则定制化供给。 4.技术实施点 整体改造将分为两个阶段进行:首先完成链路改造,即榜单生产迁移捞月,待数据验证通过进行第二阶段的存储改造,即B/C端数据存储隔离。 首先根据B/C查询场景划分为正向链路和反向链路。正向链路,也就是从榜单id获取到捞月集id,从捞月es根据捞月集id获取捞月商品结果集,B端查询方式均为正向链路,因此可以复用捞月存储结构。 这一步执行的节点十分关键,需放在链路改造完成,存储改造开始之前进行。 具体灰度切流推进流程如下: 经历两个星期的灰度,已移除对搜索的依赖实现全链路闭环,依照灰度方案通过切流开关及预案等手段确保“随切随停”,上线期间零故障。
3.2 重复造轮子 目前榜单商品生产链路强依赖搜索,由搜索实现商品圈选及排序,搜索榜单商品生产方式单一,无法满足榜单圈选/排序规则定制化供给。 4.技术实施点 整体改造将分为两个阶段进行:首先完成链路改造,即榜单生产迁移捞月,待数据验证通过进行第二阶段的存储改造,即B/C端数据存储隔离。 首先根据B/C查询场景划分为正向链路和反向链路。正向链路,也就是从榜单id获取到捞月集id,从捞月es根据捞月集id获取捞月商品结果集,B端查询方式均为正向链路,因此可以复用捞月存储结构。 这一步执行的节点十分关键,需放在链路改造完成,存储改造开始之前进行。 具体灰度切流推进流程如下: 经历两个星期的灰度,已移除对搜索的依赖实现全链路闭环,依照灰度方案通过切流开关及预案等手段确保“随切随停”,上线期间零故障。
什么是全链路监控? 图:Jaeger技术架构 最轻松的方案 ---- 开源的全链路监控方案能帮助开发者更深入的理解全链路监控的思想、原理以技术细节,但在在生产环境大规模使用开源方案,还是会给开发者带来很大的挑战: 维护工作复杂 之所以在生产环境使用开源全链路监控方案存在这么大挑战,是因为这些方案本身缺乏大规模实际业务场景的验证。 正是因为经历了大规模生产环境的长期验证,才使 ARMS 能够在易用性、功能性、稳定性方面做到极致,以开源领域最活跃的全链路监控项目 Skywalking 为例,我们可以从多个维度对两个产品进行对比: 对比维度 我们不妨从现在开始,就将所有微服务应用通过无侵入的方式接入ARMS,构建一体化的全链路监控体系,而不是等到真正遇到生产故障的那一天,为了定位问题而费尽周折。