使用基于微服务的流架构更好地进行大规模的复杂事件处理（第1部分）

基于微服务的流架构与开源规则引擎相结合，使实时业务规则变得容易

这篇文章旨在详细说明我将OSS业务规则引擎与Kafka风格的现代流消息传递系统集成在一起的项目。该项目的目标（即众所周知的复杂事件处理（CEP））旨在实现对流数据的实时决策，例如在IoT用例中。

经过大量的写作，我决定将文章分为两部分。在第一部分中，我将重点介绍什么是CEP，为什么有用，并解释体系结构解决方案以及为什么我们认为对于许多有用的生产用例来说，这是一个好主意。

在第二篇文章中，我将展示一个基于道路交通监控系统的具体示例，并尽可能详细地说明其制作方式。

因此，事不宜迟，继续第1部分！

总览

根据Gartner Inc.的数据，截至2015年，全球企业应用软件市场价值约为1500亿美元。这是一个巨大的市场，其中最常见的应用程序类型之一就是围绕将某种业务逻辑应用于从各个方面生成的数据这生意。

如今，现代企业应用程序需要连接到更多类型的数据源，随数据大小和用户数量扩展，可靠并快速执行。随着业务需求和条件的变化，长达一年或更长的自定义应用程序开发周期不具有吸引力，因此甚至在应用程序投入生产之前就已过时。

在大型，全国性，区域性或全球性组织中，或在金融，医疗保健或IT等行业中使用大量数据的组织中，需求保持不变，但必须使用大数据技术来满足。这带来了一系列全新的难题，这些难题使大规模开发企业应用程序的成本变得极为昂贵，并且在IT基础结构和专有技术要求方面也设置了很高的障碍。

因此，需要一种方法来对各种来源收集的数据运行业务逻辑，这可能是非常大规模的，理想情况下是实时的，例如物联网类型的应用程序。

了解复杂事件处理（CEP）

顾名思义，复杂事件处理（简称CEP）并不那么复杂。从根本上讲，CEP是关于将业务规则应用于流事件数据。事件数据只是带有时间戳字段的数据。此类数据的示例可能是Web服务器的日志条目，购买收据或传感器数据，所有这些都可以视为恒定的事件流。在此流数据上应用规则使响应时可以采取有用的操作。

这是一个智能家居的示例，该智能家居的门口有传感器，智能WiFi路由器和房间移动探测器。通过CEP将所有数据流式传输到家庭服务器中，用户可以制定如下规则：

如果是白天，并且门关着并且没有电话连接到WiFi，请将房屋设置为“没人回家”
如果没有人在家并且门已解锁，则锁上门并打开警报器
如果没有人在家并且是冬天，请将房屋温度降低到18C
如果没有人在家并且是夏天，请关闭空调
如果没有人在家并且门被家庭成员打开，则关闭警报并将房屋设置为“人们在家”

拥有一堆这样的简单规则，确实会很快使一个聪明的家庭加起来。实际上，在一些竞争性智能家居“集线器”设备中已经可以购买到这种功能，这些设备使用通用协议从房屋周围的兼容传感器设备中读取信息，然后在满足某些规则时将操作推回去。

这种示例可以轻松地移植到许多其他域。例如，在零售中，购买历史记录和信标可用于生成个性化，位置敏感的消息或优惠券。在工业应用中，可以使用相对简单的逻辑规则（例如，“如果该机器的红色按钮点亮，则必须停止它”）组合起来，更容易操作和维护许多机床。

CEP规则引擎与手动编码

到目前为止，阅读这些信息的工程师可能不会留下深刻的印象，因为流事件适用简单的规则。诸如上述的智能家居用例可以很容易地（很好地说）完全通过使用Python进行手工编码并在旧用途的PC或Raspberry Pi上运行来处理。

这类项目有哪些部分？

数据提取
定义数据规则
执行规则
满足条件时从规则中采取措施。

好的软件体系结构要求尝试使最容易更改的部分易于更改，但要付出使其他部分更加困难的代价。最需要改变的部分是什么？数据摄取仅在添加新传感器时才会更改，但是给定传感器的数据不会突然更改。摘要中的执行规则始终相同；变化的是规则本身。编码并可以执行的动作并没有真正改变，但是随着时间的推移添加新动作应该很容易。

当用例开始扩展并且规则数量增加时，规则处理引擎的效率开始变得重要。此外，当规则数量增加时，使规则易于编辑不仅是“必备”功能，而且是核心要求。

另一个经常使用的论点是业务逻辑与SDLC的分离。业务需要比软件开发更快。通过使用规则引擎，两个流在很大程度上可以独立移动。

CEP被“植入”物联网应用

CEP几乎是任何种类的物联网应用程序的要求，例如智能家居，智能农业，工业4.0或电信数据。从某种意义上说，这是一项要求，即抛开功能的实现方式，物联网需要将规则应用于流事件数据。无论是在单个私人住宅中进行小规模生产，还是在遍布全球的数家工厂中进行大规模生产，都是如此。

根据我们刚刚描述的内容，理想的设计会反对手动编码的解决方案，并使用所谓的“业务规则处理引擎”。开源世界中存在着几种，最著名的是Drools。

Drools：开源业务规则引擎

Drools是在开源项目的JBoss框架下开发的一个开源项目。这是一个具有长期活跃开发历史的项目，当前版本为6.5.0。最终版本为Beta 7。它相当现代，因为它支持Java 8大大改进的API。

Drools具有我们正在寻找的所有特征，其中包括规则引擎，定义良好的DSL定义规则以及基于RETE算法的规则引擎，该引擎经过了优化和非常快速。此外，文档非常详尽，并且有大量书籍可以学习有关如何使用此强大框架的所有知识。

最后，Drools带有一个称为Workbench的GUI，它使我们可以可视地创建和编辑规则，而无需编写代码。这是一项致命功能，它将规则的功能置于业务分析的范围之内。

流传输架构为大数据启用CEP

流架构是CEP的关键组件。 CEP的全部重点是通过流数据（近）实时做出决策，而不是像批处理那样对历史数据进行分析来采取行动。

CEP涉及敏捷性，并且由于大量简单规则的相互作用而导致潜在的复杂行为，这些规则都实时应用于内存中的数据。基于微服务的流式传输体系结构正成为现代大规模体系结构的标准。

奥德利（O'Reilly）出版的Ted Dunning和埃伦·弗里德曼（Ellen Friedman）的《流传输体系结构》一书详细探讨了流体系结构的优点，该书可免费在线获得。我还在2016年新加坡Strata大会上就这一主题发表了演讲。请去Slideshare看一看。

一般而言，解决方案将类似于上图。收集数据源（例如传感器，收银机或日志），并使用轻型ETL将其添加到流中。然后，数据将被程序使用，该程序将事实数据直接传递到Drools KieSession中。这是内存中的工作空间，规则引擎使用模式匹配来根据内存中存在的事实查看可以触发哪些规则。

在我们提出的体系结构中，规则驻留在Drools Workbench中，它是一个GUI规则编辑器，还可以用作版本控制和要部署到生产中的规则的存储库。

这种方法的主要好处是将维护应用程序本身的过程与编辑为业务创造价值的规则的过程完全独立。工程师的任务很明确，即确保系统性能良好且稳定，而业务方面则可以专注于规则。

在上图中，我们可以看到使用MapR集群的实现可能看起来更具体。对于该特定应用程序，在其位置使用Kafka集群同样有效，尽管这样做会导致出现新用例的可能性降低，并增加系统管理的负担。这样做的原因是，Kafka集群严格限于支持流传输，而使用聚合集群则允许在同一集群上存在其他用例，无论是操作还是分析用例。

这里的一个关键点是从CEP引擎的第二个箭头回去流。它说明了将流用于输入和输出的重要概念，这是流体系结构的核心。这也是为什么显示企业IT系统也从流中获取其数据的原因。

数据流如下所示：

数据从数据源流到事件生产者，后者只是一个流生产者，或者使用新的Kafka REST Proxy调用REST端点。新发行的MapR Ecosystem Pack 2.0中的 MapR Streams也支持REST代理。

CEP引擎可以从流中读取数据，并从Drools Workbench获取其规则。从流架构的角度来看，Drools Workbench和CEP Engine是一个单元，可以说是一个微服务，因为它们是完全独立的，并且没有任何外部依赖性。

当规则在规则处理算法中触发时，将需要采取一些外部动作。这些操作可能是在公司数据库中插入或更新表，索引到Elasticsearch以将数据提供给Kibana仪表板，发送通知。但是，我们不是通过直接从CEP Engine到外部系统进行调用来将系统紧密耦合在一起，而是将CEP Engine的数据输出回流中的另一个主题。另一个微服务或应用程序（例如Cask.co或Streamsets ）将处理该流。