00-核心概念与快速预览

欢迎来到规则中心！本页面将帮助您快速理解规则引擎的核心思想、各个模块之间的关系以及系统的工作原理。

0. 一分钟理解规则中心

0.1 规则中心是什么

简单来说，规则中心就是系统的"智能筛选器"。

当您需要给设备推送内容时，系统需要知道：

哪些设备应该收到这个推送？
哪些设备不应该收到？

规则中心就是回答这个问题的。您只需要告诉系统"什么样的设备符合条件"，剩下的匹配工作由系统自动完成。

0.2 一个简单的例子

场景：您需要给"App Store渠道的设备"推送一个新版本APK。

没有规则中心时：

您需要手动整理所有App Store渠道设备的MAC地址
导入到任务推送系统
每次推送都要重复这个工作

有了规则中心后：

创建一条规则，条件设为"渠道 = App Store"
将规则绑定到任务推送业务
系统自动匹配，所有App Store渠道的设备都会收到推送

更棒的是：这条规则还可以复用到Launcher广告、黑名单等其他业务中！

1. 核心概念

在规则中心核心概念中，在开始使用之前，请先熟悉以下核心概念：

1.1 规则 (Rule)

规则是规则中心的基本单元，规则是逻辑判断的核心单元，定义了"什么样的设备符合条件"。

配置项	说明
MAC配置	直接在规则上导入MAC地址，限制特定设备
MAC资源引用	当多个规则使用同一批MAC时，可引用MAC资源包
渠道配置	限制规则只对特定渠道的设备生效
地区配置	限制规则只对特定地区的设备生效
EL表达式	高级用法，可配置灵活的过滤条件（如 `SDK版本>46 且构建包含>NRD91N`）

1.2 MAC资源 (MAC Resource)

MAC资源是规则中心用于管理设备集合的机制，是一组MAC地址的集合库。当多个规则需要使用同一批设备清单时，可以建立一个MAC资源包，在不同规则中直接引用，实现复用。

典型场景："VIP测试组"包含1万台设备，需要在任务推送和广告投放两个规则中同时使用。

1.3 业务绑定 (Business Binding)

业务绑定是将规则应用于具体业务的机制。规则本身是独立的，只有被具体的业务绑定后，才会真正生效。

支持的业务类型：

业务类型	对应模块文档	说明	是否需审批
任务推送	任务推送管理	向设备推送任务配置	是
Launcher广告	Launcher信息管理	广告位配置推送	是
黑名单	黑名单配置	黑名单卸载配置	是
UOTA升级	UOTA信息管理	系统升级包推送	否
域名分发	域名分发管理	设备域名配置	否

操作方式：

绑定规则：业务侧可直接关联已有规则
新增规则：在业务侧新增的规则会自动绑定到当前业务
新增MAC/渠道/地区：必须选择放在一条已绑定的规则之下

1.4 EL表达式 (EL Expression)

EL表达式是规则中心基于 LiteFlow 规则引擎的领域专用语言（DSL），用于以声明式方式描述复杂的设备过滤和业务编排逻辑。既支持通过可视化拖拽自动生成，也支持直接编写文本形式的表达式，二者语义完全一致。

下方示例中的 EL 表达式，其业务含义为：当设备的“渠道名称”包含 2024，且同时满足“SDK 版本以 rk 开头”或“激活时间在 2026-01-01 00:00:00 至 2026-01-30 00:00:00 区间”这两类条件之一时，规则判定为通过；否则规则不通过：

IF(
  AND(
    OR(
      startsWithCmp.tag("build").data("rk"),
      betweenLInclCmp.tag("activationTime").data("2026-01-01 00:00:00,2026-01-30 00:00:00")
    ),
    containsCmp.tag("channelName").data("2024")
  ),
  deviceTrueCmp,
  deviceFalseCmp
);

2. 模块关系图(不考虑审批相关限制)

规则中心模块关系图展示了规则、MAC资源与业务系统之间的关系。

审批相关的业务(黑名单、launcher、任务推送)很特殊，一条规则但凡被一条需要审批的业务绑定之后，就不能再绑定其它任何数据了，如果这时候这条规则去绑定mac资源，mac资源同样也会有只能1对1绑定的限制，所以如下的图中是不考虑审批限制的关系图

下图展示了规则、MAC资源与业务系统之间的关系(不考虑审批限制)：

Mermaid Diagram Code:

graph TD
    subgraph 规则中心
        R1[规则 A]
        R2[规则 B]
        MR[MAC 资源包]
        
        MR -->|被引用| R1
        MR -->|被引用| R2
    end
    
    subgraph 业务系统
        B1[任务推送]
        B2[Launcher广告]
        B3[黑名单]
        
        B1 -->|绑定| R1
        B2 -->|绑定| R1
        B3 -->|绑定| R2
    end

MAC资源 被规则引用（复用）
规则被业务绑定（生效）
在业务侧新增的MAC/渠道/地区，实际上是直接附加在当前绑定的规则上

3. 数据关系图

规则中心数据关系图展示了规则引擎涉及的主要数据表及其关系：

Mermaid Diagram Code:

graph TD
    subgraph 规则核心
        Chain[规则定义表]
        MacItem[规则关联MAC表]
        ChannelItem[规则关联渠道表]
        RegionItem[规则关联地区表]
        MacResRef[规则关联MAC资源表]
    end
    
    subgraph MAC资源
        MacRes[MAC资源表]
        MacResItem[MAC资源关联MAC表]
    end
    
    subgraph 业务关联
        Business[规则关联业务表]
    end
    
    Chain --> MacItem
    Chain --> ChannelItem
    Chain --> RegionItem
    Chain --> MacResRef
    MacResRef --> MacRes
    MacRes --> MacResItem
    Chain --> Business

4. 匹配逻辑 (工作原理)

规则中心的匹配逻辑（工作原理）：当机顶盒（设备）请求服务器时，系统是如何判断它该获取哪些配置的呢？

4.1 匹配流程图

规则匹配流程图展示了设备请求到返回结果的完整过程。

Mermaid Diagram Code:

graph TB
    A[设备请求] --> B[传入业务类型和设备信息]
    B --> C[信息补全]
    C --> D[初筛候选规则]
    
    D --> D1[MAC专属规则]
    D --> D2[渠道关联规则]
    D --> D3[无设备限制规则]
    D --> D4[业务类型规则]
    
    D1 --> E[集合运算]
    D2 --> E
    D3 --> E
    D4 --> E
    
    E --> F[地区过滤]
    F --> G[EL表达式计算]
    G --> H[数量限制检查]
    H --> I[返回业务ID集合]

4.2 详细流程说明

规则匹配详细流程说明如下表所示：

步骤	说明
1. 请求输入	业务模块传入设备MAC、业务类型等信息
2. 信息补全	根据MAC查询设备详细画像（渠道、地区、硬件配置等）
3. 初筛候选规则	从Redis缓存中获取MAC专属规则、渠道关联规则、无限制规则、业务类型规则
4. 集合运算	候选规则 = (MAC规则 ∪ 渠道规则 ∪ 无限制规则) ∩ 业务类型规则
5. 地区过滤	检查规则是否有地区限制，设备地区不匹配则跳过
6. EL表达式计算	将设备详情注入LiteFlow上下文，执行EL表达式匹配
7. 数量限制检查	检查业务剩余数量是否满足要求
8. 结果输出	返回匹配成功的业务ID集合

5. 审批机制说明

5.1 为什么需要审批

任务推送、Launcher广告、黑名单这三类业务直接影响线上设备的运行状态，一旦配置错误可能导致：

大量设备收到错误的推送内容
广告位展示异常
应用被意外卸载

因此，这三类业务的规则变更需要经过审批流程，确保变更安全可控。

5.2 审批对业务的影响

状态	含义	设备是否生效	您可以做什么
草稿/未生效	规则已创建但未提交审批	否	继续编辑、提交审批
审批中	规则已提交，等待审批	否	等待审批结果
已生效	审批通过，规则正式生效	是	查看效果、申请修改
已驳回	审批未通过	否	修改后重新提交

5.3 审批流程图

Mermaid Diagram Code:

flowchart TD
    A[您配置规则] --> B[提交审批]
    B --> C{审批中}
    C -->|审批通过| D[规则生效]
    C -->|审批驳回| E[修改规则]
    E --> B
    D --> F[设备自动匹配新规则]

6. 从配置到生效的全链路

当您完成规则配置后，系统是如何让设备收到正确配置的？

Mermaid Diagram Code:

flowchart TD
    A[您在规则中心配置规则] --> B[规则与业务绑定]
    B --> C{是否需要审批?}
    C -->|是| D[提交审批流程]
    D --> E{审批通过?}
    E -->|是| F[规则生效]
    E -->|否| G[退回修改]
    G --> D
    C -->|否| F
    F --> H[系统更新缓存]
    H --> I[设备请求服务器]
    I --> J[规则引擎自动匹配]
    J --> K[设备获取对应配置]

关键环节说明

环节	说明	您的关注点
配置规则	定义"什么样的设备符合条件"	确保筛选条件准确
绑定业务	将规则与具体业务关联	确认绑定关系正确
审批流程	对高风险变更进行审核	关注审批进度
规则生效	系统将配置同步到缓存	等待几分钟生效
设备匹配	设备请求时自动匹配规则	验证设备是否收到正确配置

通过理解以上概念，您就可以更清晰地进行规则清单管理、MAC资源管理以及业务侧集成的操作了。

0. 一分钟理解规则中心​

0.1 规则中心是什么​

0.2 一个简单的例子​

1. 核心概念​

1.1 规则 (Rule)​

1.2 MAC资源 (MAC Resource)​

1.3 业务绑定 (Business Binding)​

1.4 EL表达式 (EL Expression)​

2. 模块关系图(不考虑审批相关限制)​

3. 数据关系图​

4. 匹配逻辑 (工作原理)​

4.1 匹配流程图​

4.2 详细流程说明​

5. 审批机制说明​

5.1 为什么需要审批​

5.2 审批对业务的影响​

5.3 审批流程图​

6. 从配置到生效的全链路​

关键环节说明​

0. 一分钟理解规则中心

0.1 规则中心是什么

0.2 一个简单的例子

1. 核心概念

1.1 规则 (Rule)

1.2 MAC资源 (MAC Resource)

1.3 业务绑定 (Business Binding)

1.4 EL表达式 (EL Expression)

2. 模块关系图(不考虑审批相关限制)

3. 数据关系图

4. 匹配逻辑 (工作原理)

4.1 匹配流程图

4.2 详细流程说明

5. 审批机制说明

5.1 为什么需要审批

5.2 审批对业务的影响

5.3 审批流程图

6. 从配置到生效的全链路

关键环节说明