1. 为什么“判断引擎”在 .NET 生态里总被当成“配角”——从需求错位说起“判断引擎落地 .NET 的四条路线、一个客户端与一份生产样本”——这个标题乍看像技术方案汇报实则戳中了企业级规则系统演进中最常被忽视的痛点不是没有判断引擎而是没有能真正跑在 .NET 生产环境里的判断引擎。我在金融风控平台、工业设备远程诊断系统、医疗合规审核中反复遇到过这类问题业务方拿着 Drools 或 Python 写的规则模型来对接开发团队第一反应是“这得重写成 C#”然后开始查 NuGet 上有没有现成包查完发现要么是十年前的老版本、要么文档只有英文、要么示例代码连dotnet run都报错。这不是能力问题是生态错位。.NET 开发者日常面对的是 ASP.NET Core Web API、WPF 桌面应用、Blazor WebAssembly、甚至 Unity 游戏逻辑——这些场景对“判断引擎”的诉求根本不同Web API 要低延迟、高并发地执行上千条业务规则WPF 客户端需要离线运行、支持用户自定义规则编辑Blazor WASM 则要求引擎体积小、无反射、能 AOT 编译。而市面上主流判断引擎如 Drools、Easy Rules、Durable Rules的设计哲学是“Java 优先”或“通用 DSL 优先”它们默认依赖 JVM 的类加载机制、Spring 的 Bean 注入、或 Node.js 的动态 require直接移植到 .NET 会触发一连串底层冲突System.Reflection.Emit在 .NET 6 的 AOT 模式下被禁用、Expression.Compile()在 Blazor WASM 中不可用、dynamic类型在 IL trimming 后丢失元数据……这些不是 Bug而是架构基因差异。更现实的问题是“客户端”二字。很多团队以为把规则引擎封装成一个.dll就算“客户端”结果上线后发现WPF 应用加载规则时卡顿 3 秒因 JIT 编译耗时、ASP.NET Core 服务在 Kubernetes Pod 重启后规则缓存失效、Blazor 应用首次加载规则文件超时被浏览器中断。真正的客户端必须同时满足三个硬约束可嵌入性不依赖全局安装、可预测性执行时间/内存占用可控、可审计性规则变更留痕、执行过程可追溯。而当前 .NET 生态里90% 的开源规则库只解决了第一个剩下两个靠开发者自己补丁。所以“四条路线”不是技术选型罗列而是对四种典型生产约束的回应当你的规则要跑在银行核心交易链路里毫秒级响应当它要装进工控机离线运行无网络、低内存当它要嵌入到 Excel 插件里COM 互操作兼容当它要通过 WebAssembly 在浏览器里验证用户输入零服务器依赖。每一条路线背后都对应着一套被忽略的底层契约——比如 AOT 编译下的表达式树限制、Windows Forms 的 STA 线程模型对异步规则的影响、或 .NET MAUI 对原生 SQLite 规则存储的适配方式。我接下来要拆解的不是“怎么用”而是“为什么只能这么用”。2. 四条落地路线的本质不是工具选择而是契约匹配判断引擎在 .NET 中的落地从来不是“找一个最像 Drools 的库”而是在 .NET 运行时契约Runtime Contract与规则执行契约Rule Execution Contract之间建立可验证的映射关系。我把这个过程抽象为四条路线每条都对应一组不可妥协的约束条件。它们不是并列选项而是按生产环境优先级排序的决策树——先确认你的场景属于哪一类再选工具而非反过来。2.1 路线一纯表达式编译路线适用于高频交易、实时风控等毫秒级场景核心契约执行时间必须可预测且 ≤ 5msP99不允许任何 JIT 编译延迟规则变更需热更新不重启进程。典型场景证券交易所订单匹配引擎、支付网关反欺诈模块、IoT 设备边缘计算节点。这里不能接受“第一次执行慢一点”的宽容因为规则可能每秒被调用数万次JIT 编译的 10-50ms 延迟会直接导致 SLA 崩溃。我实测过三种方案直接使用System.Linq.ExpressionsCompile()在 .NET 5 中Expression.Compile()生成的委托执行极快约 0.8μs/次但问题在于热更新——每次重新 Compile 会生成新委托旧委托无法 GC长期运行内存泄漏。解决方案是引入DelegateCache用ConcurrentDictionarystring, Delegate缓存已编译委托Key 是规则哈希值Value 是FuncTInput, bool。当规则变更时仅更新 Dictionary 中对应 Key 的值旧委托自然被 GC 回收。关键技巧必须用Expression.Block()包裹所有规则逻辑避免闭包捕获外部变量导致委托无法复用。使用Microsoft.CodeAnalysis动态编译 C# 代码把规则 DSL 编译成临时程序集。优势是调试友好可附加调试器、支持完整 C# 语法劣势是编译耗时平均 120ms需预热。我的做法是启动时预编译 100 条常用规则模板运行时仅对参数化部分做轻量替换将编译时间压到 8ms 以内。放弃高级 DSL用 JSON Schema System.Text.Json验证这是最激进的方案。把规则定义为 JSON Schema如{ type: object, properties: { amount: { type: number, minimum: 100 } } }用JsonSerializer.DeserializeT()JsonSerializerOptions的PropertyNamingPolicy控制字段映射。执行时间稳定在 2.3μs且完全规避反射和编译。代价是规则表达能力受限但对“金额 100 且状态为激活”的简单判断它比 Drools 快 47 倍。提示此路线严禁使用任何基于dynamic或ExpandoObject的规则引擎它们在 AOT 模式下会触发MissingMethodException且执行时间波动极大P99 达 15ms。2.2 路线二轻量 DSL 解析路线适用于 WPF/WinForms 桌面客户端、离线工控软件核心契约必须支持离线运行规则文件体积 500KB加载时间 200ms允许用户在 UI 中拖拽编辑规则。典型场景医疗设备配置管理软件、工厂 MES 系统本地客户端、电力巡检 PDA 应用。这些环境常无网络、内存有限工控机仅 2GB RAM且用户需要可视化规则编辑器。我最终采用的方案是自研微型 DSL 解析器 预编译字节码DSL 设计原则仅支持AND/OR/NOT逻辑、 ! 比较、IN/CONTAINS集合操作、DATE_ADD/DAY_OF_WEEK时间函数。禁止循环、递归、自定义函数——这些由宿主应用提供扩展点。解析流程DSL 文本 → AST 抽象语法树 → 字节码自定义指令集如LOAD_FIELD order.amount、PUSH_CONST 100、OP_GT→ 二进制序列化存储。字节码体积仅为原始 DSL 的 1/3且解析速度提升 8 倍对比 ANTLR 生成的 C# 解析器。执行引擎纯 C# 实现的栈式虚拟机指令集仅 12 条。关键优化字段访问缓存FieldInfo句柄。首次访问order.amount时通过Type.GetField(amount)获取FieldInfo后续直接fieldInfo.GetValue(obj)避免重复反射开销。实测 1000 条规则加载时间从 320ms 降至 86ms。配套的 WPF 规则编辑器采用 MVVM 模式用TreeView展示规则树拖拽节点改变逻辑结构实时生成 DSL 文本。用户保存时前端调用RuleCompiler.Compile(dslText)生成字节码存入本地 SQLite 数据库。整个流程无需任何外部依赖.NET Framework 4.7.2或.NET 6均可运行。2.3 路线三服务化嵌入路线适用于 ASP.NET Core 微服务、Blazor Server 应用核心契约规则必须可版本化管理支持灰度发布执行过程可全链路追踪与现有 DI 容器无缝集成。典型场景电商促销引擎、保险核保服务、SaaS 平台多租户规则隔离。这里规则不再是静态文件而是动态服务——同一套规则可能对 VIP 用户启用对普通用户禁用或在 A/B 测试中分流量执行。我的实现是“规则即服务Rule-as-a-Service”模式规则存储Azure Blob Storage或 MinIO存放规则定义 JSON每个规则有id、version、tenantId、enabled字段。版本号采用语义化1.2.0支持回滚。执行代理在 ASP.NET Core 中注册IRuleExecutor服务内部维护ConcurrentDictionary(string id, string version), IRule缓存。首次请求时从 Blob 加载并编译用路线一的 Expression 编译后续直接调用缓存委托。灰度控制在RuleExecutor.ExecuteAsync()中注入ITenantContext根据tenantId和HttpContext.Request.Headers[X-Canary]决定是否启用新版本。关键设计规则编译与执行分离。编译在后台任务中进行避免阻塞请求执行时仅查缓存确保 P99 3ms。链路追踪集成 OpenTelemetry在ExecuteAsync方法前后自动记录rule.id、rule.version、execution.time、input.hash。当某条规则频繁超时可快速定位是规则本身复杂如嵌套 10 层 AND还是数据源慢如调用下游 HTTP 接口超时。注意此路线严禁将规则引擎作为独立微服务部署如单独的 RuleEngine API。网络调用延迟会摧毁性能且增加运维复杂度。必须“嵌入”而非“调用”。2.4 路线四WebAssembly 路线适用于 Blazor WebAssembly、Electron.NET 前端规则验证核心契约零服务器依赖规则文件可 CDN 分发执行不触发浏览器安全警告内存占用 5MB。典型场景在线表单前端校验、电子合同签署前合规检查、Web 版工业 HMI 界面。用户提交前需即时验证不能等 API 返回——否则体验断层。技术难点在于Blazor WASM 运行在 WebAssembly 沙箱中System.Reflection.Emit不可用dynamic被裁剪System.CodeDom完全缺失。主流 .NET 规则引擎在此环境下全部失效。我的解法是“JSON 规则 预编译 WASM 模块”规则定义采用 JSON Schema Draft 2020-12 标准支持$ref引用外部规则库。例如{ type: object, properties: { email: { $ref: https://cdn.example.com/rules/email.json }, age: { type: integer, minimum: 18 } } }WASM 模块用 C 编写轻量 JSON Schema 验证器基于nlohmann/json编译为 WebAssemblyemcc -O2 -s STANDALONE_WASM1体积仅 180KB。通过IJSRuntime.InvokeVoidAsync(loadWasmModule, wasmBytes)加载到浏览器。.NET 侧胶水代码定义JsRuleValidator类用[JSInvokable]导出Validate(string jsonInput, string schemaJson)方法内部调用 WASM 模块的 C 函数。实测 10KB JSON 输入验证耗时 12msChrome内存峰值 3.2MB。这套方案让规则完全脱离服务器CDN 更新规则 JSON 即刻生效且符合 GDPR 的“数据不出浏览器”要求。唯一代价是规则语法受限于 JSON Schema但对 90% 的业务校验邮箱格式、手机号、数值范围、必填字段已足够。3. “一个客户端”的真相它不是 SDK而是运行时契约的具象化行业里常说的“判断引擎客户端”99% 都是误导。真正的客户端不是你dotnet add package的那个 NuGet 包而是一套在特定 .NET 运行时环境下能稳定履行规则执行契约的最小可执行单元。它必须回答三个问题规则从哪来规则怎么跑跑完怎么交差——而这三个问题的答案直接决定了它是不是“生产就绪”。3.1 规则来源不是“读文件”而是“可信供应链”在生产环境“从 config.json 读规则”是自杀行为。我见过太多事故运维误删规则文件、Git 合并冲突导致 JSON 格式错误、CI/CD 流水线未校验规则语法就发布。真正的客户端必须内置规则供应链验证。我的客户端设计包含三级校验语法层加载规则时先用JsonDocument.Parse()验证 JSON 合法性失败则抛出RuleSyntaxException并记录RuleId和RawContent。这比try-catch(JsonException)更精准能定位到具体行号。语义层对规则 DSL 做 AST 静态分析。例如检测是否存在未声明的变量引用user.balance但输入对象无balance字段、逻辑环Rule A 依赖 Rule BRule B 又依赖 Rule A。这部分用CSharpSyntaxTree解析 C# 风格规则或自定义 Visitor 模式遍历 DSL AST。信任层规则文件必须带数字签名。客户端启动时从https://rules-trust.example.com/cert.pem下载公钥证书验证规则 JSON 的 JWS 签名。签名密钥由 DevOps 团队离线保管每次规则发布需双人审批。未签名规则拒绝加载并触发告警。提示不要用Assembly.LoadFrom()加载规则 DLL——这会绕过所有校验且 DLL 可能含恶意代码。规则必须是数据JSON/YAML而非代码。3.2 规则执行不是“调方法”而是“受控沙箱”“执行规则”听起来简单但在生产中它意味着资源隔离一条失控的规则如while(true) { }不能拖垮整个服务。我的客户端用CancellationTokenSource设置全局超时默认 500ms并在规则执行委托内定期检查token.IsCancellationRequested。更进一步对 CPU 密集型规则如正则匹配长文本用ThreadPool.UnsafeQueueUserWorkItem()将其移出主线程避免阻塞 ASP.NET Core 请求线程池。状态净化规则执行不应污染全局状态。客户端强制要求所有规则函数为纯函数Pure Function输入参数readonly输出仅通过返回值禁止修改传入对象、禁止访问静态字段、禁止调用DateTime.Now改用注入的IClock.UtcNow。违反者在编译阶段报错。异常熔断当某条规则连续 3 次抛出未处理异常如NullReferenceException客户端自动将其标记为DISABLED并发送告警。下次执行时跳过该规则返回默认结果如false避免雪崩。3.3 结果交付不是“return bool”而是“可审计证据链”生产环境中“规则返回 true”毫无意义。你需要知道谁在什么时间、用什么输入、执行了哪条规则、依据什么条件判定为 true、中间变量值是多少这就是“证据链”。我的客户端内置RuleExecutionRecorder记录粒度每条规则执行生成一条RuleExecutionLog包含RuleId、Version、Timestamp、InputHashSHA256、Output、DurationMs、StackTrace仅异常时。存储策略日志先写入内存环形缓冲区MemoryRingBufferRuleExecutionLog容量 10000 条再异步批量写入 Elasticsearch。缓冲区满时自动丢弃最老日志FIFO确保内存不爆。查询接口提供/api/rules/logs?ruleIdxxxfrom2024-01-01to2024-01-31REST API返回结构化日志。审计人员可导出 CSV用 Excel 分析规则命中率、性能趋势、异常分布。这套设计让规则执行从“黑盒”变成“白盒”。当业务方质疑“为什么这笔订单被拒”你能在 10 秒内给出完整证据RuleId: ORDER_AMOUNT_LIMIT, Version: 2.1, Input: {amount: 50000}, Output: false, Reason: amount 10000。4. 一份生产样本从零搭建一个可上线的判断引擎客户端理论终需落地。下面我以一个真实项目——物流运费计算引擎为例展示如何将前述四条路线、客户端契约整合为一份可直接部署的生产样本。该项目需支持全国 3000 城市运费规则、实时计算 100ms、支持运营后台动态调整规则、前端 H5 页面即时验证。4.1 架构选型混合路线实践核心计算服务ASP.NET Core 7采用路线三服务化嵌入规则存储于 Azure Blob版本化管理灰度发布。WPF 运营后台采用路线二轻量 DSL 解析提供可视化规则编辑器离线可工作。H5 前端运费预估采用路线四WebAssembly规则 JSON 由 CDN 分发浏览器端即时计算不依赖后端 API。这种混合并非炫技而是精准匹配各端约束服务端要高性能和可运维桌面端要易用和离线前端要零延迟和隐私。4.2 关键代码实现一个可运行的最小客户端以下是核心客户端类FreightRuleEngine的骨架已脱敏保留生产级细节// FreightRuleEngine.cs public class FreightRuleEngine : IRuleEngine { private readonly ConcurrentDictionary(string ruleId, string version), FuncFreightRequest, FreightResult _compiledRules new(); private readonly ILoggerFreightRuleEngine _logger; private readonly IHttpClientFactory _httpClientFactory; private readonly IRuleStorage _ruleStorage; // 抽象规则存储可为 Blob 或 LocalFile public FreightRuleEngine( ILoggerFreightRuleEngine logger, IHttpClientFactory httpClientFactory, IRuleStorage ruleStorage) { _logger logger; _httpClientFactory httpClientFactory; _ruleStorage ruleStorage; } public async TaskFreightResult ExecuteAsync(FreightRequest request, string ruleId, string version latest) { var cacheKey (ruleId, version); var compiled _compiledRules.GetOrAdd(cacheKey, key { // 1. 从存储加载规则定义 var ruleDef _ruleStorage.GetRuleAsync(key.ruleId, key.version).GetAwaiter().GetResult(); // 2. 语法 语义校验省略具体实现 ValidateRuleDefinition(ruleDef); // 3. 编译为 Expression 委托 return CompileToDelegate(ruleDef); }); try { // 4. 执行带超时和异常熔断 using var cts new CancellationTokenSource(TimeSpan.FromMilliseconds(500)); var result await Task.Run(() compiled(request), cts.Token); return result; } catch (OperationCanceledException) { _logger.LogWarning(Rule {RuleId} execution timeout, ruleId); throw new RuleExecutionTimeoutException(ruleId); } catch (Exception ex) when (ex is not RuleExecutionTimeoutException) { // 5. 异常熔断记录并禁用规则 _logger.LogError(ex, Rule {RuleId} failed with exception, ruleId); DisableRule(ruleId, version); throw; } } private FuncFreightRequest, FreightResult CompileToDelegate(RuleDefinition def) { // 示例编译简单规则 weight 10 distance 100 var param Expression.Parameter(typeof(FreightRequest), req); var weightProp Expression.Property(param, Weight); var distanceProp Expression.Property(param, Distance); var weightGt10 Expression.GreaterThan(weightProp, Expression.Constant(10m)); var distanceLt100 Expression.LessThan(distanceProp, Expression.Constant(100m)); var body Expression.AndAlso(weightGt10, distanceLt100); var lambda Expression.LambdaFuncFreightRequest, bool(body, param); return req new FreightResult { IsFree lambda.Compile()(req) }; } private void DisableRule(string ruleId, string version) { // 标记规则为 DISABLED下次加载时跳过编译 _ruleStorage.MarkAsDisabled(ruleId, version); } }4.3 生产部署清单让样本真正可用光有代码不够生产环境还需这些项目要求我的实践规则发布流程支持原子性、可回滚Git 仓库中rules/目录存放 JSONCI/CD 脚本1)jq校验 JSON 语法2)curl调用/api/rules/validateAPI 预执行测试3) 上传到 Blob 并更新version.json元数据。失败则自动回滚上一版。监控指标必须采集的 5 个核心指标rule_execution_count{rule_id,version,status}status: success/fail/timeout、rule_execution_duration_seconds{rule_id,quantile}、rule_cache_hit_rate、rule_disabled_count、rule_signature_valid{rule_id}告警阈值防止小问题变大故障当rule_execution_duration_seconds{quantile0.99} 200ms持续 5 分钟或rule_disabled_count 0或rule_signature_valid 0立即触发企业微信告警。灾备方案规则中心宕机时的降级客户端内置FallbackRuleProvider从本地appsettings.json加载兜底规则如“所有城市首重 12 元”确保服务不雪崩。4.4 实测性能数据不是 benchmark而是真实流量在 2023 年双 11 大促期间该引擎支撑了日均 2.4 亿次运费计算请求P99 延迟83ms目标 100ms规则热更新从运营后台修改规则到全量生效平均耗时 4.2 秒含 CDN 缓存刷新异常率0.0017%主要为输入数据格式错误非引擎问题内存占用单 Pod2CPU/4GB稳定在 1.8GB无内存泄漏通过 dotnet-dump 分析确认最关键的是0 次因规则引擎导致的线上故障。所有问题都暴露在预发环境——因为我们的客户端契约超时、熔断、校验在测试阶段就已强制生效。5. 踩过的坑那些没写在文档里的“经验税”纸上谈兵易落地踩坑难。以下是我为这个判断引擎付出的“经验税”每一条都来自真实生产事故绝非理论推演。5.1 坑一.NET 6 的TrimModepartial会静默破坏规则引擎现象升级到 .NET 6 后WPF 客户端在某些机器上规则执行返回null日志无异常调试器显示Expression.Compile()返回null。根因TrimModepartial默认会移除未被直接引用的System.Linq.Expressions类型。虽然你的代码没显式new ExpressionVisitor()但Expression.Block()内部调用了ExpressionVisitor的私有构造函数被裁剪后导致编译失败Compile()返回null。修复在.csproj中添加PropertyGroup TrimModelink/TrimMode TrimmerSingleWarnfalse/TrimmerSingleWarn /PropertyGroup ItemGroup TrimmerRootAssembly IncludeSystem.Linq.Expressions / /ItemGroup经验所有使用Expression、Reflection、dynamic的 .NET 6 项目必须显式声明 TrimmerRootAssembly否则上线即翻车。5.2 坑二Blazor WASM 的HttpClient默认超时是 100 秒但规则加载不能等现象H5 页面首次加载运费规则时偶发白屏 100 秒用户以为卡死。根因Blazor WASM 的HttpClient默认Timeout TimeSpan.FromSeconds(100)而 CDN 规则 JSON 有时因网络抖动延迟 100 秒才返回HttpClient.GetAsync()抛出TimeoutException页面无任何提示。修复创建专用RuleHttpClient设置合理超时var handler new HttpClientHandler { AutomaticDecompression DecompressionMethods.GZip | DecompressionMethods.Deflate }; var client new HttpClient(handler) { Timeout TimeSpan.FromSeconds(10) // 规则文件应 1MB10 秒足够 };并添加重试逻辑指数退避var policy Policy .HandleHttpRequestException() .OrResultHttpResponseMessage(r !r.IsSuccessStatusCode) .WaitAndRetryAsync(3, retryAttempt TimeSpan.FromMilliseconds(Math.Pow(2, retryAttempt) * 100));5.3 坑三规则版本号1.0.0和1.0被视为不同版本但运营同学不知道现象运营在后台发布1.0版本规则API 调用却指定version1.0.0导致加载旧版规则客户投诉“新规则没生效”。根因语义化版本规范要求1.0.0和1.0等价但我们的规则存储Blob路径是rules/{id}/{version}/definition.json1.0和1.0.0是不同目录。修复在IRuleStorage.GetRuleAsync()中统一 normalize 版本号private string NormalizeVersion(string version) version switch { null or latest, 1.0 1.0.0, 1 1.0.0, _ version };并强制运营后台下拉框只显示1.0.0、1.1.0等标准格式禁用1.0输入。5.4 坑四ConcurrentDictionary.GetOrAdd()在高并发下可能多次编译同一条规则现象服务启动初期大量请求涌入日志显示同一条规则被编译了 5 次CPU 短暂飙升。根因GetOrAdd的 valueFactory 是 lazy-evaluated当多个线程同时 missvalueFactory 会被并发执行多次。虽然最终 Dictionary 只存一个值但编译动作已发生多次。修复用LazyT包装编译逻辑var lazyCompiled new LazyFuncFreightRequest, FreightResult(() { var ruleDef _ruleStorage.GetRuleAsync(ruleId, version).GetAwaiter().GetResult(); return CompileToDelegate(ruleDef); }); var compiled _compiledRules.GetOrAdd(cacheKey, _ lazyCompiled.Value);LazyT.Value是线程安全的确保编译只执行一次。这些坑文档不会写开源项目 issue 里也找不到。它们只存在于深夜的告警电话、凌晨三点的 dump 分析、和运营同事一句“这个功能怎么又不行了”的质问里。我把它们列出来不是为了炫耀而是提醒判断引擎落地 .NET最难的不是技术实现而是把每一个“理所当然”的假设都变成可验证、可监控、可回滚的生产契约。
