1. 项目概述为什么用C写规则引擎最近在社区里看到不少关于规则引擎的讨论很多朋友都在用Java的Drools或者Python的某些库。但总有人问“C性能这么好为什么没有像样的规则引擎” 甚至有人觉得C这种“硬核”语言是不是天生就不适合做这种需要灵活性的东西作为一个在C和业务系统里摸爬滚打了十来年的老码农我想说不是没有而是大家没找对路子或者被“动态类型”、“运行时编译”这些词吓住了。实际上用C实现一个核心的、高效的规则引擎不仅完全可行而且在某些对性能有极致要求的场景下比如高频交易、实时风控、游戏逻辑服务器它甚至是唯一的选择。这个项目的目标就是抛开那些庞大的框架从最本质的“条件-动作”模型出发用C打造一个轻量、快速、易于理解和集成的简单规则引擎。它不追求像Drools那样复杂的DSL领域特定语言而是强调在C的强类型和高效编译的框架内提供清晰的规则定义和快速的规则匹配能力。如果你正在为一个C服务添加灵活的业务规则配置或者想深入理解规则引擎的内核原理那么这个实践会给你带来不少启发。2. 核心设计思路在静态类型中寻求动态表达2.1 规则引擎的本质与C的适配性规则引擎的核心抽象来看就是一个“匹配-执行”系统。它接收一个包含各种属性的事实Fact与一系列预先定义好的规则Rule进行匹配然后执行匹配成功的规则所对应的动作Action。大家常说的“动态”主要体现在规则可以在不重启服务的情况下被加载、更新以及规则条件本身可以灵活组合。C是静态强类型语言这看似与“动态”矛盾但实际上我们可以通过设计来化解。我们不需要在运行时去动态解析一个字符串形式的表达式虽然也可以但复杂且易错而是可以利用C的编译期多态模板和运行时多态继承、虚函数来构建一个类型安全且高效的模型。关键思路是将规则的条件判断逻辑封装成可调用对象函数、函数对象、Lambda表达式而规则本身则管理这些条件与动作的配对关系。这样规则的“动态性”就体现在我们可以动态地组装、替换这些可调用对象而不是动态地解析代码。2.2 我们的轻量级规则引擎架构设计基于以上思路我设计了一个三层的核心架构它足够简单也足够表达大多数业务规则场景事实Fact这是一个承载数据的容器。最简单的实现就是一个std::unordered_mapstd::string, std::any用来存储键值对。但为了类型安全和性能更好的做法是定义一个通用的Fact基类或者使用std::variant来容纳有限的几种数据类型。在我们的简单实现中为了直观我会先使用std::any的map然后讨论其优化方向。条件Condition这是一个可调用对象接收一个Fact作为参数返回一个bool值表示该事实是否满足此条件。它可以是普通函数、函数指针、std::function或者是一个重载了operator()的类仿函数。这是实现灵活性的关键。规则Rule与动作Action一条规则由一个唯一标识ID、一个优先级Priority、一组条件Conditions和一个动作Action组成。动作也是一个可调用对象接收匹配的Fact作为参数执行具体的业务逻辑。规则引擎RuleEngine则管理一个规则集合并提供“匹配-执行”的入口。这个架构的精妙之处在于条件和动作的具体逻辑完全由使用者以C代码的形式提供引擎只负责组织和调度。这既保证了性能没有解释执行的开销又通过标准库组件如std::function提供了足够的运行时灵活性。注意使用std::any虽然灵活但存在类型转换的安全隐患和一定的性能开销。在生产环境中如果事实的数据类型是可枚举的强烈建议使用std::variant或者为特定领域定义具体的Fact结构体。这里为了演示通用性我们仍从std::any开始。3. 核心细节解析与关键实现3.1 事实Fact的封装与数据存取我们首先实现一个最简易的Fact类。它的核心职责是存储和提供类型安全的数据访问。// Fact.h #include string #include any #include unordered_map #include stdexcept class Fact { public: Fact() default; // 设置事实属性 templatetypename T void set(const std::string key, const T value) { data_[key] value; } // 获取事实属性如果类型不匹配或键不存在则抛出异常 templatetypename T T get(const std::string key) const { auto it data_.find(key); if (it data_.end()) { throw std::runtime_error(Fact key not found: key); } try { return std::any_castT(it-second); } catch (const std::bad_any_cast e) { throw std::runtime_error(Fact type mismatch for key: key . e.what()); } } // 检查是否存在某个键 bool has(const std::string key) const { return data_.find(key) ! data_.end(); } private: std::unordered_mapstd::string, std::any data_; };这个实现非常直接但它暴露了两个问题1)std::any_cast失败会抛出异常在性能关键路径上可能需要避免2) 错误处理不够友好。我们可以提供一个更安全的getOptional版本。// 新增一个安全获取的方法返回std::optional templatetypename T std::optionalT getOptional(const std::string key) const { auto it data_.find(key); if (it data_.end()) { return std::nullopt; } const std::any value it-second; if (value.type() ! typeid(T)) { return std::nullopt; } return std::any_castT(value); }3.2 条件Condition与动作Action的类型定义为了最大的灵活性我们将条件和动作都定义为std::function。这样用户可以用Lambda、绑定后的成员函数、普通函数等任何可调用对象来定义逻辑。// Types.h #include functional #include memory class Fact; // 条件类型接受一个Fact返回是否满足 using Condition std::functionbool(const Fact); // 动作类型接受一个Fact执行操作 using Action std::functionvoid(Fact); // 注意Action可能修改Fact使用std::function的好处是接口统一且易于使用。但这里有一个重要的性能考量std::function可能涉及堆内存分配如果捕获的Lambda过大和虚函数调用。对于极端性能场景可以考虑使用模板参数来接受可调用对象但这会使得规则引擎本身的类型变得复杂。在我们的简单引擎中std::function的通用性和便利性是首要的。3.3 规则Rule类的实现一条规则需要包含名称、优先级、一组条件和对应的动作。我们使用std::vectorCondition来存储多个条件它们之间是“与”AND的关系。如果需要“或”OR关系可以通过组合条件来实现。// Rule.h #include string #include vector #include Types.h class Rule { public: Rule(const std::string id, int priority, Action action) : id_(id), priority_(priority), action_(std::move(action)) {} // 添加一个条件 void addCondition(Condition cond) { conditions_.push_back(std::move(cond)); } // 评估规则所有条件都满足则返回true bool evaluate(const Fact fact) const { for (const auto cond : conditions_) { if (!cond(fact)) { return false; } } return true; // 如果没有条件默认视为满足 } // 执行规则的动作 void execute(Fact fact) const { if (action_) { action_(fact); } } // 获取规则ID和优先级用于排序和冲突消解 const std::string getId() const { return id_; } int getPriority() const { return priority_; } private: std::string id_; int priority_; // 数字越大优先级越高 std::vectorCondition conditions_; Action action_; };这里的设计有几个要点条件评估evaluate函数顺序检查所有条件一旦某个条件不满足立即返回false。这种短路求值short-circuit evaluation是高效的。优先级我们引入了一个简单的整数优先级字段。当多条规则同时被触发时引擎可以根据优先级来决定执行顺序这是解决规则冲突Conflict Resolution最基础的策略。规则的构建我们提供了流畅的接口可以方便地添加条件。例如rule.addCondition([](const Fact f){ return f.getint(age) 18; });3.4 规则引擎RuleEngine的核心调度引擎负责管理所有规则并对外提供execute接口传入一个事实引擎负责找出所有匹配的规则并执行它们的动作。// RuleEngine.h #include vector #include algorithm #include memory #include Rule.h class RuleEngine { public: void addRule(std::shared_ptrRule rule) { rules_.push_back(rule); // 添加后可以按优先级排序方便后续查找 std::sort(rules_.begin(), rules_.end(), [](const std::shared_ptrRule a, const std::shared_ptrRule b) { return a-getPriority() b-getPriority(); // 降序优先级高的在前 }); } // 执行所有匹配的规则 void execute(Fact fact) { std::vectorstd::shared_ptrRule matchedRules; // 1. 匹配阶段找出所有满足条件的规则 for (const auto rule : rules_) { if (rule-evaluate(fact)) { matchedRules.push_back(rule); } } // 2. 冲突消解阶段这里我们简单地按优先级执行 // 更复杂的策略可能包括优先级、特殊性、顺序等 for (const auto rule : matchedRules) { rule-execute(fact); // 注意执行一个规则的动作可能会修改fact从而影响后续规则的匹配。 // 这是“前向链”Forward Chaining推理的一种简单形式。 // 如果你不希望动作影响后续匹配需要在设计动作时注意或者复制一份fact。 } } // 清空所有规则 void clear() { rules_.clear(); } private: std::vectorstd::shared_ptrRule rules_; };这个execute函数实现了最简单的“识别-执行”循环。它有两个关键阶段匹配Match遍历所有规则检查条件。这是一个O(N)的操作。如果规则数量庞大成千上万这里会成为性能瓶颈。优化方法包括将规则按条件中涉及的属性进行分组索引类似于数据库的索引可以大幅减少需要评估的规则数量。这是我们后续可以深入优化的点。执行Act按优先级顺序执行所有匹配规则的动作。这里我们采用了“优先级排序”作为冲突消解策略。注意动作的执行可能会改变事实本身这可能导致之前已经匹配过的规则不再匹配或者未匹配的规则新被匹配。我们这个简单实现采用的是“一次性匹配然后顺序执行”的策略动作对事实的修改不会触发对剩余规则的重新匹配。这是一种设计选择如果你需要实现类似Drools的“前向链”需要在每个动作执行后重新进行匹配这会导致更复杂的控制流。4. 从零开始一个完整的实战示例让我们用一个具体的场景来串联以上所有组件实现一个简单的用户折扣计算规则引擎。规则如下如果用户是VIPis_viptrue且订单金额amount大于100则打8折。如果订单金额大于200则减免50元。如果今天是用户的生日is_birthdaytrue则额外赠送100积分points。4.1 定义规则与构建引擎首先我们创建规则并将其添加到引擎中。// main.cpp #include RuleEngine.h #include Fact.h #include iostream #include memory int main() { RuleEngine engine; // 规则1: VIP且金额100打8折 auto rule1 std::make_sharedRule(vip_discount, 10, [](Fact fact) { double amount fact.getdouble(amount); amount * 0.8; fact.set(amount, amount); std::cout [规则 vip_discount] 应用 金额变为: amount std::endl; }); rule1-addCondition([](const Fact fact) { return fact.has(is_vip) fact.getbool(is_vip) true; }); rule1-addCondition([](const Fact fact) { return fact.has(amount) fact.getdouble(amount) 100.0; }); engine.addRule(rule1); // 规则2: 金额200减50 auto rule2 std::make_sharedRule(amount_discount, 5, [](Fact fact) { double amount fact.getdouble(amount); amount - 50.0; fact.set(amount, amount); std::cout [规则 amount_discount] 应用 金额变为: amount std::endl; }); rule2-addCondition([](const Fact fact) { return fact.has(amount) fact.getdouble(amount) 200.0; }); engine.addRule(rule2); // 规则3: 生日赠积分 auto rule3 std::make_sharedRule(birthday_points, 1, [](Fact fact) { int points fact.has(points) ? fact.getint(points) : 0; points 100; fact.set(points, points); std::cout [规则 birthday_points] 应用 积分变为: points std::endl; }); rule3-addCondition([](const Fact fact) { return fact.has(is_birthday) fact.getbool(is_birthday) true; }); engine.addRule(rule3); // 测试用例1: VIP用户金额250非生日 std::cout \n 测试用例1: VIP 250元 非生日 std::endl; Fact fact1; fact1.set(is_vip, true); fact1.set(amount, 250.0); fact1.set(is_birthday, false); engine.execute(fact1); std::cout 最终金额: fact1.getdouble(amount) std::endl; if (fact1.has(points)) { std::cout 最终积分: fact1.getint(points) std::endl; } // 测试用例2: 非VIP用户金额300生日 std::cout \n 测试用例2: 非VIP 300元 生日 std::endl; Fact fact2; fact2.set(is_vip, false); fact2.set(amount, 300.0); fact2.set(is_birthday, true); engine.execute(fact2); std::cout 最终金额: fact2.getdouble(amount) std::endl; std::cout 最终积分: fact2.getint(points) std::endl; return 0; }4.2 编译与运行使用CMake或直接命令行编译。确保你的编译器支持C17因为使用了std::optional和std::any。# 假设文件结构为 # project/ # ├── CMakeLists.txt # ├── main.cpp # ├── Fact.h # ├── Rule.h # ├── RuleEngine.h # └── Types.h # 使用CMake mkdir build cd build cmake .. make ./simple_rule_engine # 或者直接使用g/clang g -stdc17 -o simple_rule_engine main.cpp ./simple_rule_engine运行上述程序你会看到类似以下的输出 测试用例1: VIP 250元 非生日 [规则 vip_discount] 应用 金额变为: 200 [规则 amount_discount] 应用 金额变为: 150 最终金额: 150 最终积分: 0 测试用例2: 非VIP 300元 生日 [规则 amount_discount] 应用 金额变为: 250 [规则 birthday_points] 应用 积分变为: 100 最终金额: 250 最终积分: 100结果分析测试用例1满足了规则1VIP100和规则2200。由于规则1优先级(10)高于规则2(5)所以先执行8折金额从250变为200再执行减50最终为150。规则3不满足。测试用例2不满足规则1非VIP满足规则2200和规则3生日。按优先级执行规则2减50至250再执行规则3加100积分。这个简单的例子已经展示了规则引擎的核心威力业务逻辑规则与执行引擎分离规则可以独立地增删改而无需修改核心代码。5. 性能优化与高级特性探讨一个基础的引擎跑起来后我们肯定会关心它的性能和扩展性。下面分享几个我在实际项目中踩过坑后总结的优化方向。5.1 优化匹配效率引入Rete算法思想当规则数量达到数百甚至上千时遍历所有规则评估条件会成为性能瓶颈。工业级规则引擎如Drools的核心是Rete算法。我们不必实现完整的Rete但可以借鉴其“共享节点”和“索引”的思想进行优化。核心思路不要每次都用完整的事实去匹配所有规则的所有条件。而是建立条件与规则的索引关系。条件分解将每个规则的条件列表拆分成独立的原子条件如age 18,type VIP。建立条件到规则的映射维护一个哈希表键是条件本身的某种签名例如条件涉及的属性名和操作符拼接成的字符串值是对应包含该条件的规则列表。增量匹配当一个新事实到来或事实的某个属性改变时我们只检查那些与该属性相关的原子条件。如果一个原子条件被满足我们就去通知依赖它的规则。规则内部维护一个计数器记录有多少个条件已被满足。当所有条件都满足时该规则才进入匹配集。这是一个简化的实现示意// 原子条件 struct AtomicCondition { std::string key; // 事实属性名如 age std::functionbool(const std::any) evaluator; // 评估函数 std::string signature; // 用于索引的签名如 age_gt_18 }; class OptimizedRuleEngine { // 映射属性名 - 涉及该属性的原子条件列表 std::unordered_mapstd::string, std::vectorstd::shared_ptrAtomicCondition conditionIndex_; // 映射原子条件签名 - 依赖该条件的规则列表 std::unordered_mapstd::string, std::vectorstd::weak_ptrRule conditionToRuleMap_; // 规则内部状态记录已满足的条件数 // ... 更复杂的状态管理 public: void onFactUpdate(const std::string key, const std::any value) { // 查找哪些原子条件涉及这个key auto it conditionIndex_.find(key); if (it ! conditionIndex_.end()) { for (auto cond : it-second) { bool newResult cond-evaluator(value); // 如果条件结果发生变化通知所有依赖它的规则更新状态 updateRuleState(cond-signature, newResult); } } } // ... 其他方法 };这种优化在规则和条件很多但每次事实变化只涉及少量属性时性能提升是数量级的。当然实现复杂度也大大增加需要精心管理规则的状态激活、未激活、已触发等。5.2 增强表达能力支持复合条件AND/OR/NOT我们之前的规则只支持条件的“与”AND。在实际业务中“或”OR和“非”NOT也很常见。我们可以通过定义组合条件Composite Condition来支持。class CompositeCondition : public Condition { public: enum class LogicOp { AND, OR, NOT }; CompositeCondition(LogicOp op) : op_(op) {} void addChild(Condition cond) { children_.push_back(std::move(cond)); } bool evaluate(const Fact fact) const override { switch (op_) { case LogicOp::AND: for (const auto child : children_) { if (!child(fact)) return false; } return true; case LogicOp::OR: for (const auto child : children_) { if (child(fact)) return true; } return false; case LogicOp::NOT: // NOT通常只有一个子条件 return !children_[0](fact); default: return false; } } private: LogicOp op_; std::vectorCondition children_; }; // 使用示例创建一个 (A AND B) OR C 的条件 auto cond_and std::make_sharedCompositeCondition(CompositeCondition::LogicOp::AND); cond_and-addChild([](const Fact f){return f.getint(A) 0;}); cond_and-addChild([](const Fact f){return f.getstd::string(B) yes;}); auto cond_or std::make_sharedCompositeCondition(CompositeCondition::LogicOp::OR); cond_or-addChild(cond_and); cond_or-addChild([](const Fact f){return f.getbool(C) true;}); rule-addCondition(cond_or);通过组合模式我们可以构建出任意复杂的逻辑表达式树。这极大地增强了规则的表现力。5.3 规则持久化与动态加载一个实用的规则引擎需要支持从外部如数据库、配置文件加载规则并在运行时更新。这涉及到规则的序列化与反序列化。我们可以定义一种简单的描述语言比如JSON或XML来描述规则。// rule.json [ { id: vip_discount, priority: 10, conditions: [ { type: comparison, key: is_vip, op: , value: true }, { type: comparison, key: amount, op: , value: 100.0 } ], action: { type: script, content: fact[amount] fact[amount] * 0.8; } } ]然后在C端我们需要一个解析器Parser来读取这个JSON并将其转换为我们内部的Rule对象。对于action中的脚本简单的做法是预定义一些动作模板如“乘以系数”、“增加固定值”复杂的话可能需要集成一个轻量级的脚本引擎如Lua。这里的安全性和性能需要仔细权衡。直接eval字符串脚本在C中非常危险且低效。更常见的做法是将动作也定义为可注册的函数在JSON中只引用函数名和参数。// 注册动作工厂 std::unordered_mapstd::string, std::functionAction(const nlohmann::json) actionRegistry; actionRegistry[multiply] [](const nlohmann::json j) - Action { double factor j[factor]; std::string key j[key]; return [factor, key](Fact fact) { fact.set(key, fact.getdouble(key) * factor); }; }; // 解析时根据type找到对应的工厂函数创建Action6. 常见问题、踩坑记录与排查技巧在实际将这套引擎集成到项目中时我遇到了不少问题。这里把典型的几个列出来希望能帮你避坑。6.1 问题一std::any的类型安全与性能陷阱症状运行时偶尔抛出std::bad_any_cast异常或者在性能分析中发现get操作耗时占比很高。根因std::any在存储和读取时需要进行类型擦除和类型恢复涉及动态类型检查有一定开销。如果频繁存取会成为热点。此外如果外部传入的数据类型与预期不符就会抛出异常。解决方案使用std::variant替代如果事实中可能的数据类型是有限、可枚举的比如int,double,string,bool那么std::variant是更好的选择。它提供编译期类型安全访问效率也更高通过std::visit。using FactValue std::variantint, double, std::string, bool; std::unordered_mapstd::string, FactValue data_;前置类型校验在set和get时如果可能增加类型断言或日志。或者提供getAsT模板函数在转换失败时返回默认值或std::optional而不是抛出异常。领域特定Fact类对于确定的业务场景直接定义一个包含具体字段的struct作为Fact这是性能最好、最安全的方式但牺牲了通用性。6.2 问题二规则执行顺序与副作用症状规则执行的结果不符合预期尤其是当多条规则修改同一个事实属性时。根因如我们之前提到的我们的简单引擎采用“先全部匹配再按优先级执行”的策略。如果高优先级规则的动作修改了某个属性而这个属性又是低优先级规则的匹配条件那么低优先级规则在匹配阶段使用的是旧的事实状态但执行时事实已经被改变。这可能导致逻辑错误。解决方案根据业务需求选择不同的冲突消解和执行策略。需求A规则间独立互不影响在execute阶段为每个匹配的规则传入一个事实的副本或者确保规则动作不修改影响其他规则匹配的关键属性。需求B需要前向链推理即一个规则的执行结果可能触发另一个规则实现一个议程Agenda和工作内存Working Memory。当一条规则执行后引擎需要重新检查所有规则或受影响的规则的匹配状态将新激活的规则加入议程。这会更复杂但更强大。Drools默认就采用这种模式。6.3 问题三条件表达式的复杂度与调试困难症状规则逻辑复杂后难以判断为什么某条规则没有触发或者触发了不该触发的规则。根因条件以Lambda或函数对象的形式存在在调试时看不到其逻辑描述。解决方案为条件添加描述信息修改Condition类型使其不仅包含可调用对象还包含一个字符串描述。struct DescriptiveCondition { std::string description; std::functionbool(const Fact) evaluator; bool evaluate(const Fact f) const { bool result evaluator(f); // 可以在这里输出调试日志std::cout description result std::endl; return result; } };实现规则跟踪日志在引擎的execute函数中为每条规则的评估过程输出详细的日志包括规则ID、每个条件的评估结果。这在大规模规则调试时是救命稻草。单元测试为每一条业务规则编写独立的单元测试用各种边界值的事实去验证其行为。这是保证规则正确性的最有效手段。6.4 问题四在多线程环境下使用症状程序在多线程并发执行engine.execute(fact)时出现数据竞争或崩溃。根因我们的RuleEngine和Rule对象内部有状态规则集合。如果多个线程同时调用addRule和execute或者execute内部修改了规则状态比如在优化版本中就需要线程安全保护。解决方案只读共享如果规则在初始化后就不再改变这是常见用法那么execute函数是线程安全的因为只读操作不需要锁。确保addRule在程序启动的单线程阶段完成。读写锁如果规则需要热更新那么对规则容器的访问需要使用读写锁如std::shared_mutex。addRule/removeRule需要独占锁execute可以共享锁。注意这可能会影响性能。副本策略每个工作线程持有引擎的一个副本。主线程在更新规则后将新规则集同步给所有工作线程。这避免了锁但增加了内存和同步开销。实现一个C规则引擎从玩具到生产可用最大的挑战往往不在于算法本身而在于如何将其优雅、高效、安全地集成到现有的C工程体系中并处理好边界情况。上面的这些坑都是我实实在在踩过的。希望这份详细的实现解析和避坑指南能帮你更快地构建出适合自己项目的那个“简单”而“强大”的规则引擎核心。
C++规则引擎实现：从条件-动作模型到高性能业务逻辑解耦
发布时间：2026/7/9 20:49:21
1. 项目概述为什么用C写规则引擎最近在社区里看到不少关于规则引擎的讨论很多朋友都在用Java的Drools或者Python的某些库。但总有人问“C性能这么好为什么没有像样的规则引擎” 甚至有人觉得C这种“硬核”语言是不是天生就不适合做这种需要灵活性的东西作为一个在C和业务系统里摸爬滚打了十来年的老码农我想说不是没有而是大家没找对路子或者被“动态类型”、“运行时编译”这些词吓住了。实际上用C实现一个核心的、高效的规则引擎不仅完全可行而且在某些对性能有极致要求的场景下比如高频交易、实时风控、游戏逻辑服务器它甚至是唯一的选择。这个项目的目标就是抛开那些庞大的框架从最本质的“条件-动作”模型出发用C打造一个轻量、快速、易于理解和集成的简单规则引擎。它不追求像Drools那样复杂的DSL领域特定语言而是强调在C的强类型和高效编译的框架内提供清晰的规则定义和快速的规则匹配能力。如果你正在为一个C服务添加灵活的业务规则配置或者想深入理解规则引擎的内核原理那么这个实践会给你带来不少启发。2. 核心设计思路在静态类型中寻求动态表达2.1 规则引擎的本质与C的适配性规则引擎的核心抽象来看就是一个“匹配-执行”系统。它接收一个包含各种属性的事实Fact与一系列预先定义好的规则Rule进行匹配然后执行匹配成功的规则所对应的动作Action。大家常说的“动态”主要体现在规则可以在不重启服务的情况下被加载、更新以及规则条件本身可以灵活组合。C是静态强类型语言这看似与“动态”矛盾但实际上我们可以通过设计来化解。我们不需要在运行时去动态解析一个字符串形式的表达式虽然也可以但复杂且易错而是可以利用C的编译期多态模板和运行时多态继承、虚函数来构建一个类型安全且高效的模型。关键思路是将规则的条件判断逻辑封装成可调用对象函数、函数对象、Lambda表达式而规则本身则管理这些条件与动作的配对关系。这样规则的“动态性”就体现在我们可以动态地组装、替换这些可调用对象而不是动态地解析代码。2.2 我们的轻量级规则引擎架构设计基于以上思路我设计了一个三层的核心架构它足够简单也足够表达大多数业务规则场景事实Fact这是一个承载数据的容器。最简单的实现就是一个std::unordered_mapstd::string, std::any用来存储键值对。但为了类型安全和性能更好的做法是定义一个通用的Fact基类或者使用std::variant来容纳有限的几种数据类型。在我们的简单实现中为了直观我会先使用std::any的map然后讨论其优化方向。条件Condition这是一个可调用对象接收一个Fact作为参数返回一个bool值表示该事实是否满足此条件。它可以是普通函数、函数指针、std::function或者是一个重载了operator()的类仿函数。这是实现灵活性的关键。规则Rule与动作Action一条规则由一个唯一标识ID、一个优先级Priority、一组条件Conditions和一个动作Action组成。动作也是一个可调用对象接收匹配的Fact作为参数执行具体的业务逻辑。规则引擎RuleEngine则管理一个规则集合并提供“匹配-执行”的入口。这个架构的精妙之处在于条件和动作的具体逻辑完全由使用者以C代码的形式提供引擎只负责组织和调度。这既保证了性能没有解释执行的开销又通过标准库组件如std::function提供了足够的运行时灵活性。注意使用std::any虽然灵活但存在类型转换的安全隐患和一定的性能开销。在生产环境中如果事实的数据类型是可枚举的强烈建议使用std::variant或者为特定领域定义具体的Fact结构体。这里为了演示通用性我们仍从std::any开始。3. 核心细节解析与关键实现3.1 事实Fact的封装与数据存取我们首先实现一个最简易的Fact类。它的核心职责是存储和提供类型安全的数据访问。// Fact.h #include string #include any #include unordered_map #include stdexcept class Fact { public: Fact() default; // 设置事实属性 templatetypename T void set(const std::string key, const T value) { data_[key] value; } // 获取事实属性如果类型不匹配或键不存在则抛出异常 templatetypename T T get(const std::string key) const { auto it data_.find(key); if (it data_.end()) { throw std::runtime_error(Fact key not found: key); } try { return std::any_castT(it-second); } catch (const std::bad_any_cast e) { throw std::runtime_error(Fact type mismatch for key: key . e.what()); } } // 检查是否存在某个键 bool has(const std::string key) const { return data_.find(key) ! data_.end(); } private: std::unordered_mapstd::string, std::any data_; };这个实现非常直接但它暴露了两个问题1)std::any_cast失败会抛出异常在性能关键路径上可能需要避免2) 错误处理不够友好。我们可以提供一个更安全的getOptional版本。// 新增一个安全获取的方法返回std::optional templatetypename T std::optionalT getOptional(const std::string key) const { auto it data_.find(key); if (it data_.end()) { return std::nullopt; } const std::any value it-second; if (value.type() ! typeid(T)) { return std::nullopt; } return std::any_castT(value); }3.2 条件Condition与动作Action的类型定义为了最大的灵活性我们将条件和动作都定义为std::function。这样用户可以用Lambda、绑定后的成员函数、普通函数等任何可调用对象来定义逻辑。// Types.h #include functional #include memory class Fact; // 条件类型接受一个Fact返回是否满足 using Condition std::functionbool(const Fact); // 动作类型接受一个Fact执行操作 using Action std::functionvoid(Fact); // 注意Action可能修改Fact使用std::function的好处是接口统一且易于使用。但这里有一个重要的性能考量std::function可能涉及堆内存分配如果捕获的Lambda过大和虚函数调用。对于极端性能场景可以考虑使用模板参数来接受可调用对象但这会使得规则引擎本身的类型变得复杂。在我们的简单引擎中std::function的通用性和便利性是首要的。3.3 规则Rule类的实现一条规则需要包含名称、优先级、一组条件和对应的动作。我们使用std::vectorCondition来存储多个条件它们之间是“与”AND的关系。如果需要“或”OR关系可以通过组合条件来实现。// Rule.h #include string #include vector #include Types.h class Rule { public: Rule(const std::string id, int priority, Action action) : id_(id), priority_(priority), action_(std::move(action)) {} // 添加一个条件 void addCondition(Condition cond) { conditions_.push_back(std::move(cond)); } // 评估规则所有条件都满足则返回true bool evaluate(const Fact fact) const { for (const auto cond : conditions_) { if (!cond(fact)) { return false; } } return true; // 如果没有条件默认视为满足 } // 执行规则的动作 void execute(Fact fact) const { if (action_) { action_(fact); } } // 获取规则ID和优先级用于排序和冲突消解 const std::string getId() const { return id_; } int getPriority() const { return priority_; } private: std::string id_; int priority_; // 数字越大优先级越高 std::vectorCondition conditions_; Action action_; };这里的设计有几个要点条件评估evaluate函数顺序检查所有条件一旦某个条件不满足立即返回false。这种短路求值short-circuit evaluation是高效的。优先级我们引入了一个简单的整数优先级字段。当多条规则同时被触发时引擎可以根据优先级来决定执行顺序这是解决规则冲突Conflict Resolution最基础的策略。规则的构建我们提供了流畅的接口可以方便地添加条件。例如rule.addCondition([](const Fact f){ return f.getint(age) 18; });3.4 规则引擎RuleEngine的核心调度引擎负责管理所有规则并对外提供execute接口传入一个事实引擎负责找出所有匹配的规则并执行它们的动作。// RuleEngine.h #include vector #include algorithm #include memory #include Rule.h class RuleEngine { public: void addRule(std::shared_ptrRule rule) { rules_.push_back(rule); // 添加后可以按优先级排序方便后续查找 std::sort(rules_.begin(), rules_.end(), [](const std::shared_ptrRule a, const std::shared_ptrRule b) { return a-getPriority() b-getPriority(); // 降序优先级高的在前 }); } // 执行所有匹配的规则 void execute(Fact fact) { std::vectorstd::shared_ptrRule matchedRules; // 1. 匹配阶段找出所有满足条件的规则 for (const auto rule : rules_) { if (rule-evaluate(fact)) { matchedRules.push_back(rule); } } // 2. 冲突消解阶段这里我们简单地按优先级执行 // 更复杂的策略可能包括优先级、特殊性、顺序等 for (const auto rule : matchedRules) { rule-execute(fact); // 注意执行一个规则的动作可能会修改fact从而影响后续规则的匹配。 // 这是“前向链”Forward Chaining推理的一种简单形式。 // 如果你不希望动作影响后续匹配需要在设计动作时注意或者复制一份fact。 } } // 清空所有规则 void clear() { rules_.clear(); } private: std::vectorstd::shared_ptrRule rules_; };这个execute函数实现了最简单的“识别-执行”循环。它有两个关键阶段匹配Match遍历所有规则检查条件。这是一个O(N)的操作。如果规则数量庞大成千上万这里会成为性能瓶颈。优化方法包括将规则按条件中涉及的属性进行分组索引类似于数据库的索引可以大幅减少需要评估的规则数量。这是我们后续可以深入优化的点。执行Act按优先级顺序执行所有匹配规则的动作。这里我们采用了“优先级排序”作为冲突消解策略。注意动作的执行可能会改变事实本身这可能导致之前已经匹配过的规则不再匹配或者未匹配的规则新被匹配。我们这个简单实现采用的是“一次性匹配然后顺序执行”的策略动作对事实的修改不会触发对剩余规则的重新匹配。这是一种设计选择如果你需要实现类似Drools的“前向链”需要在每个动作执行后重新进行匹配这会导致更复杂的控制流。4. 从零开始一个完整的实战示例让我们用一个具体的场景来串联以上所有组件实现一个简单的用户折扣计算规则引擎。规则如下如果用户是VIPis_viptrue且订单金额amount大于100则打8折。如果订单金额大于200则减免50元。如果今天是用户的生日is_birthdaytrue则额外赠送100积分points。4.1 定义规则与构建引擎首先我们创建规则并将其添加到引擎中。// main.cpp #include RuleEngine.h #include Fact.h #include iostream #include memory int main() { RuleEngine engine; // 规则1: VIP且金额100打8折 auto rule1 std::make_sharedRule(vip_discount, 10, [](Fact fact) { double amount fact.getdouble(amount); amount * 0.8; fact.set(amount, amount); std::cout [规则 vip_discount] 应用 金额变为: amount std::endl; }); rule1-addCondition([](const Fact fact) { return fact.has(is_vip) fact.getbool(is_vip) true; }); rule1-addCondition([](const Fact fact) { return fact.has(amount) fact.getdouble(amount) 100.0; }); engine.addRule(rule1); // 规则2: 金额200减50 auto rule2 std::make_sharedRule(amount_discount, 5, [](Fact fact) { double amount fact.getdouble(amount); amount - 50.0; fact.set(amount, amount); std::cout [规则 amount_discount] 应用 金额变为: amount std::endl; }); rule2-addCondition([](const Fact fact) { return fact.has(amount) fact.getdouble(amount) 200.0; }); engine.addRule(rule2); // 规则3: 生日赠积分 auto rule3 std::make_sharedRule(birthday_points, 1, [](Fact fact) { int points fact.has(points) ? fact.getint(points) : 0; points 100; fact.set(points, points); std::cout [规则 birthday_points] 应用 积分变为: points std::endl; }); rule3-addCondition([](const Fact fact) { return fact.has(is_birthday) fact.getbool(is_birthday) true; }); engine.addRule(rule3); // 测试用例1: VIP用户金额250非生日 std::cout \n 测试用例1: VIP 250元 非生日 std::endl; Fact fact1; fact1.set(is_vip, true); fact1.set(amount, 250.0); fact1.set(is_birthday, false); engine.execute(fact1); std::cout 最终金额: fact1.getdouble(amount) std::endl; if (fact1.has(points)) { std::cout 最终积分: fact1.getint(points) std::endl; } // 测试用例2: 非VIP用户金额300生日 std::cout \n 测试用例2: 非VIP 300元 生日 std::endl; Fact fact2; fact2.set(is_vip, false); fact2.set(amount, 300.0); fact2.set(is_birthday, true); engine.execute(fact2); std::cout 最终金额: fact2.getdouble(amount) std::endl; std::cout 最终积分: fact2.getint(points) std::endl; return 0; }4.2 编译与运行使用CMake或直接命令行编译。确保你的编译器支持C17因为使用了std::optional和std::any。# 假设文件结构为 # project/ # ├── CMakeLists.txt # ├── main.cpp # ├── Fact.h # ├── Rule.h # ├── RuleEngine.h # └── Types.h # 使用CMake mkdir build cd build cmake .. make ./simple_rule_engine # 或者直接使用g/clang g -stdc17 -o simple_rule_engine main.cpp ./simple_rule_engine运行上述程序你会看到类似以下的输出 测试用例1: VIP 250元 非生日 [规则 vip_discount] 应用 金额变为: 200 [规则 amount_discount] 应用 金额变为: 150 最终金额: 150 最终积分: 0 测试用例2: 非VIP 300元 生日 [规则 amount_discount] 应用 金额变为: 250 [规则 birthday_points] 应用 积分变为: 100 最终金额: 250 最终积分: 100结果分析测试用例1满足了规则1VIP100和规则2200。由于规则1优先级(10)高于规则2(5)所以先执行8折金额从250变为200再执行减50最终为150。规则3不满足。测试用例2不满足规则1非VIP满足规则2200和规则3生日。按优先级执行规则2减50至250再执行规则3加100积分。这个简单的例子已经展示了规则引擎的核心威力业务逻辑规则与执行引擎分离规则可以独立地增删改而无需修改核心代码。5. 性能优化与高级特性探讨一个基础的引擎跑起来后我们肯定会关心它的性能和扩展性。下面分享几个我在实际项目中踩过坑后总结的优化方向。5.1 优化匹配效率引入Rete算法思想当规则数量达到数百甚至上千时遍历所有规则评估条件会成为性能瓶颈。工业级规则引擎如Drools的核心是Rete算法。我们不必实现完整的Rete但可以借鉴其“共享节点”和“索引”的思想进行优化。核心思路不要每次都用完整的事实去匹配所有规则的所有条件。而是建立条件与规则的索引关系。条件分解将每个规则的条件列表拆分成独立的原子条件如age 18,type VIP。建立条件到规则的映射维护一个哈希表键是条件本身的某种签名例如条件涉及的属性名和操作符拼接成的字符串值是对应包含该条件的规则列表。增量匹配当一个新事实到来或事实的某个属性改变时我们只检查那些与该属性相关的原子条件。如果一个原子条件被满足我们就去通知依赖它的规则。规则内部维护一个计数器记录有多少个条件已被满足。当所有条件都满足时该规则才进入匹配集。这是一个简化的实现示意// 原子条件 struct AtomicCondition { std::string key; // 事实属性名如 age std::functionbool(const std::any) evaluator; // 评估函数 std::string signature; // 用于索引的签名如 age_gt_18 }; class OptimizedRuleEngine { // 映射属性名 - 涉及该属性的原子条件列表 std::unordered_mapstd::string, std::vectorstd::shared_ptrAtomicCondition conditionIndex_; // 映射原子条件签名 - 依赖该条件的规则列表 std::unordered_mapstd::string, std::vectorstd::weak_ptrRule conditionToRuleMap_; // 规则内部状态记录已满足的条件数 // ... 更复杂的状态管理 public: void onFactUpdate(const std::string key, const std::any value) { // 查找哪些原子条件涉及这个key auto it conditionIndex_.find(key); if (it ! conditionIndex_.end()) { for (auto cond : it-second) { bool newResult cond-evaluator(value); // 如果条件结果发生变化通知所有依赖它的规则更新状态 updateRuleState(cond-signature, newResult); } } } // ... 其他方法 };这种优化在规则和条件很多但每次事实变化只涉及少量属性时性能提升是数量级的。当然实现复杂度也大大增加需要精心管理规则的状态激活、未激活、已触发等。5.2 增强表达能力支持复合条件AND/OR/NOT我们之前的规则只支持条件的“与”AND。在实际业务中“或”OR和“非”NOT也很常见。我们可以通过定义组合条件Composite Condition来支持。class CompositeCondition : public Condition { public: enum class LogicOp { AND, OR, NOT }; CompositeCondition(LogicOp op) : op_(op) {} void addChild(Condition cond) { children_.push_back(std::move(cond)); } bool evaluate(const Fact fact) const override { switch (op_) { case LogicOp::AND: for (const auto child : children_) { if (!child(fact)) return false; } return true; case LogicOp::OR: for (const auto child : children_) { if (child(fact)) return true; } return false; case LogicOp::NOT: // NOT通常只有一个子条件 return !children_[0](fact); default: return false; } } private: LogicOp op_; std::vectorCondition children_; }; // 使用示例创建一个 (A AND B) OR C 的条件 auto cond_and std::make_sharedCompositeCondition(CompositeCondition::LogicOp::AND); cond_and-addChild([](const Fact f){return f.getint(A) 0;}); cond_and-addChild([](const Fact f){return f.getstd::string(B) yes;}); auto cond_or std::make_sharedCompositeCondition(CompositeCondition::LogicOp::OR); cond_or-addChild(cond_and); cond_or-addChild([](const Fact f){return f.getbool(C) true;}); rule-addCondition(cond_or);通过组合模式我们可以构建出任意复杂的逻辑表达式树。这极大地增强了规则的表现力。5.3 规则持久化与动态加载一个实用的规则引擎需要支持从外部如数据库、配置文件加载规则并在运行时更新。这涉及到规则的序列化与反序列化。我们可以定义一种简单的描述语言比如JSON或XML来描述规则。// rule.json [ { id: vip_discount, priority: 10, conditions: [ { type: comparison, key: is_vip, op: , value: true }, { type: comparison, key: amount, op: , value: 100.0 } ], action: { type: script, content: fact[amount] fact[amount] * 0.8; } } ]然后在C端我们需要一个解析器Parser来读取这个JSON并将其转换为我们内部的Rule对象。对于action中的脚本简单的做法是预定义一些动作模板如“乘以系数”、“增加固定值”复杂的话可能需要集成一个轻量级的脚本引擎如Lua。这里的安全性和性能需要仔细权衡。直接eval字符串脚本在C中非常危险且低效。更常见的做法是将动作也定义为可注册的函数在JSON中只引用函数名和参数。// 注册动作工厂 std::unordered_mapstd::string, std::functionAction(const nlohmann::json) actionRegistry; actionRegistry[multiply] [](const nlohmann::json j) - Action { double factor j[factor]; std::string key j[key]; return [factor, key](Fact fact) { fact.set(key, fact.getdouble(key) * factor); }; }; // 解析时根据type找到对应的工厂函数创建Action6. 常见问题、踩坑记录与排查技巧在实际将这套引擎集成到项目中时我遇到了不少问题。这里把典型的几个列出来希望能帮你避坑。6.1 问题一std::any的类型安全与性能陷阱症状运行时偶尔抛出std::bad_any_cast异常或者在性能分析中发现get操作耗时占比很高。根因std::any在存储和读取时需要进行类型擦除和类型恢复涉及动态类型检查有一定开销。如果频繁存取会成为热点。此外如果外部传入的数据类型与预期不符就会抛出异常。解决方案使用std::variant替代如果事实中可能的数据类型是有限、可枚举的比如int,double,string,bool那么std::variant是更好的选择。它提供编译期类型安全访问效率也更高通过std::visit。using FactValue std::variantint, double, std::string, bool; std::unordered_mapstd::string, FactValue data_;前置类型校验在set和get时如果可能增加类型断言或日志。或者提供getAsT模板函数在转换失败时返回默认值或std::optional而不是抛出异常。领域特定Fact类对于确定的业务场景直接定义一个包含具体字段的struct作为Fact这是性能最好、最安全的方式但牺牲了通用性。6.2 问题二规则执行顺序与副作用症状规则执行的结果不符合预期尤其是当多条规则修改同一个事实属性时。根因如我们之前提到的我们的简单引擎采用“先全部匹配再按优先级执行”的策略。如果高优先级规则的动作修改了某个属性而这个属性又是低优先级规则的匹配条件那么低优先级规则在匹配阶段使用的是旧的事实状态但执行时事实已经被改变。这可能导致逻辑错误。解决方案根据业务需求选择不同的冲突消解和执行策略。需求A规则间独立互不影响在execute阶段为每个匹配的规则传入一个事实的副本或者确保规则动作不修改影响其他规则匹配的关键属性。需求B需要前向链推理即一个规则的执行结果可能触发另一个规则实现一个议程Agenda和工作内存Working Memory。当一条规则执行后引擎需要重新检查所有规则或受影响的规则的匹配状态将新激活的规则加入议程。这会更复杂但更强大。Drools默认就采用这种模式。6.3 问题三条件表达式的复杂度与调试困难症状规则逻辑复杂后难以判断为什么某条规则没有触发或者触发了不该触发的规则。根因条件以Lambda或函数对象的形式存在在调试时看不到其逻辑描述。解决方案为条件添加描述信息修改Condition类型使其不仅包含可调用对象还包含一个字符串描述。struct DescriptiveCondition { std::string description; std::functionbool(const Fact) evaluator; bool evaluate(const Fact f) const { bool result evaluator(f); // 可以在这里输出调试日志std::cout description result std::endl; return result; } };实现规则跟踪日志在引擎的execute函数中为每条规则的评估过程输出详细的日志包括规则ID、每个条件的评估结果。这在大规模规则调试时是救命稻草。单元测试为每一条业务规则编写独立的单元测试用各种边界值的事实去验证其行为。这是保证规则正确性的最有效手段。6.4 问题四在多线程环境下使用症状程序在多线程并发执行engine.execute(fact)时出现数据竞争或崩溃。根因我们的RuleEngine和Rule对象内部有状态规则集合。如果多个线程同时调用addRule和execute或者execute内部修改了规则状态比如在优化版本中就需要线程安全保护。解决方案只读共享如果规则在初始化后就不再改变这是常见用法那么execute函数是线程安全的因为只读操作不需要锁。确保addRule在程序启动的单线程阶段完成。读写锁如果规则需要热更新那么对规则容器的访问需要使用读写锁如std::shared_mutex。addRule/removeRule需要独占锁execute可以共享锁。注意这可能会影响性能。副本策略每个工作线程持有引擎的一个副本。主线程在更新规则后将新规则集同步给所有工作线程。这避免了锁但增加了内存和同步开销。实现一个C规则引擎从玩具到生产可用最大的挑战往往不在于算法本身而在于如何将其优雅、高效、安全地集成到现有的C工程体系中并处理好边界情况。上面的这些坑都是我实实在在踩过的。希望这份详细的实现解析和避坑指南能帮你更快地构建出适合自己项目的那个“简单”而“强大”的规则引擎核心。
