在电信网络优化（Optimize）子系统中，基站参数的合规性检查是保障网络稳定运行的第一道防线。传统的参数核查逻辑往往以硬编码的形式散落在 Service 层中，例如针对 PCI（物理小区标识）的模三冲突检测、邻区关系的一致性校验以及覆盖重叠区域的判断。随着 5G 网络的演进，核查规则日益复杂且频繁变更，硬编码模式导致了代码耦合度高、维护成本大、业务响应慢等痛点。
本文将分享如何引入 LiteFlow 轻量级规则引擎，替代复杂的条件分支逻辑，实现基站参数核查流程的组件化编排与动态热加载。我们将重点探讨如何利用 LiteFlow 的上下文数据传递机制，构建一个高效、可扩展的参数自动核查微服务，并结合 Spring Cloud Alibaba 实现规则的云端统一管理。
一、 业务背景与挑战
1. 核心痛点
- 逻辑僵化：原有的PCICheckRule逻辑通常由多层 if-else 嵌套组成，新增一种核查维度（如新增“干扰门限”判断）需要修改核心代码并重新发布。
- 复用性差：不同的核查任务（如日常巡检、专项优化）往往共享部分基础校验逻辑，但硬编码导致代码重复率高。
- 性能瓶颈：全省数万个基站的参数核查若采用串行处理，耗时极长，难以满足实时性要求。
2. 技术选型：为什么选择 LiteFlow？
相比 Drools 等传统重型规则引擎，LiteFlow 更适合微服务架构下的业务编排：
- 轻量级：无外部依赖，启动速度快，内存占用极低。
- 组件化：将每个核查步骤封装为独立的 Node（组件），支持高度复用。
- 动态编排：支持通过 XML/JSON/YAML 或数据库动态配置执行流程，实现规则的热更新。
- 上下文隔离：通过 NodeContext 在各组件间安全传递核查数据。
二、 架构设计：基于 Spring Cloud Alibaba 的核查体系
1. 总体架构
- 接入层：Vue 3 前端发起核查请求，选择核查模板（如“PCI 专项核查”）。
- 服务层 (Optimize Service)：集成 LiteFlow，根据模板 ID 加载对应的规则链。
- 规则存储：利用 Nacos Config 或 MySQL 存储规则编排脚本，支持运维人员在线调整核查顺序。
- 数据层：从 NetMgr Service 获取基站工参，从 Perf Service 获取实时性能指标。
2. 核查流程建模
我们将一个完整的核查任务拆解为以下原子组件：
三、 核心实现：LiteFlow 组件化编排
1. 定义核查上下文 (Context)
上下文对象用于在组件间传递数据，它是线程安全的。
@Data
public class CellCheckContext extends NodeContext {
private String cellId; // 待核查小区 ID
private NeCellInfo baseInfo; // 小区基础信息
private List<NeighborRelation> neighbors; // 邻区列表
private List<String> errorLogs; // 错误日志列表
private boolean isPassed = true; // 整体是否通过
}
2. 开发原子核查组件 (Node)
每个组件继承 NodeComponent，实现 process 方法。
组件 A：PCI 模三冲突检测
@LiteflowComponent("pciMod3Check")
public class PciMod3CheckNode extends NodeComponent {
@Override
public void process() throws Exception {
CellCheckContext context = this.getContextBean(CellCheckContext.class);
NeCellInfo cell = context.getBaseInfo();
// 业务逻辑：检查 PCI 是否能被 3 整除或与强邻区冲突
if (cell.getPci() % 3 == 0) {
context.getErrorLogs().add("PCI 模三冲突风险");
context.setPassed(false);
}
// 进一步检查邻区 PCI 分布…
}
}
组件 B：邻区一致性核查
@LiteflowComponent("neighborCheck")
public class NeighborConsistencyNode extends NodeComponent {
@Autowired
private NetMgrFeignClient netMgrClient;
@Override
public void process() throws Exception {
CellCheckContext context = this.getContextBean(CellCheckContext.class);
for (NeighborRelation neighbor : context.getNeighbors()) {
// 调用远程服务验证反向邻区是否存在
boolean hasBackLink = netMgrClient.checkBackLink(neighbor.getTargetCellId(), context.getCellId());
if (!hasBackLink) {
context.getErrorLogs().add("单向邻区异常: " + neighbor.getTargetCellId());
}
}
}
}
3. 规则链编排 (EL 表达式)
在 Nacos 配置中心或数据库中定义规则链。LiteFlow 支持强大的 EL 表达式，可以实现串行、并行、选择执行。
<!– chain_config.xml –>
<chain name="pciSpecialCheck">
<!– 1. 获取数据 –>
<then node="dataFetch"/>
<!– 2. 并行执行多项检查，提高效率 –>
<when>
<then node="pciMod3Check"/>
<then node="neighborCheck"/>
<then node="overlapCoverCheck"/>
</when>
<!– 3. 只有当上述检查都通过时，才进行深度干扰分析 –>
<if id="isAllPassed" then="interferenceAnalysis" else="skip"/>
<!– 4. 汇总结果 –>
<then node="resultAggregate"/>
</chain>
四、 动态热加载与云端管理
为了实现“不重启服务即可调整核查逻辑”，我们将规则配置存储在 Nacos 中，并利用 LiteFlow 的监听机制实现热刷新。
1. Nacos 配置监听
@Component
public class RuleConfigListener {
@Autowired
private FlowExecutor flowExecutor;
@NacosConfigListener(dataId = "optimize-check-rules", type = ConfigType.XML)
public void onRuleChange(String configContent) {
// 解析 XML 并刷新 LiteFlow 的规则缓存
flowExecutor.reloadRule(configContent);
System.out.println("核查规则已动态更新");
}
}
2. Vue 3 前端规则可视化编辑器
在前端提供一个简单的拖拽式界面，运维人员可以勾选需要执行的核查项，后端将其转换为 LiteFlow 的 EL 表达式并存入 Nacos。
// 前端提交规则配置
const saveRuleConfig = async () => {
const ruleChain = {
name: 'dailyCheck',
nodes: ['dataFetch', 'pciMod3Check', 'neighborCheck']
};
await axios.post('/api/optimize/rule/update', ruleChain);
};
五、 性能优化与最佳实践
六、 总结
通过引入 LiteFlow，我们成功实现了基站参数核查业务的解耦与智能化：
- 灵活编排：将复杂的核查逻辑拆解为可复用的原子组件，通过配置即可组合出新的业务流程。
- 动态响应：借助 Nacos 实现规则的热加载，业务人员可随时调整核查策略，无需等待版本发布。
- 高效执行：并行执行机制与上下文数据共享，确保了在海量基站场景下的处理性能。
这套方案不仅提升了网络优化的工作效率，也为后续引入 AI 辅助决策（如将核查结果输入机器学习模型）奠定了标准化的数据基础。
