理解CEP应用真正特点

日期:2016-2-22作者:Tom Nolle翻译:崔婧雯来源:TechTarget中国 英文

复杂事件处理   CEP   

【TechTarget中国原创】

复杂事件处理使得用户可以及时收集到BI从而影响当前运营。但是要想通过事件驱动架构带来价值要求真正彻底地理解CEP。

IT领域的每个人都知道分析,以及借助大量历史数据作出更优业务决策的价值。这里应用程序的挑战在于“历史”这个限定词。大多数分析工具是设计来处理大量已经收集到的数据的,而不是处理正在收集的数据。

随着数据收集,分析和操作间间隔时间的缩短,分析应用演变出了完全不同的东西:复杂事件处理(CEP)。CEP应用提供的实时智能处理能够帮助企业借助数据修改当前的操作,而不仅仅是修改未来的操作。但是,有效地利用事件驱动架构要求用户理解CEP的真正含义,CEP的三个基本模型及其特性,以及CEP内在的限制。

核心CEP概念

让我们从一些定义入手。事件指在业务里发生的事情,包括业务活动、流程状态、网络或IT条件,或者其他任何东西。很多事件只要能够识别出来就可以进行处理,通常会伴随着发送警报。当无法可靠处理单个事件而必须在上下文里分析时,就会使用CEP。几乎所有场景里,CEP分析都要求事件能够实时关联,并且要求带有准确时间戳的一定格式。

CEP应用大致分为两大类:事件关联和根本原因分析。通常来说,事件关联用来识别不是单个事件,而是多个事件组合起来触发的条件,比如“如果你打喷嚏并且发烧了,那么你感冒了。”根本原因分析用来解释一系列事件—通常是错误—的底层原因,确保补救措施并不仅仅针对症状,而是能够真正解决问题。

所有CEP都应该是实时的,或者和事件同时发生,但是,当然这里的同时发生意味着很多种情况。CEP处理的关系越复杂,就越难保证实时性。CEP地实现有三种公认的模型,所有模型都是在复杂度,实时操作和流程消耗之间寻求平衡。

选择CEP模型

有效利用事件驱动架构要求用户真正理解CEP的含义,CEP的三个基本模型及其特性,以及CEP内在的限制。

CEP的最简单方案是触发或者阈值激活处理。该模型里,事件要么直接导致一些操作的发生,要么是当事件达到某个阈值时会执行某个操作。CEP能够在从源到目的地的事件流里引入事件处理,比如在线事务处理,因为生成的延时很小。虽然触发或阈值CEP能够通过单个类型事件实现,但是也可以使用多个不同权重的不同事件来提供对条件更为深入的理解。

第二种模型是上下文模型,该模型假定一个事件或者事件集在某个特定的上下文里才有意义,因此需要维护这个上下文。可以通过模式匹配来完成,意味着查找满足某个模式的特定事件集,或者当事件改变某个显式上下文或状态时通过状态事件处理,随后在上下文理解事件。后一种方案很广泛地用于网络管理,这里上下文示例可能包括初始化,激活或者错误。

对于更为复杂的CEP,可以使用级联分析模型,这里的事件流包括使用某个CEP模型处理的一种或者多种类型的事件。它们并不是直接采取操作加以处理,而是生成其他事件或者事件上下文,随后注入CEP的其他阶段,直到能够最终决定采取什么操作。

高效CEP的诀窍

当架构应用时,低估CEP需求的复杂性是错误的,因为选择了过于简单的模型通常会导致不完善的事件分析,并且会加大维护应用程序的复杂性,特别是在新的条件被识别出来的时候。比如用户报告,几乎一半的CEP应用都能够最终从级联分析里受益,但是10个里只有1个真的达到了这个目的。

实现事件驱动架构或者CEP不仅仅要求使用正确的模型。记住:如果事件没有流过公用点,你就无法正确分析事件,因此事件聚合可能是不可或缺的一步。也要记住随着CEP模型从简单阈值向级联分析的演进,分析事件所需的时间以及制定流程决策的时间都将变长。要处理的事件变得越来越复杂,因此必须更加小心地设计CEP应用程序,并且需要花费更多的时间来保证分析的完成。

区分CEP应用也很重要,可以基于CEP是否是应用处理的主要驱动者,还是事件已经发送到其他被分析的应用来做额外的流程管理来加以区别。安全是后者的很好示例:通过截获事件,并且查看入侵或不正常使用的迹象,来保护某些东西。当然不能因此反过来影响到主要的应用程序。

能够有助于在已确定的事务或者事件流里引入CEP的一种方法是复制或摘要事件。可以使用阈值分析的简单CEP模型来完成主要事件处理,但是用该模型生成第二类事件集,分发到常规事务和事件流程之外让CEP来处理。这会避免复制整个事件流,那样从资源的角度来看会很昂贵,并且限制CEP对已有应该的影响。

记住CEP基于同时发生的事件上下文的确定。分析基于上下文的历史恢复。如果你不需要采取实时行动,那么可以采用更为便宜的分析方案,也能够轻松揭露预料之外的条件或者情况。CEP设计用来响应特定事情,并不适合分析的数据挖掘模型。但是,如果使用正确,CEP可以辅助分析,并且让一些分析流程更接近实时,同时给业务运营的IT支持引入新的维度。

我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。

我原创,你原创,我们的内容世界才会更加精彩!

【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

评论
查看更多评论

敬请读者发表评论,本站保留删除与本文无关和不雅评论的权力。

作者>更多

Tom Nolle
Tom Nolle

关于作者:Tom Nolle是CIMI公司的总裁,这家公司成立于1982年,是致力于电信和数据通信的战略顾问公司。Tom Nolle是IEEE、ACM、Telemanagement Forum和IPsphere Forum的一员,著作有关于Netwatcher方面的书籍。

SOA与IT治理>更多

  • 把软件架构演进体现在栈上

    曾几何时,企业架构师要为了得到承认和支持而抗争,但这种时候正在过去。大多数企业现在已经意识到实现业务流程中敏捷性和效率需要业务目标、人力资源以及信息技术的结合。

  • SOA治理模型核心:人

    治理在IT领域非常关键,但是很多时候企业的做法往往太过单向,企业SOA治理模型往往忽视了所有部分当中最关键的组件:人。

  • 顶级APM软件大PK

    管理应用性能说起来容易做起来难。在探索很多种方式,研究很多种趋势之后,应用性能管理能够快速地从简单进化到复杂。对于APM软件而言也是如此。

  • 理解CEP应用真正特点

    IT领域的每个人都知道分析,以及借助大量历史数据作出更优业务决策的价值。这里应用程序的挑战在于“历史”这个限定词。

相关推荐

技术手册>更多

  • 应用生命周期管理(ALM)学习

    在当今世界,IT对于一个企业的重要性是毋庸置疑的,简单的用一句话可以概括——“应用就是业务”!IT的发展速度非常之快,我们不仅要问,究竟是什么原因会促使这种反战的继续?答案只有一个,业务驱动。这就对IT提出了一种挑战,快速地生产并交付出能够满足新的业务过程的需要的业务应用系统,这就涉及到了应用生命周期管理。

  • UDDI(统一描述发现和集成)

    UDDI统一描述、发现和集成协议,是为解决Web服务的发布和发现问题而制订的新一代基于Internet的电子商务技术标准。全称Universal Description, Discovery and Integration,它包含一组基于Web的、分布式的Web服务信息注册中心的实现标准,以及一组使企业能将自己提供的Web服务注册到该中心的实现标准。UDDI利用SOAP消息来查找和注册Web服务。并为应用程序提供了一系列接口来访问注册中心。

    UDDI(统一描述发现和集成) 提供一种发布和查找服务描述的方法。UDDI数据实体提供对定义业务和服务信息的支持。WSDL中定义的服务描述信息是UDDI注册中心信息的补充。

  • 架构框架TOGAF学习指南

    TOAGF是一个架构框架,简而言之,TOGAF是一种协助发展,验收,运行,使用,和维护架构的工具。它是基于一个迭代(Iterative)的过程模型,支持最佳实践和一套可重用的现有架构资产。

  • 企业云ERP学习

    云之一词的出现带起一片“云海”,也改变了很多事情,改变传统的IT架构模式,冲击了传统的业务运作模式。那么企业内部资源规划,即ERP系统当然不能落于人后。

TechTarget

最新资源
  • 安全
  • 存储
  • CIO
  • 数据库
  • 服务器
  • 云计算