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

基于docker微服务架构

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

这篇文章旨在详细介绍我将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的Streaming Architecture一书中详细探讨了流架构的好处，该书可免费在线获得。我还在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 ）将处理该流。