- 博客(388)
- 收藏
- 关注
RSS订阅原创 全链路压测标记透传落地实战：数据上下文设计与Sleuth Baggage的完整改造方案
利用 Sleuth 原生的 Span Baggage 机制，在网关 Filter 中将压测标记写入 Baggage，下游服务通过 Baggage 读取，无需修改业务代码。两者组合的完整流程：请求到达网关 → Filter 提取 Header 中的压测标记 → 写入 Span Baggage + 存入 AppContext → 下游服务通过 Baggage 或 AppContext 读取标记 → 区分压测流量与正常流量。
2026-05-05 14:19:00
227
原创 全链路压测标记透传选型：ThreadLocal演进路径与五种跨服务方案的对比决策
但线程池会复用线程，复用的线程在创建时已经完成了变量复制，后续提交的任务拿到的是旧线程的变量值，而非当前父线程的值。模拟 10 个并发请求向线程池提交任务时，子线程输出的父线程名称与 index 无法一一对应——这在全链路压测中是致命的，会导致压测标记错乱。### TransmittableThreadLocal（TTL）：线程池场景的完整解决方案阿里开源的 TTL 在提交任务到线程池时，将当前父线程的变量值快照传递给子任务，而不是依赖线程创建时的复制。：跨线程透传直接选 TTL，跳过前两个方案。
2026-05-05 14:14:42
368
原创 【无标题】
Brave 库对常见组件的支持情况如下：| 组件 | 支持方式 | 依赖 ||------|---------|------|| SpringMVC / Feign / Logback | 自动配置，引入 Sleuth + Zipkin 依赖即可 ||| Spring Cloud Gateway | 原生支持（基于 WebFlux instrument/web 模块） | 同上 || MySQL 8 | Brave 插件拦截 SQL |—## 二、MySQL 链路追踪的关键配置MySQL 链路追踪通过。
2026-05-03 17:36:25
61
原创 【无标题】
改造完成后，可以在 Zipkin UI 中直接看到每个请求的完整调用链，包括各服务间调用耗时、数据库查询耗时、缓存访问耗时，以及压测流量与正常流量的区分标记。以电商下单为例，完整链路涉及会员服务、认证中心、订单服务、购物车服务的逐级调用，每个服务可能由不同团队开发，部署在成百上千台服务器上。分布式链路追踪的核心功能是：在运行时记录各服务间的调用过程，通过可视化 UI 展示完整调用链，使性能分析人员能够直接看到一个请求在每一段的耗时——包括服务间调用、Redis 访问、MySQL 查询等各个环节。
2026-05-03 17:26:06
156
原创 【无标题】
全链路压测涉及业务团队、架构团队、开发团队、运维团队等多个团队，需要提前明确各模块的值班人员，确保在给定时间点能够联调和值守，出现问题时各模块负责人能快速响应。：在正式压测前，将容量场景中涉及的所有业务接口提前跑一遍，让缓存数据加载、线程池和连接池完成资源分配。：执行初期只上全局监控（覆盖性能分析决策树第一层计数器，如 CPU、磁盘、网络基础指标），发现问题后重复执行场景，再上定向监控（针对具体异常计数器深入分析）。全链路压测的场景分为四类：基准场景、容量场景、稳定性场景、异常场景，没有其他类型。
2026-05-03 17:17:38
157
原创 【无标题】
性能项目中的模型可以归纳为五类：业务模型、容量模型、监控模型、分析模型、异常（失效）模型。五个模型各自解决不同的问题：- 业务模型：确定压力工具中的业务比例配置- 容量模型：确定系统设计容量的计算方式- 监控模型：确定需要监控的计数器范围- 分析模型：确定性能问题的分析路径- 异常模型：确定异常场景的设计方式全链路压测与普通压测在模型分类上没有区别，主要差异是：由于全链路压测在线上执行，对微服务、缓存、队列、数据库做了改造（影子库等），每个模型都需要额外覆盖改造后新增的组件。
2026-05-03 17:14:48
169
原创 全链路压测的环境复杂性：网络架构、应用架构与性能影响因素全解析
## 六、实践建议对于不同规模的项目，环境策略的选择有所不同：规模较小的 ToB 项目，可以搭建核心链路的缩比镜像环境，通过单副本容量测试 + 扩展性测试推算生产容量，但需要额外做横向扩展验证，确认容量是否线性增长。—## 五、线下镜像环境的挑战与线上压测的必要性线下镜像环境需要完整复制：网络拓扑（包括各层网络设备、防火墙、公网出入口）、基础资源（服务器、存储）、应用架构（所有服务及其依赖）、网络带宽，以及全量铺底数据。：需要跨开发、运维、网络、安全等几乎所有相关部门，协调周期长，执行难度高。
2026-05-03 17:12:05
444
原创 【无标题】
构建决策树时有几个注意点：- CPU 是综合资源，不单独作为模块，但在进程监控中必然覆盖- Swap 通常在性能项目中关闭，但仍需在决策树中标记，避免遗漏- 需要关联分析的计数器之间画出关联线，方便后续分析时建立联系—## 四、全局监控：将决策树中的计数器全部覆盖全局监控的目标是：决策树中标记为重要的计数器，在监控工具中都要有对应的采集项。—## 三、性能分析决策树：从技术栈到全量计数器性能分析决策树的作用是：将技术栈中的每个组件，逐层细化到具体的性能计数器，形成完整的监控指标清单。，三层递进，逐步细化。
2026-05-03 17:09:13
281
原创 全链路压测流量平台选型：三种构造方式的对比与工具决策框架
选型时还需要关注以下技术指标：压力控制（流量倍数、TPS 控制）、数据驱动（大量测试数据的参数化手段）、分布式支持（是否支持压力机集群）、测试报告（图形化展示能力）、性能开销（执行机资源消耗、执行效率）。实际上，流量回放相比流量模拟，在成本和复杂度上并不会减少——录制的流量必须能覆盖全链路压测的所有业务场景，这本身就需要仔细验证，并不比统计业务模型更简单。有条件的企业可以搭建 1:1 镜像环境，没有条件的也可以通过线上线下容量换算来解决，需要根据自身系统的部署架构复杂度做判断，而不是一律将压测搬到线上。
2026-05-03 17:06:44
310
原创 全链路压测铺底数据：从表链路追踪到数据脱敏的完整方法论
对于一个典型电商系统，压测链路通常涉及以下表：用户表、用户地址表、商品表、库存表、购物车表、订单表。如果没有代码权限，可以让研发梳理接口与表的关系，并告知压测时间节点和各表的铺底数据量级，由研发提前做好数据备份。—## 三、数据脱敏：生产数据导入前的必要处理生产数据是铺底数据最可靠的来源，但用户名、手机号、银行账号、身份证号、详细地址等敏感字段必须脱敏后才能使用，否则构成重大信息安全事故。—## 二、表链路追踪：找到压测涉及的所有表准备铺底数据的第一步是确定压测链路涉及哪些数据库表。
2026-05-03 17:04:08
384
原创 从架构视角梳理全链路压测的核心业务链路
全链路压测的有效性，很大程度上取决于链路梳理的准确性。链路梳理不准确，压测结果就无法真实反映系统整体的性能状态，后续的监控设计、场景设计、性能分析都会失去方向。链路梳理需要从架构视角出发，而不是从代码细节出发。一线技术人员容易陷入代码细节，丧失全局观。架构视角能清楚地描述服务之间的调用关系，以及每个业务接口涉及的技术组件范围。
2026-05-03 16:53:53
249
原创 一份真正有价值的全链路压测方案应该包含什么
压测方案是全链路压测项目中最容易被忽视、但实际上最重要的文档。它不是走流程的形式文件，而是整个项目实施的指导依据，直接决定后续环境准备、场景执行、分析报告的质量。一个完整的全链路压测方案必须覆盖以下内容：压测目标、压测范围、启停准则、性能指标、系统架构图（逻辑架构+部署架构）、系统改造方案、场景设计、监控设计、组织架构、风险分析、成果输出要求。缺少任何一项，都会在后续执行中产生问题。
2026-05-03 16:52:56
346
原创 RESAR性能工程如何覆盖全链路压测的完整流程
全链路压测不是一套独立的方法论，它是性能容量场景中的一个具体落地案例，完全在 RESAR 性能工程的框架范围之内。。全链路压测在这五个部分中都有对应的工作内容，只是某些环节的工作量和复杂度更高。这五个部分不是严格的时序关系，而是对一个完整性能项目必须覆盖的维度的描述。无论采用瀑布模型、敏捷还是 DevOps，这五个部分都必须做到，否则性能项目的结果就是不可控的。
2026-03-26 10:26:28
336
原创 全链路压测的认知误区与落地前提
全链路压测的出现，根本原因是微服务分布式架构的普及带来了容量评估方式的根本性变化。在 SOA 架构时代，服务通过 ESB 调用，链路短，单系统压测基本能反映容量。进入微服务时代后，服务被拆得越来越细，一个业务操作需要跨多个系统，调用链路大幅变长。这时，单系统压测的结果无法说明整体业务容量，"全链路"的概念才变得重要。。其他差异（压力场景、铺底数据、监控手段）都可以通过投入来平衡。
2026-03-26 10:23:58
282
原创 全链路压测开篇：打破神话做接地气的性能工程
网络上关于全链路压测的文章，大多来自阿里、美团、滴滴、字节等大厂，但这些资料普遍存在几个共同问题：目标和方案只有摘要级说明；全链路压测平台的细节描述宽泛；没有架构级改造的完整细节；没有监控平台覆盖范围的说明；没有性能分析逻辑的描述；也没有真实的人员、资金、时间成本数据。这造成了一个典型的落地困境：管理者看到大厂效果就安排任务，执行层因为缺乏管理权限、成本计算能力和技术细节实现能力，越做越觉得坑太大。
2026-03-26 10:21:33
467
原创 测试工序如何成为团队认知对齐的核心抓手
认知分歧无法消除，但可以通过建立认知基线来管理。对于开发团队而言，拉齐认知基线最有效的工具是测试工序。测试工序由架构和测试策略共同推导而来，代表了开发过程中不同的任务种类。在给定的架构与测试策略下，测试工序的数量是有限的。以典型的三层架构为例，测试工序包括：使用 Fake 数据库测试持久化层组件、通过 Stub 持久化层测试应用逻辑层、通过 Stub 应用逻辑层测试 HTTP 接口层、使用独立测试数据库做三层功能测试。能否按照测试工序准确拆分任务，以及能否掌握每一个测试工序的实施方法。
2026-03-26 10:19:11
393
原创 团队认知分歧的本质与理想认知行为模式
不完全胜任的成员处于复杂模式：先探测（spike 一下不清楚的地方），再感知（根据结果重新理解整张卡），再响应（逐步试错完成）。敏捷社区的 spike 实践就是这个思路：遇到解决方案不清楚的情况，停下手头工作，通知团队存在瓶颈，给定探索时间上限，超时立即止损（换人、寻找外援）。在无序状态的管理上，遇到不确定的技术问题，立即启动 spike，通知团队，设定时间上限，超时止损。理想模式不是静态的，团队成员的认知水平会变化，项目本身也会演进，需要有机制持续拉齐认知基线。，因为无序状态下时间是不可控的。
2026-03-26 10:17:35
336
原创 从复杂到庞杂：一个老码农用TDD结合LLM的探索心得
作者是一名工龄 20+ 的嵌入式软件工程师，在探索 GitHub Copilot 结合 TDD 的过程中，总结出一套注释型提示词模板。用例命名采用"验证什么结果，通过做什么动作（verifyWhatResult_byDoWhatAction）"的句式，如。按这个模板写完整注释后，Copilot 能生成约 80% 的测试代码。，相当于告诉模型"参考答案在哪里"，生成质量会直线上升。
2026-03-25 23:54:33
202
原创 LLM时代框架与工具的价值重估：知识复用还是载体复用
在 LLM 出现之前，复用知识的主要形式是框架和工具。使用 React、Spring Boot 这类框架，本质上是在复用凝聚在框架中的知识。从认知行为模式来看，熟练使用框架时处于——按照框架提供的思路解决具体问题；使用工具性质的库则更接近——按照问题选取对应工具。过去我们无法直接复用知识，只能通过知识的载体——软件——来复用。这是框架和工具存在的根本原因。LLM 改变了这一前提：它使得我们可以，而不必依赖知识的载体。
2026-03-25 23:53:29
149
原创 三个技巧让LLM自动化脚本更稳定可控
使用 LLM 构造自动化脚本面临一个根本矛盾：一方面不希望它像传统脚本一样只能处理有限情况，另一方面又希望它在更多场景下给出符合预期的答案。LLM 的生成结果天然存在不确定性，同一个提示词多次执行可能得到不同的实现方式，这对自动化脚本来说是致命的。解决这个问题有三种常用技巧：补充上下文、零样本/少样本学习、数据驱动简化生成目标。
2026-03-25 23:52:29
98
原创 与LLM结对编程：测试先行如何提升AI辅助开发质量
用同一个命令行参数解析器需求，按照测试驱动的方式重做一遍，与直接让 LLM 生成代码的方式形成对比。关键差别在于起点：这次。通过提示词模板让 LLM 根据功能需求列出需要测试的场景，并给出测试数据。简单阅读返回结果，就能发现几个错误：场景间存在大量重复覆盖；LLM 将理解为唯一支持的参数，而不是通过配置可扩展的设计，完全误解了需求。。不正确的生产代码和不正确的测试列表，是同一份错误知识的不同表现形式。。因此需要在更早的时候提出反馈，避免错误的累积。
2026-03-25 23:51:30
312
原创 LLM辅助编程：从直接生成到测试驱动的质量跃迁
以命令行参数解析器为例（源自 Robert C. Martin《Clean Code》第十四章），需求是解析-l（布尔）、-p（整数）、-d（字符串）、-g（列表）等带类型的命令行参数，支持默认值和错误提示。将需求直接转化为提示词模板交给 LLM，几秒钟内就能得到一段有相当复杂度的 Java 代码。。这就意味着，无论是否了解测试驱动开发，LLM 的特性都会把注意力引导到测试上——必须为生成的代码构造测试，才能验证它是否符合要求。于是继续让 LLM 生成测试代码，然后执行，发现失败。
2026-03-25 23:48:52
258
原创 测试驱动AI开发：架构与测试策略驱动的任务分解方法
LLM 存在技术限制：每次只能处理有限数量的 token，也只能产生有限数量的输出。对于大型系统，无法一次性将上下文传递给 LLM，也无法从 LLM 中一次性获取整个应用。因此，，将任务转化为提示词，交由 LLM 处理，再将生成结果组合成生产或测试代码。任务划分的质量，直接决定了 LLM 辅助开发的效果。和。
2026-03-25 06:08:56
344
原创 按测试策略驱动LLM生成架构对齐的代码
确定测试策略之后，就可以将其转化为结构化的提示词模板（Prompting Template），驱动 LLM 按照架构约束生成代码。以三层架构（HTTP Interface / Application Logic / Persistent）为例，测试策略规定：Persistent 层使用 Fake（H2 内存数据库）作为测试替身，HTTP Interface 和 Application Logic 层使用 Stub，最后通过功能测试对整个系统进行验证。针对每一层，分别构造对应的提示词模板。和。
2026-03-25 06:07:52
345
原创 消除公孙止困境：用CoT打通架构知识到团队执行的最后一公里
编码的过程本质上是技术方案应用的过程——不只是实现功能，还要保证实现方式符合技术方案的约束与条件。从认知行为模式来看，技术方案的应用处于：感知业务需求（Sense）→ 按技术方案分解任务（Analysis）→ 依照任务列表完成代码（Respond）。这个判断带来两个重要推论。第一，技术方案作为不可言说知识，需要。进入开发环节时，主要是不可言说知识的应用，而不是学习。第二，庞杂模式下效率的关键是，而不是个人的有效性和效率。
2026-03-25 06:06:16
358
原创 用CoT提示词模板将测试工序注入LLM代码生成流程
测试工序定义了针对不同架构层的测试方式，要让 LLM 按照工序生成代码，需要将工序转化为 CoT（Chain of Thought）提示词模板。CoT 的作用是指导 LLM 按照工序要求，将给定的功能需求拆分为对应的任务列表。（技术栈、各层命名规则、层间调用关系）、（每一层使用什么测试替身、需要识别哪些目标功能和测试场景）、（先列出验收场景和测试数据，再按工序说明逐层生成任务列表）。
2026-03-25 06:03:52
416
原创 测试工序：让架构设计真正落地的关键机制
—测试策略制定了我们在完成架构中不同组件的开发与集成过程中，测试所需完成的任务。因此，软件开发中的工序也叫测试工序。以三层架构（HTTP Interface / Application Logic / Persistent）为例，一套典型的测试工序包含四个步骤：使用 Fake 数据库测试 Persistent 层组件；通过 Stub Persistent 层组件测试 Application Logic 层；通过 Stub Application Logic 层组件测试 HTTP Interface 层。
2026-03-24 16:26:55
64
原创 功能上下文划分与测试替身选择策略
划分功能上下文最直接的方法是软件架构。架构定义了系统由哪些组件构成以及各组件之间的关系，每个组件负责明确的功能单元，天然对应一个功能上下文。以一个典型的后端三层架构为例，业务场景是"用户获取所有在售商品"。按照这三个功能上下文，可以构造相互关联的 Q1 与 Q2 测试：Q2 的功能测试覆盖整个调用链（HTTP interface → Application Logic → Persistent），而三个 Q1 测试分别只覆盖对应的单个组件。
2026-03-24 16:26:03
178
原创 测试四象限：构造支持团队的有效测试策略
很多人谈到测试策略，第一反应是测试金字塔（Testing Pyramid）。这个由 Mike Cohn 在 2009 年提出的隐喻，用金字塔结构描述单元测试、服务测试和 UI 测试的分布关系，核心含义是：能提供快速反馈的细粒度测试应占多数，缓慢昂贵的粗粒度测试只应占少数。。下层测试撑起上层测试，而不是两套毫无关联的测试。这意味着测试金字塔描述的是测试集合的健康状态，而不是帮助我们设计测试策略的工具。真正用于设计测试策略的框架是，由 Brian Marick 在 2003 年提出。
2026-03-24 16:25:13
197
原创 LLM如何辅助软件交付
清晰认知模式下，LLM 带来的效率提升最为直接——通过实现一类任务的自动化。以产品目录服务的提示词模板为例，其中 API 要求的部分与需求背景部分是正交的：无论针对何种需求背景，都可以依照同样的 API 要求进行任务操作。这意味着对 API 要求这部分的知识提取是可复用的。更进一步，同一份 API 要求不仅能用于设计 API，还能用于构造 API 客户端、功能测试、编写实现——只需改变任务部分，就能获得新的任务模板。通过 LLM 的提示词模板，实现了类似自动化脚本的效果。
2026-03-24 16:24:09
89
原创 使用LLM应用和提取不可言说知识
由于 LLM 的回答具有不确定性，我们与 LLM 的默认交互模式是但这并不意味着 LLM 只能在复杂模式下发挥作用。当我们给予 LLM 一个非常明确的任务时（比如生成特定 SQL 查询），我们对于要做的修改有清晰的认识，实际上处在清晰的认知模式中——交互上表现为复杂模式，只是为了应对 LLM 的不确定性。因此，讨论 LLM 的交互模式时，需要区分：哪些是应对 LLM 不确定性的，哪些是我们认知行为的体现。
2026-03-24 16:23:17
370
原创 使用LLM提取和传递知识
要理解 LLM 如何帮助我们提取知识，首先需要将它看作一种特殊的。迁移学习是机器学习领域的重要概念：将从一个问题（源任务）中学到的知识，应用到另一个相关问题（目标任务）上。即使两个任务不完全相同，一个任务中学到的特征、模式和知识也可以在另一个任务中发挥作用。比如，一个识别猫狗的计算机视觉 AI，可以通过迁移学习训练成识别汽车的 AI。LLM 是一个非常特殊的模型，核心能力是阅读理解——结合预训练集中的语料，根据提示词中提供的上下文信息执行任务。
2026-03-24 16:22:28
217
原创 不可言说的知识：AI时代软件工程的核心传递问题
软件工程中存在两类截然不同的知识，理解它们的区别是构建高效知识传递体系的前提。**显式知识（Explicit Knowledge）**是能够直接表达并在人群中分享的知识，比如数据结构的定义、设计模式的规则、编码规范等。这类知识可以写进文档、记录在 Wiki 里，任何人都能通过阅读获取。**不可言说的知识（Tacit Knowledge）**则是那些无法用语言完整表达的知识，它依附于个人经验、直觉和技能，与具体场景紧密绑定。
2026-03-24 16:21:34
472
1
原创 Cynefin框架：用认知模式理解知识传递效率
上一篇讨论了不可言说知识的传递需要社会化活动，但如何评估知识传递是否高效？答案在于观察知识消费者的——同样的知识，不同的人在消费时会产生截然不同的认知负载，这直接决定了传递效率。Cynefin 框架（由戴维·斯诺登于 1999 年提出）原本是一个解决问题的工具，将各种情况归入由因果关系定义的五个领域。在知识管理的语境下，这五个领域对应了人们在消费和传递不同类型知识时的认知行为模式，认知水平由高到低依次是：清晰、庞杂、复杂、混乱、困惑。
2026-03-24 16:20:26
228
原创 软件工程即知识工程：从知识传递视角重新理解研发过程
理解软件工程的本质，需要先厘清一个根本问题：软件的真正产品是什么？软件与书籍是同构的。书籍是载体，作家真正关心的是其中的人物、情节、观点和论据——内容才是产品，书籍只是内容的载体。。软件中最重要的知识是，包括业务流程、组织架构、行业规则、领域知识等。这些知识描述了软件如何帮助客户解决问题、企业如何运营业务。业务知识可以脱离软件存在，但软件不能脱离其内在知识而存在。业务知识的载体不只是软件，还有人和组织。一个按公式计算报价的软件，其真正的产品是报价规则；掌握了这个规则的人，同样能完成报价工作。
2026-03-24 16:18:41
397
原创 知识过程中的认知模式
清晰与庞杂模式产生于知识消费和应用，属于有序模式复杂模式产生于知识学习，需要通过探测-反馈循环掌握混乱模式应尽快恢复秩序，回到有序模式在AI时代的软件工程中，识别当前所处的认知模式，并设计相应的知识传递策略，是提升团队效能的关键。对于LLM辅助开发，理解这些模式有助于我们设计更有效的交互策略：显式知识直接提供上下文，不可言说知识通过多轮对话构造反馈循环。
2026-03-24 16:12:00
407
原创 围绕不可言说知识构造知识过程
知识工程的核心在于理解知识的本质差异，并据此设计高效的知识传递机制。显式知识可以直接编码和传递，而不可言说知识需要通过社会化活动中的启动-反馈循环来实现转移。在AI时代，LLM既是知识消费者也是知识生产者。掌握如何构造有效的知识过程，将成为软件工程师的核心竞争力。
2026-03-22 12:18:14
149
原创 知识工程：重新定义AI时代程序员的核心价值
当 ChatGPT 能够根据一段描述生成完整的 Spring Boot 服务时，很多程序员感到恐慌。但这种恐慌本身，恰恰暴露了一个长期存在的认知误区：把"写代码"等同于"软件开发"。软件工程的核心从来不是代码本身，而是代码所承载的知识。软件是知识的可执行形式，是载体而非产品。真正的产品是其中包含的业务逻辑、架构决策、领域知识和工程实践。这一点从实际工作时间分布就能看出来：大多数开发者的日常由反复确认需求、构思解决方案、查阅文档、在 Stack Overflow 寻求答案、通过调试理解代码逻辑构成。
2026-03-22 12:10:57
169
原创 从狂热到理性 大模型在测试内部落地的实战复盘
问题类别具体表现流程刚性缺乏灵活干预机制（暂停、参数调整、临时调试）等待时间长LLM 处理复杂任务耗时久，尤其高负载下产出不稳定受模型性能、输入数据、算力影响，质量不一致缺乏个性化流程与配置过于通用，无法适配不同项目需求反馈循环不足问题反馈机制迟缓，长期痛点未解阶段策略结果第一阶段从简单入手（Dify 智能体），化繁为简成功，用户接受度高第二阶段自研复杂系统，期望一步到位失败，用户弃用第三阶段提供封装好的 MCP Server，控制开放程度成功，避免重蹈覆辙。
2026-03-22 11:54:38
197
原创 AI 赋能测试左移 用大模型下好需求先手棋
需求阶段：大模型自动补充验收条件，开卡效率提升至少一倍开发阶段：测试工程师主导提示词工程，注入边界用例和异常处理质量保障：从"缺陷猎手"升级为"风险守护者"这种实践不仅提升了交付效率，更重要的是重塑了软件质量保障的哲学基础——质量从项目伊始就融入设计与规划，而非事后补救的产物。
2026-03-22 11:52:41
403
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人