什么是流处理引擎？
基于流的编程是一种编程范例，它将应用程序定义为"黑盒"进程网络。这些进程（也称为函数）表示为通过消息传递在预定义连接之间交换数据的节点。节点可以无休止地重新连接以形成不同的应用程序，而无需更改其关联的功能。
因此，基于流的编程（FBP）自然是"面向组件的"。FBP的一些好处是：
在不重写组件的情况下更改连接接线。
固有的并发性 — 适用于多核 CPU 世界。
流处理引擎有哪些示例？
Yahoo！ Pipes 和 Node-RED 是使用基于流的编程构建的规则引擎的两个示例。随着"无服务器"计算的引入，基于流的编程变得更加流行，其中云应用程序可以通过链接函数来构建。
IBM的OpenWhisk是通过链接云函数（IBM称之为操作）来基于流的编程的一个例子。另一种无服务器编排方法（例如 AWS 步骤函数）基于有限状态机规则引擎。
流处理引擎能否对复杂逻辑进行建模？
基于流的编程没有状态和状态转换的概念。在规则中组合函数（观测值）的多个非二进制结果是可能的，但必须在应用它的每个函数中对其进行编码。这也意味着你必须在每个需要对多项选择结果进行建模的函数上进行分支。这导致了非常繁忙的流图，很难理解，特别是因为逻辑既表现在函数本身，也表达在它们的"连接器"——路径执行中。这些连接器不仅以某种方式暗示了信息流，还暗示了正在做出的决策。
与决策树类似，随着逻辑复杂性的增加，这种建模方法会受到节点数呈指数级增长的影响。更糟糕的是，与决策树不同，我们无法将函数结果作为状态进行跟踪。对于这个缺点，没有比查看使用 Node-RED 实现的稍微复杂一点的流程并计算节点和连接器的数量更好的例证了。由node-RED设计的简单用例具有30或40个节点和连接器，甚至很难在一个屏幕上安装，这并不罕见。
只有当我们引入将不同节点的输出合并到单独的合并节点中的概念时，流引擎中的多数投票才有可能。即便如此，它仍然是有问题的，因为它需要在该合并节点的函数中编写多数规则。
流处理引擎能否对时间进行建模？
流引擎几乎不能处理时间维度的任何方面，因为FBP在设计上是一个无状态的规则引擎。在某些有限的用例（几乎无法扩展）中，您可以在时间范围内合并流。
流处理引擎是否可解释？
使规则引擎可解释的一些因素是：
该规则的意图应该对所有用户、开发人员和业务所有者都很清楚。
逻辑应该有一个紧凑的表示
引擎应在设计时和运行时具有仿真和调试功能
对于简单的用例，基于流的数据流表示感觉很自然，至少从信息流的角度来看是这样。但是，任何使用FPB创建复杂逻辑的尝试都会使验证预期的逻辑变得非常困难。
话虽如此，通过查看流程图来了解要做出哪些决策是一项非常困难的任务。这样做的主要原因是逻辑表示形式不紧凑，并且规则的验证通常需要流式传输测试数据，然后跨所有管道验证函数日志。
逻辑在流路径（当数据在处理节点之间传输时）和每个节点中的有效负载处理之间拆分，这可能会导致在该处理节点之后采用不同的路径。因此，调试和规则验证成为一个非常繁琐且容易出错的过程。此外，我们永远无法确定所有极端情况（来自不同输入的决策的输出）是否都包含在使用FBP表达的特定规则中 - 它看起来几乎就像基于FBP的规则验证是一个NP难题。
流处理引擎是否具有适应性？
基于流的编程引擎具有可重用的黑盒节点（函数）。但是，对任何特定规则进行部分更新都是困难和有风险的，因为这通常意味着对图表的重大变化和规则的重新验证。在某种程度上，其主要原因是对于大多数规则引擎，特别是对于FBP，可解释性和灵活性之间存在高度相关性。基于流的规则引擎很容易使用第三方服务进行扩展，并且以优雅的方式实现了可扩展性。
流量处理引擎是否易于操作？
模板化非常难以实现，因为在处理在不同处理节点之间传递有效负载时发生的有效负载转换时需要特别小心。此外，阈值和分支逻辑是同一有效负载处理流的一部分，因此很难抽象出此逻辑。出于同样的原因，批量升级容易出错且存在风险。
流处理引擎是否可扩展？
基于流的编程引擎本质上是并发的，因为它们必须分发功能计算。它们也是无状态的，这意味着规则引擎只需要跟踪当前执行和需要执行的进一步操作。另一方面，如果需要在一个规则中合并不同节点的多个输出，或者当使用不同的路径执行引入决策分支时，规则引擎将需要将规则执行的快照（作用域）保留在某个位置。
使用 Node-RED 进行物联网应用程序开发
Node-RED今天在创客社区中非常受欢迎，并且是许多工业供应商网关中的事实工具。这与它的创建者决定让不同的协议流作为输入数据事件直接进入节点有关。这是故意完成的，以简化协议终止并允许在node-RED中执行有效负载规范化。但这是一个像双刃剑一样的决定。
一方面，这意味着依赖于协议的数据流可以由任何第三方实现，并立即在node-RED环境中使用。由于协议转换和有效负载规范化在物联网部署中非常重要，因此node-RED对于边缘部署非常有价值。
但另一方面，这也使Node-RED遭受了比其他基于流的编程引擎更大的可操作性问题。例如，它使模板化变得更加困难：协议转换和有效负载规范化需要与阈值定义和分支一起成为Node-RED模板的一部分。
虽然现成的 Node-RED 实例非常适合边缘部署，但它无法针对云进行扩展。一些供应商提供云解决方案，在Node-RED之上实现分片，并在单独的组件中外部化协议终止。但是，在采用这种方法时，他们也可以切换回更通用的FPB引擎。
版权属于：月萌API www.moonapi.com，转载请注明出处
