复杂事件处理使得用户可以及时收集到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支持引入新的维度。
本文转自d1net（转载）
