Flow 设计原则

概述

本节介绍 Node-RED Flow 的设计原则和最佳实践。学习完成后，您将能够：

理解 Flow 的结构和组织方式
设计模块化、可维护的 Flow
使用注释和命名规范管理 Flow
导入导出 Flow 与他人协作

什么是 a Flow？

Flow 是 Node-RED 中的基本工作单元，由连接的节点组成的数据处理管道：

【注入节点】 → 【处理节点】 → 【输出节点】
    ↑              ↑              ↑
  触发信号    数据处理/逻辑    结果输出

Flow Organization

1. 使用多个 Tab 组织 Flow

┌──────────────────────────────────────────────────┐
│  Node-RED Editor                                   │
├──────────────────────────────────────────────────┤
│  [+]/tab ├── [Tab 1: Data Collection]            │
│          ├── [Tab 2: Data Processing]            │
│          ├── [Tab 3: Alert & Notification]        │
│          ├── [Tab 4: Device Control]              │
│          └── [Tab 5: Testing & Debug]             │
└──────────────────────────────────────────────────┘

2. Flow 命名规范

规范	示例	说明
前缀分类	`data-`, `ctrl-`, `alert-`	按功能分类
场景描述	`Factory-Temperature`	清晰描述用途
设备标识	`SHELLY-POWER-A`	关联具体设备
版本标记	`v1.2`	便于追踪

Flow Design Patterns

Pattern 1: Simple Pipeline

最简单的 Flow 结构 - 单输入单输出：

[MQTT In] → [Function] → [InfluxDB Out]
   ↑            ↑             ↑
  输入       数据处理       输出存储

适用场景: 传感器数据采集和处理

Pattern 2: Branching

根据条件分流：

             → [Switch] → [Email] (高温告警)
[MQTT In] →
             → [InfluxDB Out] (正常存储)

适用场景: 条件判断和多路输出

Pattern 3: Aggregation

多路数据汇聚：

[Device 1] →
[Device 2] → [Join] → [Function] → [Database]
[Device 3] →

适用场景: 多设备数据合并

Pattern 4: Feedback Loop

带反馈回路的控制：

[MQTT In] → [Function] → [Decision] → [MQTT Out] → ESP32
               ↑                            │
               └────── [Status] ←──────────┘

适用场景: 设备远程控制

Flow Design Guidelines

✅ 推荐做法

1. 模块化设计

// 每个 Tab 处理一个独立功能
// Tab 1: Data Ingestion (数据接入)
// Tab 2: Business Logic (业务逻辑)
// Tab 3: Data Storage (数据存储)
// Tab 4: Notification (通知)

2. 使用注释节点

Flow 注释示例:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  Temperature Monitoring Flow v1.2
  --------------------------------
  输入: MQTT Topic: factory/temperature
  输出: InfluxDB bucket: nodered
  告警: > 30°C → Email to operator
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

3. 完整命名节点

✅ 好的命名:
  [MQTT In: Factory Temperature]
  [Function: Calculate Average]
  [Influx Out: Write to DB]
  [Debug: Monitor Payload]

❌ 差的命名:
  [MQTT In]
  [Function 23]
  [influxdb]

❌ 避免做法

1. 单个 Tab 包含所有逻辑

难以维护和调试
团队协作困难

2. 不设注释

后续维护者无法理解业务规则
遗忘后无法复用

3. 过度复杂的 Function 节点

超过 50 行的 Function 应拆分
保持逻辑简单清晰

Import and Export

Export Flow

# 在 Node-RED 编辑器中:
# 1. 选择要导出的节点
# 2. 菜单 → Export → Selected Flows / Current Flow / All Flows
# 3. 复制 JSON 或下载文件

# 导出为 JSON 文件
# flows.json - 所有 Flow
# flows_cred.json - 加密的凭证信息

Import Flow

# 在 Node-RED 编辑器中:
# 1. 菜单 → Import
# 2. 粘贴 JSON 或选择文件
# 3. 选择导入位置 (新 Tab / 当前 Flow)

# 导入后检查:
# - 缺少的节点需先安装
# - MQTT Broker 配置需更新
# - 数据库连接需重新配置

CLI 导入导出

# 从持久化目录导出
cp /data/flows.json ./backup-flows.json

# 导入备份
cp ./backup-flows.json /data/flows.json
docker restart nodered

Flow Version Management

# 使用 Git 管理 Flow 版本
cd nodered/data
git init
git add flows.json
git commit -m "v1.2: Add temperature monitoring flow"

git tag v1.0
git tag v1.1
git tag v1.2

# 回滚到旧版本
git checkout v1.0 -- flows.json
docker restart nodered

Common Customer Questions

Q1: Flow 设计有标准规范吗？

A: 虽然没有官方强制规范，但建议：模块化 Tab 组织、有意义的节点命名、适当注释、单一职责原则。

Q2: 如何复用已有的 Flow？

A: Node-RED 社区提供了上千个示例 Flow，可以从社区导入。也支持 JSON 导出分享给其他用户。

Q3: Flow 出错了怎么排查？

A: 使用 Debug 节点监控中间数据，查看 Node-RED 日志，使用 Catch 节点捕获错误。

最佳实践

✅ 推荐做法:

每个 Tab 一个独立功能
使用有意义的节点名称
添加 Flow 级别注释
保持 Function 节点简洁
定期备份 Flow 定义
使用 Git 管理版本

❌ 避免做法:

将所有逻辑放在一个 Tab
使用默认节点名称
Function 节点超过 50 行
缺少错误处理
不注释复杂的逻辑

Summary

良好的 Flow 设计是 Node-RED 开发的基础
模块化、命名规范、适当注释是三大原则
支持导入导出，便于分享和协作
使用 Git 管理 Flow 版本实现回滚
Debug 节点和 Catch 节点是主要排错工具