公司的风控系统出了个诡异的 bug。用户 A 在页面上看到自己被拒绝了，但查日志发现规则里引用的是用户 B 的订单金额。两个人完全不相干，数据却串了。排查了两天，最后定位到 QLExpress 的 DefaultContext 被当成了单例 Bean，所有请求共享同一个 context 对象，并发请求下变量互相覆盖。 这种 bug 的特征很典型——低并发时一切正常，压测或者高峰期才出现，而且数据是"偶尔串"而不是"一直错"。如果你问 QA 能不能复现，他们的回答多半是"有时候能有时候不能"。这就是并发问题的经典症状。 今天聊聊怎么在规则引擎的场景下，用 ThreadLocal 把上下文彻底隔离开，再加一个清理钩子防止内存泄露。 问题怎么发生的 先还原一下事故现场。很多人在用 QLExpress 的时候，为了省事会把 DefaultContext 注入成 Spring Bean： @Component public class RuleService { // ❌ 单例 Bean！所有请求共享 private final DefaultContext<String, Object....

背景：规则执行性能的挑战 在现代软件系统中，规则引擎被广泛应用于业务逻辑处理、决策制定等场景。规则的执行性能直接影响系统的响应速度和用户体验。然而，规则执行耗时突增的问题时有发生，可能导致系统性能下降、响应超时，甚至服务崩溃。 传统的监控方式通常是基于系统级别的指标（如CPU、内存使用率），难以精确到具体的规则执行耗时。当规则执行耗时突增时，往往无法及时发现和定位问题，导致问题扩大化。 本文将介绍如何使用SpringBoot实现规则执行耗时突增告警机制，当某条规则执行时间超过阈值时，在5秒内通知负责人排查，确保系统的稳定运行。 核心概念 1. 规则执行耗时监控 规则执行耗时监控是指对规则执行过程的时间消耗进行实时监控和分析。 监控维度描述示例 单条规则耗时监控每条规则的执行时间规则A执行耗时100ms 规则组耗时监控规则组的总执行时间规则组A执行耗时500ms 规则执行频率监控规则的执行次数和频率规则A每分钟执行100次 耗时趋势监控规则执行耗时的变化趋势规则A耗时从10ms增长到100ms 异常耗时监控规则执行的异常耗时规则A执行耗时超过1000ms 2. 告警机制 告警....

前言 在企业级应用中，规则引擎是一个常见的组件，用于处理复杂的业务逻辑。然而，当线上规则出现异常时，排查和定位问题往往非常困难。规则执行过程中的上下文信息复杂多变，环境差异可能导致线下无法复现线上问题。如何快速捕获和重现规则执行的完整上下文，成为了开发和运维团队面临的一个重要挑战。 想象一下这样的场景：线上系统在处理某个用户的订单时，规则引擎执行异常，导致订单处理失败。开发人员在本地环境中尝试复现这个问题，但由于缺少完整的执行上下文，无法重现线上的异常情况。这不仅会延长问题排查的时间，还可能导致类似问题再次出现。 规则执行上下文快照和问题复现是解决这个问题的有效方案。通过在规则执行过程中捕获完整的上下文信息，并支持一键导出和导入执行环境，可以快速重现线上问题，提高排查效率。本文将详细介绍如何在 SpringBoot 项目中实现规则执行上下文快照和问题复现功能。 一、规则执行上下文快照的核心概念 1.1 什么是规则执行上下文快照 规则执行上下文快照是指在规则执行过程中，捕获和保存完整的执行环境信息，包括： 规则定义：执行的规则内容和版本 输入数据：规则执行的输入参数和数据 中间状态：规....