- 综合排序
- 最热优先
- 最新优先
- 来自专栏7DGroup
架构级全链路性能咨询服务
实施此方案的特点是： 切中企业中的性能管理、性能实施的当前问题； 完整分析企业中的实际性能项目； 现场分析问题、解决问题； 如有需求，请联系我。
49020发布于 2019-07-17 - 来自专栏devops
【架构实战】全链路压测实战与架构优化
为什么需要压测性能测试是验证系统能力的重要手段，但很多时候我们发现：上线前测试通过，上线后扛不住单接口压测没问题，混合场景就崩了压测时好好的，大促时各种异常根本原因：测试环境与生产环境差异大单接口压测无法模拟真实业务场景缺乏全链路压测 ，无法发现系统短板全链路压测的目标：验证系统在高并发下的稳定性发现性能瓶颈和隐患确定系统容量边界为扩容和优化提供数据支撑二、压测类型与目标1.压测类型分类类型说明目的基准测试单接口压测获取单个接口性能基线负载测试逐步加压找到最大处理能力压力测试持续高压测试系统极限容量测试持续运行验证长时间稳定性全链路测试端到端压测模拟真实业务场景 .工具选型建议场景推荐工具理由快速单接口压测wrk轻量快速复杂业务流程JMeter/Gatling支持脚本编程大规模分布式压测JMeter成熟的分布式方案CI/CD集成Gatling代码化，易集成四、全链路压测实施 1.数据库优化连接池配置（HikariCP）：最大连接数：50最小空闲连接：20连接超时：3秒SQL优化：添加适当索引避免全表扫描使用分页查询2.缓存优化多级缓存架构：L1：本地缓存（Caffeine） ：指标目标值实际值结论QPS1000012000达标P99响应时间小于500ms380ms达标错误率小于0.1%0.02%达标容量规划公式所需服务器数=目标QPS/单机QPSx(1+冗余比例)八、总结全链路压测是保障系统稳定性的重要手段
17500编辑于 2026-04-01 - 来自专栏老张的求知思考世界
全链路压测(1)：认识全链路压测
前言 之前断断续续写过一些全链路压测相关的技术文章，很多同学评价还不错。朋友建议我写个系列，基于自己的落地实践经验，对全链路压测做个系统性的梳理总结。 定义：如何理解全链路压测 PS：这里的定义是我基于自己对生产全链路压测的了解和实践总结得来的，仅代表个人观点。 1、什么是全链路压测？ ，数据流转性无法保证，数据多样性也存在部分问题； ---- 那么，要解决差异带来的不稳定因素，最终的选择就是生产全链路压测： 挑战：如何落地生产全链路压测 虽然全链路压测解决了传统压测过程中的种种痛点 但在落地过程中，全链路压测依然要解决很多问题，主要有如下几点挑战： 1、链路梳理 现在大多数企业都是采用微服务架构来设计系统，且业务场景多样化，导致了系统架构异常复杂。 流程：生产全链路压测落地实践 生产全链路压测的整个流程，大致可分为三个环节，每个环节的主要事项如下： 能力建设：生产压测能力演变历程 生产全链路压测的本质是能力建设的技术工程，不是一蹴而就。
3.6K30发布于 2021-10-14 - 来自专栏老张的求知思考世界
全链路压测(5)：生产全链路压测实施全流程
前言 前面的几篇文章从生产全链路压测的定义，内部立项和技术调研，聊到了测试验证以及全链路压测的对企业业务和技术团队的价值，算是整体上的构建一个认知的概念。 从这篇文章开始，会进入具体的落地实践环节。 这篇文章中，我会介绍生产全链路压测的落地实施全流程，即每个环节要做什么事情。 四大阶段 如果将生产全链路压测作为一个阶段性的技术项目来看，全链路压测从开始到项目结束，需要经过四个阶段。 整体的实施流程图如下所示： 接下来我来为大家解密，生产全链路压测落地实施，在不同的阶段都会做哪些事情。 筹备阶段 确定业务范围 一般来说线上实施线上全链路压测之前，要明确本次压测需要验证的业务范围。 核心业务定义 出问题会影响其他业务链路； 流量较高且出现问题会影响整体业务目标的达成； 核心项目定义 前面提到了生产全链路压测是个复杂的技术项目，那么如何定义这种技术项目呢？
2K40编辑于 2022-04-01 - 来自专栏老张的求知思考世界
全链路压测(14)：生产全链路压测SOP
——来自百度百科 本篇文章要说的全链路压测SOP，实际上就是我在实践全链路压测的过程中，对实践经验和教训的一个总结。 全链路压测(1)：认识全链路压测 全链路压测(2)：方案调研和项目立项 全链路压测(3)：技术改造和测试验证 全链路压测(4)：全链路压测的价值是什么？ 全链路压测(5)：生产全链路压测实施全流程 全链路压测(6)：确认范围和识别风险 全链路压测(7)：核心链路四问 全链路压测(8)：构建三大模型 全链路压测(9)：容量评估和容量规划 全链路压测(10) ：测试要做的准备工作 全链路压测(11)：聊聊稳定性预案 全链路压测(12)：生产压测必不可少的环节 全链路压测(13)：高可用和性能优化 再加上本篇的生产全链路压测SOP思维导图，就是整个系列的内容。 最后，重申一下我对全链路压测的部分认知： 全链路压测是一个技术工程，而非单纯的测试手段； 全链路压测只适用于部分企业和业务类型，而非一个银弹； 全链路压测的落地并非一蹴而就，需要较好的技术基础设施建设做保障
1K10编辑于 2022-09-02 - 来自专栏D·技术专栏
EagleEye全链路追踪
RpcID RPCId用链路调用顺序来递增。 阿里云相似产品：Tracing Analysis 效果图： ? image.png
4K10发布于 2020-02-13 - 来自专栏OSChina
全链路跟踪zipkin
--全链路跟踪 sleuth zipkin --> <dependency> <groupId>org.springframework.cloud</groupId
78620发布于 2020-04-24 - 来自专栏vivo互联网技术
Node.js 应用全链路追踪技术——全链路信息存储
作者：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 应用全链路追踪技术——全链路信息获取》 文章中，已经详细阐述了，如何去获取全链路信息。
1.2K50编辑于 2023-02-06 - 来自专栏Java学习录
Zipkin全链路监控
Zipkin是SpringCloud官方推荐的一款分布式链路监控的组件，使用它我们可以得知每一个请求所经过的节点以及耗时等信息，并且它对代码无任何侵入，我们先来看一下Zipkin给我们提供的UI界面都是提供了哪些信息 zipkin首页为我们提供了对于调用链路的搜索查询及展示的功能 ? 第二个选项卡里提供了历史数据的导入功能 ? 第三个选项卡里展示了各个微服务之间的关系 ? 我们再次回到首页，我们点开一个调用链路之后就会看到此次链路调用的详情 ? 现在我们点开详情中的一个service，可以看到此次调用在这个微服务中的详细信息。 ?
3.7K00发布于 2019-04-18 实时云渲染平台的全链路技术架构解析
本文将围绕实时云渲染的系统架构展开讨论，重点分析其从云端渲染、网络传输到终端适配的全链路技术实现，并探讨该架构在不同行业场景中的应用潜力。 为解决上述问题，新一代实时云渲染平台逐步形成，其核心特征是实现从底层资源调度到上层应用管理的全栈集成。 二、全链路技术架构的关键环节实时云渲染系统的性能与体验，依赖于“云端渲染–网络传输–终端适配”三个环节的深度协同与优化。 通过优化帧捕获、编码、传输与解码全链路，可将端到端的视频流处理延迟控制在较低水平。在弱网环境下，系统能通过动态调整码率与画质策略，优先保障流畅性，从而维持稳定的操作体验。 通过全链路的技术优化与生态兼容，该架构在数字孪生、远程协作、云游戏等场景中展现出广泛的应用潜力。
30920编辑于 2025-12-31- 来自专栏王清培的专栏
微服务架构—自动化测试全链路设计
SPI 初步实现 Mock 总结 背景 从 SOA 架构到现在大行其道的微服务架构，系统越拆越小，整体架构的复杂度也是直线上升，我们一直老生常谈的微服务架构下的技术难点及解决方案也日渐成熟（包括典型的数据一致性 文章接下来的部分将展开 marketing-cloud 规则引擎 在打通测试链路上的实践。 但是有一块我们一直没有重视的就是 全链路压力测试 这块，在生产上进行全链路的真实的压力测试需要解决很多问题，比较重要的就是 DB 这块，压测的时候产生的所有交易数据不能够参与结算、财务流程，这就需要借助 当然还有其他地方都需要解决，一旦打开全链路压测开关，应该需要处理所有产生数据的地方，这是一个庞大的工程，但是也会非常有意思。 本篇文章只是我们在这块的一个初步尝试，我们会继续扩展下去，在下次产线全链路压测的时候我们就可以借助现在的实践架构扩展起来。 作者：王清培 （沪江集团资深JAVA架构师）
1.6K10发布于 2018-07-31 - 来自专栏架构随笔录
架构师——复盘落地全链路监控项目
1、如何技术选型，应该是架构师必须具备的技能 技术预研 技术调研 项目风险模型 2、场景项目（全链路监控） 2.1 项目背景 调研某公司的技术研发团队的现状： 监控埋点项目太多，不统一 业务稳定性凝聚力不够 2.2.2 Lightstep Lightstep全链路解决方案非常完整，整体解决方案和微服务架构生态完美的匹配，如果技术栈匹配，可以开箱即用，维护一个稳定的基线版本，Lightstep学习成本较高，可以复用 Lightstep的架构思想，自研全链路框架。 某一个里程碑版本，维护起来，并架构演化为自研链路框架。 推广阶段： 全链路知识体系普及分享，讲解全链路项目的优势以及能够解决的业务痛点； 全链路接入方案和部署方案讲解，接入和部署透明化，让业务知道可能存在的风险点 ； 链路压测报告输出，并同步给各个部门leader
1.8K30编辑于 2022-09-23 - 来自专栏老张的求知思考世界
全链路压测(7)：核心链路四问
前言 前面的文章介绍了全链路压测的落地实施全流程，其中有个环节我特别提到了它的重要性，同时这也是本篇文章的主题：核心链路梳理。那什么是核心链路？为什么要确定核心链路？如何进行核心链路梳理？ 以电商企业为例，为用户提供商品的购买服务，为商家提供商品的管理和上架及定价展示，利润大多为撮合用户和商家交易所带来的服务费以及广告等相关费用。 这么说比较拗口，再直白一些就是：哪些接口会影响用户下单支付，哪些就是核心链路。 下面附一个常见的电商企业核心链路流程图，供大家参考。 为什么要确定核心链路？ 流量模型 我在前面的文章《生产全链路压测实施全流程》中有提高转化技术指标的一个案例，这里再次回顾下： 客单价为500，单日GMV为10亿，那么支付订单量为10亿/500=200W； 假设日常支付订单量为 文末回顾 这篇文章主要聊了全链路压测在备战阶段最重要的一件事，核心链路梳理。其中提到了流量模型相关的内容，下篇文章，我会以全链路压测过程中需要梳理的三大模型为主题，为大家介绍它们。
1.9K21编辑于 2022-04-01 - 来自专栏老张的求知思考世界
全链路压测(4)：全链路压测的价值是什么？
在开始真正的介绍落地实践过程以及相关案例之前，我想和大家聊聊，我对全链路压测的一些认知，即：全链路压测在技术团队中的定位，以及它的价值是什么。 业务和技术是什么关系？ 全链路压测对稳定性保障的价值 聊了这么多，回到文章顶部，我所要表达的内容，全链路压测的价值是什么？ 通过生产全链路压测，可以串联稳定性保障的全流程，解决线上系统稳定性保障面临的种种挑战，它所带来的价值如下： 总结回顾 这篇文章介绍了我对技术和业务关系的理解，线上稳定性保障面临的挑战以及全链路压测在其中的价值 ，通过前面的几篇文章，从认识全链路压测到项目立项以及技术调研和测试验证，我试图从另一个视角来为大家揭秘全链路压测的另一面。 下篇文章，我会为大家介绍，全链路压测落地实践的整体流程。
1.6K20编辑于 2022-01-25 - 来自专栏肉眼品世界
轻松玩转全链路监控
OpenTracing 抽象出一套与编程语言以及业务逻辑无关的接口，对链路追踪领域各类元素的统一管理，从而实现完整的全链路监控。 图：Jaeger技术架构 最轻松的方案 ---- 开源的全链路监控方案能帮助开发者更深入的理解全链路监控的思想、原理以技术细节，但在在生产环境大规模使用开源方案，还是会给开发者带来很大的挑战： 维护工作复杂 有没有一套经历过大规模实际业务场景验证，又简单易用的全链路监控产品呢？在云计算时代这个问题的答案是肯定的，阿里云ARMS就能满足这个要求，代表着业界在全链路监控以及应用性能管理领域的最高水平。 ? 受益于统一的全链路监控模型，如果一个微服务体系中存在多种语言之间的相互调用，只要把对应的应用都接入ARMS，就能够跨越多语言对调用链路进行统一的管理和分析。 ? ，作为全链路监控以及应用性能管理领域的标杆产品，ARMS还有更多的功能特性等待着我们去挖掘，我们可以对照帮助文档逐步学习。
1.9K11发布于 2020-12-07 - 来自专栏测试开发架构之路
全链路测试不是银弹
与单体的复杂系统不同，开发者需要开发和管理一系列相对简单的服务，而这些服务可能以一些复杂的方式交互。 何为全链路测试？ 个人认为，链路可以分为业务链路和调用链路，调用链路主要指从请求发起方到结果返回所途径各种服务/中间件产生的路径，可以理解为单系统下的某一功能模块。 而业务链路则是多个业务关联的场景组合产生的链路调用集合，例如淘宝添加购物车->提交订单->支付这个场景，所以全链路必然包含多个业务关联场景涉及的调用链路。 全链路下自动化成本更高，因为全链路用例涉及到多域的流程编排，处理服务间各种异常重试情况（超时、网络异常）， 各域的输出断言，这无疑大大增加一条用例开发成本。 综上，我们要正确看待全链路测试，不能迷信于全链路测试，觉得全链路测试通过就没啥问题了。
56930编辑于 2022-08-01 - 来自专栏老张的求知思考世界
再谈全链路压测
面临的挑战 除了上面所说的技术层面的问题，要开展全链路压测，还面临如下的几点挑战： ①、由于全链路压测涉及的系统及场景较多，因此需要跨团队沟通、跨系统协调改造，公司体量 越大，这一点难度就越大； ②、全链路压测涉及的系统较多 ，且不同的系统架构也有所不同，因此需要考虑：机房管理、基 础网络、DB管理、持久存储、中间件、应用部署、流量接入、监控与运维保障等多方面； ③、全链路压测的目的是找到系统调用链路薄弱环节并优化，这就要求对整个调用链路涉及的系 ，都需要及时且可视化的获取到系统的状态变 化，方便及时排查定位问题，也避免压测对正常的服务造成干扰； 监控的重点，主要是对应服务的TPS、不同百分比的RT、成功率、资源耗用、服务状态、告警等 信息； 全链路压测平台架构设计 要开展全链路压测，那么一个合理高效可用的压测管理平台，是很有必要的，参考了很多全链路 压测的设计思路，我个人的想法中全链路压测平台的架构设计，主要由以下几部分组成： ①、Controller：主要任务为压测任务分配 具体的架 构设计图，可参考京东的全链路军演系统ForceBot的架构设计，如下图： ? 完成了上面的工作，接下来就可以开展全链路压测的工作了。
90610发布于 2019-12-02 - 来自专栏CodeGuide | 程序员编码指南
基于JavaAgent的全链路监控五《ThreadLocal链路追踪》
案例简述 Google开源的Dapper链路追踪组件，并在2010年发表了论文《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure 》，这篇文章是业内实现链路追踪的标杆和理论基础，具有非常大的参考价值。 目前，链路追踪组件有Google的Dapper，Twitter 的Zipkin，以及阿里的Eagleeye （鹰眼）等，它们都是非常优秀的链路追踪开源组件。 链路追踪(Dapper) 当业务程序代码在线上运行时，实例A、实例B、实例C，他们直接可能从上到下依次调用，为了能很好的监控程序的调用链路，我们需要对调用链路进行追踪监控。 测试结果：hi1 链路追踪：7dfd98e8-c474-461c-87b9-1da3bf6072c2 org.itstack.demo.test.ApiTest.http_lt2 测试结果：hi2 链路追踪
2.7K20发布于 2020-07-14 - 来自专栏腾讯云中间件的专栏
云原生专场分享：微服务架构下的全链路追踪
徐为 腾讯云微服务团队高级解决方案构架师 毕业于欧盟 Erasmus Mundus IMMIT，获得经济和IT管理硕士学位 自2006年以来，曾就职于SonyEricsson、SAP、Alibaba Cloud 等多家公司，历任软件开发工程师，数据开发工程师，解决方案架构师 ---- 可不可以悄悄透露一下议题内容~ 企业级业务系统日趋复杂，微服务架构逐渐成为了许多中大型企业的标配，它将庞大的单体应用拆分成多个子系统和公共的组件单元 与此同时，微服务架构也带来了新的问题：系统排查问题难定位，运维难度系数高。为了解决这些问题，全链路追踪应运而生。 关于微服务及全链路追踪你有哪些看法呢？ 哪些云原生案例让你眼前一新呢？
63520发布于 2021-03-24 - 来自专栏飞鸟的专栏
使用Zuul实现全链路追踪
除此之外，Zuul还提供了全链路追踪的功能，通过在请求头中添加相关信息，可以跟踪一个请求从发起到响应的整个过程，帮助我们定位问题。 实现原理 在Zuul中实现全链路追踪需要用到Sleuth和Zipkin，Sleuth是Spring Cloud提供的用于生成和管理Trace Id的工具，而Zipkin是一个分布式跟踪系统，用于收集和查询 tracing表示开启全链路追踪功能，sleuth表示使用Sleuth进行Trace Id的生成和管理，web表示启用Web的相关配置，client表示启用Zuul作为客户端的相关配置。
95420编辑于 2023-04-10
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号