paas 工具 node-red

[图片上传失败...(image-62f8d5-1622710569083)] 

[图片上传失败...(image-60325a-1622710569083)] 

逻辑编排是用可视化方式描述逻辑，在一般搭建场景中用于代替逻辑描述部分。

更进一步的逻辑编排是前后端逻辑混排，一般出现在一站式 paas 平台，今天就介绍一个全面实现了逻辑编排的 paas 工具 [node-red](https://github.com/node-red/node-red)，本周精读的内容是其介绍视频：[How To Create Your First Flow In Node-RED](https://www.youtube.com/watch?v=cVWVr_T7kQ0)，介绍了如果利用纯逻辑编排实现一个天气查询应用，以及部署与应用迁移。

概述

想要在本地运行 Node-RED 很简单，只要下面两条命令：

npm install -g --unsafe-perm node-red

node-red

之后你就可以看到这个逻辑编排界面了：

[图片上传失败...(image-88ac30-1622710569083)] 

我们可以利用这些逻辑节点构建前端网站、后端服务，以及大部分开发工作。光这么说还比较抽象，我们接下来会详细介绍每个逻辑节点的作用，让你了解这些逻辑节点是如何规划设计的，以及逻辑编排到底是怎么控制研发规范来提高研发效率的。

Node-RED 截止目前共有 42 个逻辑节点，按照通用、功能、网络、序列、解析、存储分为六大类。

所有节点都可能有左右连接点，左连接点是输入，右连接点是输出，特殊节点可能有多个输入或多个输出，其实对应代码也不难理解，就是入参和出参。

下面依次介绍每个节点的功能。

通用

通用节点处理通用逻辑，比如手动输入数据、调试、错误捕获、注释等。

inject

[图片上传失败...(image-c7a9e2-1622710569083)] 

手动输入节点。可以定期产生一些输入，由下一个节点消费。

举个例子，比如可以定期产生一些固定值，如这样一个这个对象：

**return** {

 payload: **new** Date(),

 topic: "abc",

};

当然这里是用 UI 表单配置的：

[图片上传失败...(image-26003b-1622710569083)] 

之后就是消费，几乎后面任何节点都可以消费，比如利用 change 节点来设置一些环境变量时，或者利用 template 节点设置 html 模版时，都可以拿到这里输入的变量。如果在模版里，变量通过 {{msg.payload}} 访问，如果是其它表单，甚至可以通过下拉框直接枚举选择。

然而这个节点往往用来设置静态变量，更多的输入情况是来自其它程序或者用户的，比如 http in，这个后面会讲到。其实通过这种组合关系，我们可以把任意节点的输入从生产节点替换为 inject 节点，从而实现一些 mock 效果，而 inject 节点也支持配置定时自动触发：

[图片上传失败...(image-9f1b16-1622710569083)] 

debug

[图片上传失败...(image-1a1a4e-1622710569083)] 

用来调试的，当任何输出节点连接到 debug 的输入后，将会在控制台打印出输出信息，方便调试。

比如我们将 inject 的输入连上 debug 的输入，就可以在触发数据后在控制台看到打印结果：

[图片上传失败...(image-ceb492-1622710569083)] 

当然如果你把输入连接到 debug，那么原有逻辑就中断了，然而任何输出节点都可以无限制的输出给其它节点，你只要同时把输出连接到 debug 与功能节点就行了：

[图片上传失败...(image-996cbe-1622710569083)] 

complete

[图片上传失败...(image-45dcd9-1622710569083)] 

监听某些节点触发完成动作。通过这个节点，我们可以捕获任意节点触发的动作，可以接入 debug 节点打印日志，或者 function 节点处理一下逻辑。

可以监听全部节点，也可以用可视化方式选择要监听哪些节点：

[图片上传失败...(image-bb11d5-1622710569083)] 

catch

[图片上传失败...(image-7cda43-1622710569083)] 

错误捕获节点，当任何或指定节点触发错误时输出，输出的格式为：

**error**.message 字符串

错误消息。

**error**.**source**.id 字符串

引发错误的节点的ID。

**error**.**source**.type 字符串

引发错误的节点的类型。

**error**.**source**.name 字符串

引发错误的节点的名称。（如果已设置）

其实每个节点都有固定输出格式，这些固定格式限制了开发灵活度，但熟练掌握后可以大大提升开发效率，因为所有同类型节点格式都是一样的，这是逻辑编排带来规则约束的好处。

status

[图片上传失败...(image-38752d-1622710569083)] 

监听节点状态变化。

link in

[图片上传失败...(image-ff5992-1622710569083)] 

只能连接 link out。link in、link out 就像一个传送门，用来整理逻辑编排节点，使之看上去易于维护。

比如下面的例子，在一个天气 http in 服务后，穿插了许多逻辑处理节点，有处理响应 html 内容的 template 节点，也有处理请求查询城市天气的 http request 服务，整体逻辑虽然聚合，但比较杂乱：

[图片上传失败...(image-26f262-1622710569083)] 

较好的方式是分类，即类似代码开发中的模块化行为，将天气服务导出，其他任何用到的模块直接导入，这个导入动作就是通过 link in 实现的，link out -> link in 只是一个空间位置的变换，传输值是不会变的：

[图片上传失败...(image-c78852-1622710569083)] 

这样模块看起来清晰了许多，如果要知道各个 “传送门” 见连接关系，只要鼠标点击其中一个就可以给出提示，看起来十分方便：

[图片上传失败...(image-cd0f47-1622710569083)] 

link out

[图片上传失败...(image-b06f0d-1622710569083)] 

和 link in 成对出现，用来导出输入值，后面对接 link out 可以像传送门一样将值传送过去，在视觉上不会形成连接线。

comment

[图片上传失败...(image-85450b-1622710569083)] 

注释，配合 link 系列使用，可以让逻辑编排 UI 更易于维护。

结合原视频的例子，对于天气服务，有创建环境变量逻辑，有查询逻辑，其中查询天气还分为查询当前天气、连续 5 天天气、查询国家信息，我们可以在 UI 上讲每块逻辑分组，并利用 comment 组件标记好注释，方便阅读：

[图片上传失败...(image-a7a985-1622710569083)] 

功能

功能型节点，一般用于处理业务逻辑，所以包含了基础的 if else、js 代码、模版处理等等功能模块。

function

[图片上传失败...(image-afcca9-1622710569083)] 

最核心的 js 函数模块，你可以用它做任何事：

[图片上传失败...(image-8abffc-1622710569083)] 

其输入会传导到 msg 对象，可以通过代码修改 msg 对象后再通过输出节点传导出去。

当然也可以访问和修改节点、流程、全局变量，这个在 change 节点里介绍。

switch

[图片上传失败...(image-bad7d4-1622710569083)] 

对应代码的 switch，只是用起来更加方便，因为我们可以根据不同 case 导出不同的节点：

[图片上传失败...(image-63e988-1622710569083)] 

注意看上图，因为有三条分支，所以节点的导出项也变成了三个，我们可以根据不同逻辑走不同的连接：

[图片上传失败...(image-e47587-1622710569083)] 

change

[图片上传失败...(image-9cd662-1622710569083)] 

用来改变环境变量。环境变量分为三种，分别是当前节点、流程（画布）、全局（跨应用）。也就是说，变量可以存储在某个节点上，也可以存储在整个画布上，也可以跨画布存储在全局。

访问参数分别为 msg.、flow.、global.，设置这些参数后，就像全局变量一样，任何节点都可以在任何地方使用，比较方便。

比如应用固定了一些 URL 地址，直接把一串字符串写死在某个 http in 节点里并不明智，因为后面的 html 或者其它节点里可能会访问它，一旦你进行修改，影响面会非常广，因此最好将其设置为全局变量，在节点中通过变量方式访问：

[图片上传失败...(image-ccb997-1622710569083)] 

其实在控制台，可以看到这三种变量的值：

[图片上传失败...(image-6d0e40-1622710569083)] 

当我们利用 change 节点赋值后，可以通过调试面板查看不同作用域全局变量的值：

[图片上传失败...(image-737218-1622710569083)] 

range

[图片上传失败...(image-46636a-1622710569083)] 

区间映射，将一个范围的值映射到另一个范围。其实通过 function 模块也能完成，只是因为比较常用所以封装了一个特殊节点。其实用户也可以自己封装节点，具体方式可以参考 [官方文档](https://nodered.org/docs/creating-nodes/)。

[图片上传失败...(image-68ab0e-1622710569083)] 

上图很容易理解，比如数据分析中归一化就可以用这个节点实现。

template

[图片上传失败...(image-3611cc-1622710569083)] 

以模版方式生成字符串或 json。

其实本质上也可以被 function 代替，只是用来写模版的话有高亮，维护起来比较方便。

内置了 [mustache](https://github.com/janl/mustache.js) 模版语法，通过 {{}} 方式使用变量。

比如我们通过 inject 注入一个变量给 template，并通过 debug 打印，流程是这样的：

[图片上传失败...(image-7cc666-1622710569083)] 

其中 inject 是这么配置的：

[图片上传失败...(image-70696-1622710569083)] 

可以看到，将 msg.name 设置为一个字符串，然后通过 template 访问 name:

[图片上传失败...(image-102888-1622710569083)] 

delay

[图片上传失败...(image-49aca9-1622710569083)] 

延迟发消息，一个快捷的工具，可以放在任何输入与输出中间，比如让上面的例子中，inject 触发后 5s 再打印结果，可以这么配置：

[图片上传失败...(image-186559-1622710569083)] 

trigger

[图片上传失败...(image-c87f1f-1622710569083)] 

一个消息触发器，相比 inject，可以更灵活的设置何时重新触发。

[图片上传失败...(image-437ff9-1622710569083)] 

从配置可以看出，首先和 inject 一样发送一条消息，然后可以等待，或者等待被重置，或者周期性触发（这样就和 inject 一样），其中 “发送第二条消息到单独的输出” 和 switch 一样会多一个输出口。

然后有重置条件，即 payload 为什么值时重置。

通过这个组件可以看出来，其实每个节点都可以用 function 节点实现，只不过通过定制一个节点，可以用 UI 而非代码的方式配置，使用起来更方便。

exec

[图片上传失败...(image-dacdf-1622710569083)] 

执行系统命令，比如 ls 等，这个在系统后台执行而非前端，所以是一个相当危险的节点。

我们可以在配置中写入任何命令：

[图片上传失败...(image-ccb6af-1622710569083)] 

rbe

[图片上传失败...(image-3fd261-1622710569083)] 

异常报告节点（Report by Exception），比如说当输入变化时进行阻塞。

网络

用于创建网络服务，比如 http、socket、tcp、udp 等等，因为其它都不常用，这次仅介绍 http 服务。

http in

[图片上传失败...(image-4bb6ee-1622710569083)] 

创建一个 http 服务，可以是任何接口或者 web 服务。

当你把 Method 设置为 post，连接到 http response 就创建了后端接口；当设置为 get 请求，并连接 template 写上 html 模版，并连接到 http response 就创建了 web 服务。

虽然这种方式创建 web 服务难以使用 react 或 vue 框架，不过自定义节点还是为其创造了可能性，或许真的可以把前端模块化文件定义为节点相互串联。

http response

[图片上传失败...(image-a7ee8b-1622710569083)] 

http 返回，只能对接 http in 的输出，总是与 http in 成对使用。

如果只用了 http in 但没有用 http response，就相当于后端代码里处理了请求，但没有调用类似：

res.send("hello word");

来向客户端发送内容。

http request

[图片上传失败...(image-fa9142-1622710569083)] 

与 http in 创建一个 http 服务不同，http request 直接发送一个网络请求并将返回值导入到输出节点。

视频中获取天气的例子，就用了 http request 发起请求获取天气信息：

[图片上传失败...(image-bee3b8-1622710569083)] 

不难看出，发送请求后，又使用了 function 节点处理返回结果。不过在逻辑编排中还是期望少使用 function 节点，因为除非有很好的命名，否则难以看出来节点含义，如果 function 处理内容过多或者 function 区块过多，就失去了逻辑编排的意义。

序列

序列是对数组进行处理的节点。

split

[图片上传失败...(image-5faf58-1622710569083)] 

对应代码的 split，将字符串变为数组。

join

[图片上传失败...(image-edcd1a-1622710569083)] 

对应代码的 join，一般与 split 配合使用，方便处理字符串。

sort

[图片上传失败...(image-de7f0f-1622710569083)] 

对应代码 sort，只能根据 key 做简单的升序降序处理，对于简单场景比较方便，但对于复杂场景可能还会使用 function 节点代替。

batch

[图片上传失败...(image-5af80-1622710569083)] 

批量接收输入流后，根据数量进行打包后统一输出，等于批量打包，可以按照数量或者时间间隔进行分组：

[图片上传失败...(image-12154c-1622710569083)] 

解析

[图片上传失败...(image-71f30c-1622710569083)] 

很容易理解，专门处理上述格式的数据，并按照数据特征输出，比如 csv 数据，可以每行一条消息的方式输出，或者打包为一个大数组以一条消息输出。

当然也可以被 function 节点代替，那么解析方式与输出方式都可以自定义。

存储

持久化存储，一般存储为文件。

file

[图片上传失败...(image-289184-1622710569083)] 

输出为文件。

file in

[图片上传失败...(image-14fd98-1622710569082)] 

以文件作为输入，并将文件结果作为输出。

watch

[图片上传失败...(image-3fd882-1622710569082)] 

监听目录或文件的修改。

精读

看了上面 node-red 功能后，相信你对逻辑编排已经有较为体系化的认识了。

逻辑编排的目的是为了让非研发人群也可以快速上手研发工作，因此注定是为 paas 工具服务的，而逻辑编排到底好不好用，取决于节点功能是否完备，以及各节点之间通信是否顺畅，像 node-red 逻辑编排方案，在完备性上做的较为成熟，可以说只要熟练掌握了几个核心节点规则，使用起来还是非常提效的。

逻辑编排也有天然缺点，就是当所有节点都退化为 function 节点后，会存在两个问题：

*   所有节点都是 function 节点，即便有说明，但内部实现逻辑非常自由，导致逻辑编排无法起到约束输入输出的作用。
*   退化到代码函数式调用，本质上与写代码无异。逻辑编排之所以提效，很大程度上是我要的业务逻辑刚好与节点功能匹配，以低成本 UI 配置的方式实现效率才高。

然而这也是有解决方法的，如果你的业务无法被现有的逻辑编排节点满足，你可以尝试抽象一下，自己梳理出业务常用的节点，并用合理的配置封装，只要常用业务逻辑可以被封装为逻辑节点，逻辑编排就还有为业务提效的空间。

总结

逻辑编排是一种极端，即用 UI 方式描述通用业务逻辑，降低非专业开发人员的上手门槛。通过对 [node-red](https://github.com/node-red/node-red) 的分析可以发现，一个较为完备的逻辑编排系统还是能带来价值的。

然而针对非专业开发人员降本提效还有一种极端，就是完全代码化，但是把代码模块化、函数库、工具链甚至低代码平台建设的非常完备，以至于写代码的效率根本不低，这条路走到极致也不错，因为既然要深入开发系统，同样是投入时间学习，为什么学习写代码就一定比学习拖拽 UI 效率低呢？如果有高度封装的函数与工具辅助，效率不见得比 UI 拖拽来的低。

然而 node-red 在创建前端 UI 的模版上还可以再增强一下，把 template 从节点升级为 UI 搭建画布，逻辑编排仅用来处理逻辑，这样对大型全栈项目的前端开发体验会更好。