事件处理模型Word格式.docx
《事件处理模型Word格式.docx》由会员分享，可在线阅读，更多相关《事件处理模型Word格式.docx（9页珍藏版）》请在冰豆网上搜索。
概念基础
支持事件处理的架构（即事件处理系统）的概念构建块应该提供事件处理逻辑等核心功能，并通过事件连接事件创建者和使用者。
用于考虑这样的架构和系统的一个有用的模型是事件处理网络（EPN）构造，这是一个概念构想，用于描述事件处理系统的结构和这些系统都应支持的公共特性。
EPN将事件处理系统描述为相互交互的事件创建者、处理代理和事件使用者的集合。
从这个意义上讲，EPN的主要职责是从创建者接收事件，将事件传递到适当的事件处理代理组合以处理事件，然后将处理后的事件交付给适当的使用者。
本文第二部分将详细介绍事件处理网络构造，该部分主要介绍事件处理的概念模型。
这个概念模型包含虚拟化、事件数据库、事件驱动的中间件、事件处理语言，以及在从建模和编程到监控和响应的整个事件生命周期中支持事件管理所需的所有组件。
事件处理类型
根据事件处理的复杂程度，事件处理功能可以宽泛地归为以下两类：
简单事务处理：
简单事件，即不聚合、表示或预示其他事件的事件，直接被过滤或路由，无需修改。
这样，一个明显的事件发生，触发下游动作，每个事件都被独立处理。
尽管称为“简单”事件，但这样的事件能够提供巨大的价值和大量业务信息。
事件被转换，涉及转换和分割事件，然后合并为一个或多个事件。
简单事件处理的例子包括：
将事件架构从一种形式更改为另一种形式，使用额外的数据增大事件负载，将事件从一个通道或流重定向到另一个，基于单个事件的负载生成多个事件。
这种类型的事件处理并不能总是区分为一个单独的类型。
复杂事件处理：
跨越多个独立事件的模式受到检测，以便派生新的“复杂事件”（复杂事件是聚合、表示或预示其他事件的事件）。
复杂事件处理包括处理一组事件，以便检测一个具有业务意义的情形。
通常，这种处理涉及应用一个评估条件或约束集合到一个事件集合上。
这些事件（显著的或普通的）可能跨越不同的事件类型，且可能在一个特定的时间段内发生。
事件可能在多个维度上相互关联，包括偶然、临时、空间和其他维度。
应该要认识到来自复杂事务处理的信息虽然具有复杂性和丰富性，但是它们对于用户来说并不是（也不应该）是复杂的。
尽管各种编程模型被用于表达这些构造，但是事件处理构造的模型化和实现受到应用程序集成中间件以及各种网络和系统管理平台的支持。
复杂事件处理工具和引擎在最近几年才开始出现。
事件处理可以结合分析技术来预测事件，挖掘模式并将实时分析嵌入到路由决策和事件派生中。
使用这些种类的技术来进行实时事件分析将支持在决策制定周期中做出更明智的决策。
业务事件处理
业务事件处理以事件处理为基础并进行了扩展，以一种可使用的方式提供给业务用户。
业务事件处理将功能和工具扩展到业务用户，允许应用这些技术来构造有利于业务的事件驱动信息系统。
感知一个事件或事件模式已经发生或没有发生（这表明一个可操作的业务情形）的能力使业务能够对机遇和威胁做出快速反应。
业务经理和分析师理解可操作的情形，即关键事件或事件组合和为响应那些事件而即将采取的操作。
他们每天都要处理这样的情形，并直接负责了解它们发生的时间并管理响应。
但是，他们没有可用的解决方案来支持他们自己识别并响应这些情形的数量和复杂性。
与此同时，尽管如今有数以百万计的可操作事件正在IT基础设施内自由流动，但支持高级事件处理功能需要一组专门的功能；
但是大多数IT组织没有有效且高效地支持这些要求的技术。
BusinessEventProcessing是专门设计来应对这个挑战的，即，利用流经业务系统的信息来支持业务决策制定流程。
BusinessEventProcessing的功能是：
感知一个事件，表明一个可操作业务情形已经出现，并在适当的时间协调适当的响应（操作）。
BusinessEventProcessing提供一组集成的系统和基础设施，在企业范围内监控事件的发生。
这种类型的处理在重要事件发生时识别它们，触发警报，并发布关于这个事件的信息来启动适当的响应。
作为一个BusinessProcessManagement解决方案的一个组成部分时，BusinessEventProcessing提供及时的事件模式检测和动态业务流程执行的强大组合。
BusinessEventProcessing向IT部门提供在高性能、可管理和可伸缩的环境中支持高级事件处理要求的功能。
另外，通过包含一个非编程的图形用户界面，BusinessEventProcessing使业务用户能够自己定义事件处理交互和操作。
事件处理的价值
事件处理的基本原则已经在应用程序集成中间件和各种类型的系统软件（比如操作系统、网络和系统管理软件）中广泛使用了一段时间。
但是，事件处理的重要价值体现在从业务上下文中识别事件的意义，并识别与该事件关联的适当响应。
反过来，这可以允许企业对新机遇和竞争威胁做出快速响应，及时将相关信息发布给适当的人员，支持主动问题诊断，并有利于创建业务常规状态的一个实时视图。
事件处理可以帮助企业识别趋势和威胁，抓住机遇来减小风险，缩短价值实现时间，并支持快速的感知和响应周期。
事件处理在各个行业中的市场越来越大，比如：
资本市场中的交易者希望对细微的价格差异做出反应。
军事或情报分析人员评估卫星流和传感器数据来确定适当的进攻和防御行动。
运输和后勤企业利用交通工具实时遥感探测技术来更有效地管理车辆和船舶。
银行家持续跟踪交易来发现欺诈、洗钱和金融违规行为。
通信服务运营商寻求最小化网络中的平均维修时间（mean-time-to-repair）故障。
石油公司基于实时操作数据动态确定钻探的深度和宽度。
汽车配件供应商利用复杂的制造决策来为制造商实施“零库存”生产提供配件
在所有这些情形和其他情形中，都有实时处理大量复杂数据的内在要求，而事件处理能够提供这个能力。
企业从批处理转变到实时处理以进行快速决策的需求是推动事件处理需求的另一个原因。
新兴的工作负载的特征也需要接近实时的复杂事件处理，这不仅涉及数据事件，还涉及源自语音和视频等非常规源的事件。
这个观点得到一些行业分析师的支持，比如Gartner，他指出，几种形式的事件（从简单事件到复杂事件）将在业务应用程序中得到更广泛的应用。
实现事件驱动的业务流程有巨大的财务和战略好处，因为它们适合真实世界中的许多方面所固有的事件驱动特性。
事件驱动流程不只是运行更快的传统流程；
相反，它们拥有区别于“传统业务”的特有特征。
事件驱动的应用程序允许快速修改流程，从而响应干扰传统流程的错误和异常情况。
随着企业致力于降低成本并提高对客户、供应商和整个世界的响应性，事件驱动设计的概念得到了越来越广泛的应用。
企业正在通过实现事件驱动的业务流程而获得好处，这不仅因为这种业务流程符合业务固有的事件驱动特性，而且因为这种业务流程向他们提供了成本和价值实现时间方面的竞争优势。
概念模型
我们的概念模型呈现两个不同的事件处理系统视图，旨在抽象地描述重要的概念和它们之间的关系，并剔除了所有技术细节。
EventProcessingNetwork（EPN）抽象了一个事件处理系统的输入、处理和输出元素的关键特性。
在EPN概念的指引下，我们的概念架构识别可用于实现一个事件处理系统的抽象架构元素（或组件）以及它们之间的关系，以便提供业务价值。
这个概念架构处在一个抽象层面上，独立于可用于提供这些组件的技术、协议和产品。
这个概念架构的目标有两个：
构成事件处理系统和事件驱动应用程序的基础；
提供一个公共架构来指定、比较和对比不同的事件处理解决方案架构和实现。
我们的意图是：
这个概念架构在一个概念层面上提供一组充足的组件，事件处理系统的实现可以基于这些组件构造；
但是没有必要实现给定系统中不需要的任何组件，也没有任何遵从这个模型的暗含概念。
事件处理网络
我们的事件处理系统高级抽象应用来自事件处理网络构造（见图5）的概念。
如前所述，事件处理网路是一个概念构想，描述事件处理系统的结构和应该全部支持的公共特性。
一个EPN包含4个组件：
事件创建者、事件使用者、事件处理代理（简称为EPA）以及一个称为事件通道的连接组件。
EPN描述从创建者接收的事件如何通过代理传输到使用者，这些代理通过（例如）执行转换、验证或补充（enrichment）来处理这些事件。
从一个组件流向另一个组件的任何事件必须流经一个事件通道，如图5所示，图5展示了事件通道、使用者、创建者和处理代理之间的关系。
事件通道是一些节点，它们将创建者连接到EPN中的EPAs，根据需要将EPAs连接到一起，并将EPAs连接到使用者，导致事件从事件创建者流出，经过EPN，到达事件使用者。
图5还展示：
由EPN中的事件创建者创建的各种事件可以由通过通道连接的适当的EPAs组处理，以便那些事件（或由它们派生的事件）由EPN中的各种事件使用者所使用。
事件通道
事件通道是一种机制，用于将事件或事件流从事件创建者和EPAs发送到事件使用者和EPAs。
在这个抽象级别，对于事件通道的属性（比如是否每个通道可以移动一个以上的事件类型）或移动事件的机制没有施加任何约束。
事件通道可以从多个不同的事件创建者和EPA接收多个事件，也可以将来自几个源的合并事件传输到多个EPA或使用者。
用于创建合并事件集合的来自不同EPAs和事件创建者的多个事件的顺序是特定于实现的，且没有被这个概念模型涵盖；
在有些情况下，不需要任何特殊的排序。
但是，事件通道的职责是从事件创建者和/或EPAs接收事件，排序（如果需要）并合并，然后提供给适当的事件使用者和/或EPAs。
事件通道的另一个职责是：
根据决定任意已保留事件的保留期限和过滤条件的保留策略，保留通过的事件的历史，以便进行追溯事件处理。
追溯事件处理是在事件历史上发现事件模式，与在线事件处理相反，后者在新事件可用时探测预定义的事件模式。
事件通道在EPN中表示为节点，带有指向节点和来自节点的线（edge）。
每个进入的线表示来自一个事件创建者或事件处理代理的一些事件，这个事件创建者或事件处理代理将这些事件放置到通道上；
每个出去的线表示发送到一个事件使用者或处理代理的事件，这个事件使用者或处理代理从通道接收这些事件。
事件创建者和使用者
事件创建者通过事件通道创建事件，供有关方面使用。
有关方面可以是事件使用者或EPAs。
概念模型没有对从事件创建者或EPAs获取事件的机制进行任何限制；
如果要进行限制，可能会涉及“推”或“拉”模型。
在一个由节点和线组成的网络中，事件创建者表示为源节点，即这种节点只存在发出的线。
从源节点发出的线的数量就是将一些事件从创建者移动到即将接收这些事件的EPAs或使用者所涉及的不同事件通道的数量。
事件创建者可以将一个事件发布或提供给多个事件通道；
但是，作为一种设计实践，最好将路由交给EPAs决定，以便更好地控制、设计和理解整个事件处理需求。
事件使用者对允许它执行其职责的事件感兴趣。
一旦事件使用者接收到感兴趣的事件，它将执行与这个事件关联的一个或多个任务。
事件使用者被表示为一个汇点，即只有指向它的线。
指向它的线的数量就是将事件移动到这个使用者涉及的不同事件通道的数量。
同一个事件可以通过多个事件通道接收；
但是，何处、何时以及如何接收事件的逻辑最好留给EPAs决定，以便更好地控制、设计和理解整个事件处理需求。
这并不是说事件使用者不可以是事件创建者，而是当它充当后面的角色时，它将作为EPN中的事件创建者出现。
事件处理代理
在分布式和异构系统中，事件创建者可能不会创建事件使用者期望接收的事件。
这些事件可能与预期的语法（结构）或语义含义不同，或者与两者都不同。
还有这样的情况：
单个事件将不会触发由事件使用者执行的操作，相反，这个操作由在不同的时间和不同的上下文中发生的多个事件的一个复杂组合触发。
需要EPAs（有时也称为事件中介）来探测原始事件中的模式，以便通过补充、转换和验证来处理这些事件，最终派生新事件并发布它们。
EPAs负责创建这些派生事件，并决定在何处、以何种方式提供这些事件。
EPA拥有三个可能的阶段：
模式匹配：
如果需要，这个阶段负责选择将根据一个指定模式进行处理的事件。
执行模式匹配的EPA称为“模式探测EPA”。
处理：
如果需要，这个阶段负责将处理功能应用到满足模式的选中事件，生成派生事件。
发送：
这个阶段负责将事件或派生事件发送到一个通道。
EPA从事件通道接收事件以进行模式探测或其他处理，非常类似于事件使用者从事件通道接收事件并处理事件。
EPA在发送事件时通过事件通道送出事件，非常类似于事件创建者通过事件通道发送它创建的事件。
在一个由节点和线组成的网络中，EPA表示为节点，带有指向节点和来自该节点的线。
指向该节点的线的数量就是代理用于它的功能（比如探测模式）的不同事件通道的数量。
来自该节点的线的数量就是代理用于根据处理和发送定义发送事件的不同事件通道的数量。
总之，EventProcessingNetwork（EPN）就是通过事件通道连接的事件处理操作的有向图。
网络中的EPAs提供事件处理服务和中介；
即，获取一组由一个或多个事件组成的事件组作为输入，执行一些处理，然后返回一组由零个或多个事件组成的事件组（可能是新的）作为输出。
EventProcessingNetwork的主要职责是从创建者接收事件，将它们传递到一个事件处理代理组合，处理事件，然后将事件交付给适当的使用者。
概念架构
这个概念架构构建在EPN的概念之上，方法是定义一个事件处理解决方案中可能涉及的各种组件。
在EPN层面上，这些组件中的一部分等同于一个EPA，或者一组互联的EPAs，而其他组件则与事件流的关系更加紧密，等同于EPN中的通道。
这个小节后面的图11将展示这个概念架构如何映射到EPN。
支持业务事件处理的任何系统架构都应该支持事件处理逻辑的灵活定义：
事件模式的探测、新事件的派生、以及基于需要的业务逻辑从创建者到使用者的路由。
这样，业务能够对变化做出反应，执行相关的流程，并影响基于这些变化的当前流程。
另外，这样的事件处理定义应该容易修改，并根据业务需求（比如业务流程和策略的更改）快速部署。
为理解这种业务价值如何从业务处理系统产生，重要的是考虑比事件处理网络更深的一层细粒度，即考虑可用于构造一个事件处理系统的组件及其交互。
这个流程的结果即我们所说的事件处理系统的概念架构。
除了一个事件驱动系统的三个典型层——事件创建者及其关联组件、事件使用者及其关联组件以及一个中间的事件总线层——之外，这个概念架构还需要包含用于事件和事件流的安全、监控、分析和管理的组件。
在最简单的层面上，一组最小的概念组件要求一个事件处理系统包含一个事件发送器层来从事件创建者发送事件，一个事件总线层，以及一个事件处理器层（用于处理事件），以供事件使用者使用。
图9展示了这个最小的事件处理概念架构，还包含一些事件创建者和事件使用者的示例。
事件发送器（EventEmitter）层、事件总线（EventBus）层和事件处理器/接收器（EventHandler/Receiver）层中也许还需要其他功能。
在实践中，从事件创建者生成的事件并不总是能立即被事件使用者共享。
由于在一个事件处理系统中，事件创建者并不一定具有事件使用者意识，因此，创建者和使用者之间通常需要一个中间件层。
这个中间件层执行其他事件相关任务，并允许使用者接收那些感兴趣的事件，或者接收那些事件的派生事件。
创建者生成的事件并不一定具有要求的格式，遇到这种情况时，这些事件需要在被发布到中间层之前转换为符合要求的（企业标准）格式。
在某些情况下，一个普通事件可能由一个事件预处理器（路由器、过滤器）评估以引起注意，导致生成一个新的显著事件。
事件处理代理能够在创建者的领域内过滤和调整原始事件。
类似地，并不是所有位于使用者端的事件都具有可以使用的形态。
因此，使用者端可能需要一些处理和调整。
在使用者端进行处理之前，一个普通事件可能需要由一个事件预处理器（过滤器）进行评估以引起注意。
使用者可能会选择不理睬接收到的部分事件。
事件处理服务在事件处理器层实现这些预发布和预接收事件处理要求。
图10展示了这个事件处理概念架构的所有组件。
将这个概念架构作为概念层面上的基础组件集，任何事件处理实现都应该能够得以实现，但这并不是说每个实现中都需要所有组件。
类似地，对于任意给定场景，并不是所有组件都是必要的。
我们稍后将回到上述三个场景，了解它们如何映射到这个概念架构，那时我们将看到，并不是每个组件都会被涉及到，而且这种情况是很普遍的。
这个概念架构还包含事件治理（EventGovernance）和安全服务，用于管理和控制事件的生命周期和事件元数据。
事件监控和分析基础设施（EventMonitoringandAnalyticInfrastructure）用于实现主要的管理目的，通知事件基础设施中的故障，收集并显示关于事件流的统计数据。
这些功能需要覆盖整个事件流，因此在“概念模型”图表的右边部分展示。
这样，这个概念架构表示将事件发送到事件总线的事件创建器，这些事件在事件总线中处理，最终被事件使用者使用。
作为一个事件的结果，一个使用者可以生成另一个事件，或者以其他方式回应另一个组件，结果，这个组件本身又生成一个事件。
图11展示了这个概念架构如何构建在一个EPN的概念之上的示例，其中展示了等同于EPAs或者一些互联的EPAs的集合的组件，以及提供事件通道服务的其他组件。
升级会员 