drools (业务逻辑引擎)招募

发布人:仓颉技术交流平台官方
分类:编程框架与基础设施 / 规则引擎

现招募开发者,基于仓颉语言构建一个规则引擎的核心功能原型。本项目灵感来源于成熟的Java规则引擎项目(如Apache KIE Drools),但目标并非简单移植,而是希望利用仓颉语言在性能、安全性和并发模型上的先天优势,设计并实现一个具有创新性的、高性能的规则匹配与执行内核。

等待接取
2025-11-20
22

悬赏内容

招募内容

1. 项目概述与愿景

本项目是一项旨在探索系统级编程语言在现代规则引擎领域应用的非营利性开源项目。我们将使用仓颉语言,从头开始设计并实现一个高性能、内存安全、并发友好的规则引擎核心。其愿景是构建一个可作为未来复杂决策系统(如实时风控、智能规划、事件流处理)坚实基石的高质量参考实现

本项目不追求功能的全面性,而是聚焦于核心算法的极致优化与工程实现的严谨性。我们相信,一个架构清晰、代码可读性强、测试完备的核心模块,其价值远胜于一个庞大但臃肿的系统。

2. 核心模块与技术规格

项目将分解为以下几个核心模块,贡献者可选择一个或多个模块深入参与。

模块一:规则语义模型与类型系统 (Rule Semantic Model & Type System)

  • 目标:​ 定义强类型的、可在编译期进行大量验证的规则内部表示(IR)。

  • 详细内容:

    • 设计仓颉结构体(Struct)或类(Class)来表示规则(Rule)、模式(Pattern)、条件(Condition)、动作(Action)。

    • 实现一个高效的属性访问系统,用于在规则执行时解析和访问事实对象(Fact)的字段。

    • 交付物示例:

    // 示例:仓颉语言代码(假设语法,体现强类型与内存安全概念)
    pub struct RuleId {
        id: String,
    }
    
    pub struct Pattern {
        object_type: TypeId,
        constraints: Vec<Box<dyn Constraint>>, // 约束 trait
    }
    
    pub struct Rule {
        id: RuleId,
        name: String,
        lhs: Vec<Pattern>, // Left-Hand Side (条件部分)
        rhs: Box<dyn RuleAction>, // Right-Hand Side (动作部分) Trait Object
        attributes: RuleAttributes, // 优先级、激活组等属性
    }
    
    pub trait RuleAction {
        fn execute(&self, session: &mut StatefulSession, facts: &[FactHandle]);
    }
    
    pub struct InsertAction {
        object: Box<dyn Any>, // 要插入的对象
    }
    impl RuleAction for InsertAction {
        fn execute(&self, session: &mut StatefulSession, _facts: &[FactHandle]) {
            session.insert(self.object.as_ref());
        }
    }

模块二:Rete规则网络编译器与运行时 (Rete Network Compiler & Runtime)

  • 目标:​ 实现经典Rete算法或其现代变种(如ReteOO),并针对仓颉语言的零成本抽象和所有权模型进行优化。

  • 详细内容:

    • 构建网络节点:AlphaNode、BetaNode、JoinNode、TerminalNode。

    • 实现高效的内存索引结构(如Hash索引),加速模式匹配。

    • 设计事实在网络中的传播机制,确保在并发场景下的正确性。

  • 交付物示例:

    // 示例:网络节点定义与匹配上下文
    pub trait NetworkNode {
        fn propagate(&self, context: &PropagationContext, wm: &WorkingMemory);
    }
    
    pub struct AlphaNode {
        field_index: usize,
        expected_value: ConstraintValue,
        successors: Vec<Rc<dyn NetworkNode>>,
    }
    
    pub struct PropagationContext {
        pub fact_handle: FactHandle,
        pub token: Option<Rc<Token>>, // 用于Beta节点的部分匹配
    }
    
    // 性能关键:使用高效集合类型存储匹配结果
    pub struct BetaMemory {
        left_memory: Vec<Rc<Token>>,
        right_memory: Vec<FactHandle>,
        // 使用 HashMap 等结构建立索引,避免全量遍历
        index: HashMap<Key, Vec<usize>>,
    }

模块三:规则会话管理与并发模型 (Session Management & Concurrency)

  • 目标:​ 提供线程安全、资源管理明确的规则会话接口。

  • 详细内容:

    • 实现无状态会话(StatelessSession)和有状态会话(StatefulSession)。

    • 设计FactHandle与底层事实对象的映射关系,安全地管理事实的生命周期。

    • 研究并应用仓颉的并发原语(如Arc/Mutex或更高级的锁),实现安全的并行规则执行。

  • 交付物示例:

    pub trait Session {
        fn insert<T: Any>(&mut self, object: T) -> FactHandle;
        fn fire_all_rules(&mut self) -> u32;
    }
    
    pub struct StatefulSession {
        rule_base: Arc<RuleBase>,
        working_memory: WorkingMemory,
        agenda: Agenda,
        // 使用线程安全的引用计数和互斥锁
        event_listeners: Arc<Mutex<Vec<Box<dyn RuleEventListener>>>>,
    }
    
    impl Session for StatefulSession {
        fn insert<T: Any>(&mut self, object: T) -> FactHandle {
            let handle = self.working_memory.insert(object);
            self.agenda.on_fact_inserted(handle, &self.working_memory);
            handle
        }
    }

3. 项目质量认证要求

所有贡献的代码必须通过以下质量关卡的验证,确保项目长期可维护性与技术卓越性。

质量维度

具体标准与验收要求

验证方法

架构与设计

1. 模块间依赖关系清晰,无循环依赖。
2. 关键数据结构与算法有独立的设计文档,阐述权衡(如为何选择Hash索引而非Tree索引)。
3. 遵循仓颉语言的最佳实践,有效利用所有权、生命周期等特性。

- 代码依赖关系图分析
- 设计文档评审
- 核心代码同行评审

代码质量

1. 通过项目的静态代码分析工具(如自定义的Clippy Lints)。
2. 所有公共API必须有完整的Doc注释,包含示例。
3. 错误处理规范,避免不可达的代码路径。

- 自动化CI流水线(ci lint
- 文档生成检查(cargo doc --document-private-items

测试覆盖率

1. 单元测试覆盖率 > 95%:针对所有公开函数和核心私有函数。
2. 集成测试:覆盖从规则解析到执行的端到端流程。
3. 性能基准测试:为Rete网络匹配、会话操作等提供基准测试,监控性能回归。

- 使用cargo tarpaulin或类似工具验证覆盖率
- 基准测试集成到CI,性能波动超过10%需报警

文档完备性

1. API文档:通过cargo doc生成,必须覆盖所有公共项。
2. 贡献者指南CONTRIBUTING.md):详细说明构建、测试、调试流程。
3. 架构决策记录(ADRs):记录重大技术决策的背景。

- 自动化检查文档生成是否成功
- 文档链接在PR模板中强制要求填写

持续集成(CI)流程:

每个Pull Request将自动触发以下流程,全部通过方可合并:

# 1. 格式检查
cargo fmt -- --check
# 2. 编译检查(包括正式版和调试版)
cargo check --all-features
cargo build --release
# 3. 静态分析
cargo clippy -- -D warnings
# 4. 测试套件与覆盖率检查
cargo test --all-features
cargo tarpaulin --ignore-tests --out Html
# 5. 基准测试(仅监控,不阻断)
cargo bench

相关附件

暂无附件

质量认证要求

交付件

NO

交付件描述

备注

1

三方库源代码

源代码

2

三方库测试方案和用例

测试用例和文档

3

用户手册,API文档,设计文档,license文档

 资料和文档

验收标准

1.功能

  1. 三方库必须有明确的功能;

  2. 如果参考对标库移值开发,功能与参考三方库保持一致。

2.资料

  1. Readme:包含简介,软件架构,目录结构,下载安装(编译构建),接口说明,使用示例,约束限制,开源协议,参与贡献等内容;

  2. Changelog,三方库版本需包含基本的修改说明。

3.标准遵从性(可选),三方库实现需满足对应协议或行业标准,举例

  1. appquth:支持对OAuth 的PKCE扩展;

  2. icu4j:支持unicode标准库,通用字符集ISO/IEC 10646。

4.性能目标

  1. 性能敏感三方库接口运行性能持平对标三方库

5.开源协议遵从,必须包含License文件

  1. 放置合适的开源License协议,建议Apache License Version 2.0;

  2. 引用或参考开源三方库,需遵从开源协议。

6.网络安全要求

  1. 满足基础的网络安全红线及隐私要求,符合安全编码规范。

过程质量要求

指标分类

指标名称

指标要求

度量工具

牵引 OR Must

代码度量

平均文件代码行

≤300 LOC

CMetricsPlus,CJMetric

Must

总文件重复率

C/C++≤4%;相比开源不劣化

CMetricsPlus,CJMetric

Must

源文件重复率

C/C++≤4%;相比开源不劣化

CMetricsPlus,CJMetric

Must

平均函数或方法代码行*

≤30  LOC

CMetricsPlus,CJMetric

Must

总代码重复率

C/C++≤10%;相比开源不劣化

CMetricsPlus,CJMetric

Must

源文件代码重复率

C/C++≤10%;相比开源不劣化

CMetricsPlus,CJMetric

Must

平均圈复杂度

≤5;相比开源不劣化

CMetricsPlus,CJMetric

Must

冗余代码

“0” 【2】;

CMetricsPlus,CJMetric

Must

不安全函数

NA

CMetricsPlus,CJMetric

Must

静态检查

编译告警

“0” 【2】

Compile工具

牵引

通用静态告警

“0” 【2】

Pclint plus,CJLINT

Must

开发者测试

DT用例密度(个/KLOC)

> 40

手工

牵引 

DT代码语句覆盖率

>=85%

Gcov,cjcov

牵引

DT代码分支覆盖率

>=50%

Gcov,cjcov

牵引

未做DT文件数

0

手工

牵引

问题解决率

遗留问题DI

整体<10

Issue

牵引 

遗留致命缺陷数(0)

0

Issue

Must

累计缺陷解决率

85%

Issue

牵引 

软件开发

每日构建成功率

100%

CI

牵引

测试评估

测试缺陷密度(/KLOC)

5-9

人工

牵引

测试用例密度(个/KLOC)

20-40

人工

牵引

初验用例自动化率

100%

CIDA

牵引 

HLT自动化用例比率

【85%,95%】

CIDA

牵引 

开源第三方(含构建工具)

开源片段引用

0(除例外备案类)

FOSSBOT+人工

Must

可信构建

二进制一致性

0(含可澄清)

人工

Mus