百度搜索 网站介绍,公司网站制作有哪些,yellow片观看完整版,凡科互动游戏作弊软件基于docker微服务架构基于微服务的流架构与开源规则引擎相结合#xff0c;使实时业务规则变得容易 这篇文章旨在详细介绍我将OSS业务规则引擎与Kafka风格的现代流消息传递系统集成在一起的项目。 该项目的目标#xff08;即众所周知的复杂事件处理#xff08;CEP#xff0… 基于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涉及敏捷性并且由于大量简单规则的相互作用而导致潜在的复杂行为这些规则都实时应用于内存中的数据。 流式基于微服务的体系结构正成为现代大规模体系结构的标准。 OReilly出版的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 将处理该流。 结论 复杂事件处理已经存在了一段时间但现在终于有了自己的应用。 在硬件方面具有大量内存的服务更为普遍。 在软件方面有可能完全在OSS之外创建有用的生产级CEP系统而无需诉诸昂贵的自定义编码的流应用程序。 将Kafka风格的流消息传递系统与Drools结合在一起为组织提供了非常需要的敏捷性以区分创建和维护企业流应用程序的非常不同的任务以及为实时决策定义和编辑业务逻辑。 在下一篇博客文章中我们将介绍一个具体的用例将所有这些都付诸实践并说明如何仅使用JavaMapR集群和在Wildfly应用程序服务器上运行的Drools Workbench即可实现这种系统。 翻译自: https://www.javacodegeeks.com/2017/01/better-complex-event-processing-scale-using-microservices-based-streaming-architecture-part-1.html基于docker微服务架构
