事件处理系统的概念模型

简介

很多领域中的企业过去总是以一种事件驱动的方式经营，且必须每天处理不断增加的业务事件和交易。事件处理（Event Processing，EP）是一个新兴的领域，主要受到企业对这种大量业务和 IT 事件进行快速响应的需求所推动。它通过更有效地处理具有企业意义的事件来满足支持决策制定周期的需求，在面向服务架构（Service Oriented Architectures，SOAs）企业战略中变得越来越重要。

本文首先讨论为何需要进行事件处理，不同类型的事件处理，以及企业采用事件处理架构的价值。然后，本文详细介绍一个事件处理概念模型，该模型 用于实现一个事件驱动架构（Event Driven Architecture，EDA）。本文将通过讨论三个为改进决策制定而实现事件处理的业务场景来展示这些概念。

 

事件处理概述

事件是任何经常发生或认为正在发生的重要事情。一个事件要么完全发生，要么根本没发生，且具有重要意义，因为它可能会影响某个动作。事件被认 为正在发生是因为它可能是一个正在变成事实的事件，也可能是真实世界中的一个实体的转变过程。事件可能是一个业务流程的一部分，例如，一个交易订单已经发 出；或者，事件也可能关于 IT 基础设施、中间件、应用程序和业务流程的监控信息。图 1 提供了事件处理的一个高级概览。

图 1. 事件处理概览

一个事件（企业内外部发生的一件重要事情）可能会触发一个服务的调用，一个业务流程的启动，和/或更多信息的发布或聚合。事件处理的任务就是 处理一个或多个事件，其目的是识别事件云中有意义的事件。从业务价值角度看，事件处理是探测和响应一些特殊事件的能力，这些特殊事件表明企业内出现了一些 会影响业务的情况。例如，一条事件消息可能会表明添加了一个新客户，出售了一个产品，收到了一批货，打开了一扇安全门，通过 GPS 提供一个资产的当前位置，等等。

事件创建者（或源）生成事件。事件创建者可以是应用程序、数据存储、服务、业务流程、发送器、传感器或者协作工具，比如即时消息传递或电子邮 件应用程序。从创建者接收事件时，这些事件可以直接导致结果，或者针对事件处理模式进行评估。事件处理模式针对有关各方而不是事件创建者的需求定义。事件 处理结果包括（但不局限于）调用一个服务，启动一个业务流程，将事件发布到一个订阅中心，直接通知人员或系统，生成一个新事件，以及捕获事件以备用。事件 及其与业务服务之间的交互通常称为事件驱动信息系统或事件驱动架构。

 

概念基础

支持事件处理的架构（即事件处理系统）的概念构建块应该提供事件处理逻辑等核心功能，并通过事件连接事件创建者和使用者。用于考虑这样的架构 和系统的一个有用的模型是事件处理网络（EPN）构造，这是一个概念构想，用于描述事件处理系统的结构和这些系统都应支持的公共特性。EPN 将事件处理系统描述为相互交互的事件创建者、处理代理和事件使用者的集合。从这个意义上讲，EPN 的主要职责是从创建者接收事件，将事件传递到适当的事件处理代理组合以处理事件，然后将处理后的事件交付给适当的使用者。本文第二部分将详细介绍事件处理 网络构造，该部分主要介绍事件处理的概念模型。这个概念模型包含虚拟化、事件数据库、事件驱动的中间件、事件处理语言，以及在从建模和编程到监控和响应的 整个事件生命周期中支持事件管理所需的所有组件。

事件处理类型

根据事件处理的复杂程度，事件处理功能可以宽泛地归为以下两类：

• 简单事务处理 ：简单事件，即不聚合、表示或预示其他事件的事件，直接被过滤或路由，无需修改。这样，一个明显的事件发 生，触发下游动作，每个事件都被独立处理。尽管称为 “简单” 事件，但这样的事件能够提供巨大的价值和大量业务信息。事件被转换，涉及转换和分割事件，然后合并为一个或多个事件。简单事件处理的例子包括：将事件架构 从一种形式更改为另一种形式，使用额外的数据增大事件负载，将事件从一个通道或流重定向到另一个，基于单个事件的负载生成多个事件。这种类型的事件处理并 不能总是区分为一个单独的类型。
• 复杂事件处理 ：跨越多个独立事件的模式受到检测，以便派生新的 “复杂事件”（复杂事件是聚合、表示或预示其他事件的事件）。复杂事件处理包括处理一组事件，以便检测一个具有业务意义的情形。通常，这种处理涉及应用一 个评估条件或约束集合到一个事件集合上。这些事件（显著的或普通的）可能跨越不同的事件类型，且可能在一个特定的时间段内发生。事件可能在多个维度上相互 关联，包括偶然、临时、空间和其他维度。应该要认识到来自复杂事务处理的信息虽然具有复杂性和丰富性，但是它们对于用户来说并不是（也不应该）是复杂的。

尽管各种编程模型被用于表达这些构造，但是事件处理构造的模型化和实现受到应用程序集成中间件以及各种网络和系统管理平台的支持。复杂事件处 理工具和引擎在最近几年才开始出现。事件处理可以结合分析技术来预测事件，挖掘模式并将实时分析嵌入到路由决策和事件派生中。使用这些种类的技术来进行实 时事件分析将支持在决策制定周期中做出更明智的决策。

业务事件处理

业务事件处理以事件处理为基础并进行了扩展，以一种可使用的方式提供给业务用户。业务事件处理将功能和工具扩展到业务用户，允许应用这些技术 来构造有利于业务的事件驱动信息系统。感知一个事件或事件模式已经发生或没有发生（这表明一个可操作的业务情形）的能力使业务能够对机遇和威胁做出快速反 应。

图 2. 业务事件处理：将业务透视图添加到业务处理功能

业务经理和分析师理解可操作的情形，即关键事件或事件组合和为响应那些事件而即将采取的操作。他们每天都要处理这样的情形，并直接负责了解它 们发生的时间并管理响应。但是，他们没有可用的解决方案来支持他们自己识别并响应这些情形的数量和复杂性。与此同时，尽管如今有数以百万计的可操作事件正 在 IT 基础设施内自由流动，但支持高级事件处理功能需要一组专门的功能；但是大多数 IT 组织没有有效且高效地支持这些要求的技术。Business Event Processing 是专门设计来应对这个挑战的，即，利用流经业务系统的信息来支持业务决策制定流程。

Business Event Processing 的功能是：感知一个事件，表明一个可操作业务情形已经出现，并在适当的时间协调适当的响应（操作）。Business Event Processing 提供一组集成的系统和基础设施，在企业范围内监控事件的发生。这种类型的处理在重要事件发生时识别它们，触发警报，并发布关于这个事件的信息来启动适当的 响应。作为一个 Business Process Management 解决方案的一个组成部分时，Business Event Processing 提供及时的事件模式检测和动态业务流程执行的强大组合。Business Event Processing 向 IT 部门提供在高性能、可管理和可伸缩的环境中支持高级事件处理要求的功能。另外，通过包含一个非编程的图形用户界面，Business Event Processing 使业务用户能够自己定义事件处理交互和操作。

事件处理的价值

事件处理的基本原则已经在应用程序集成中间件和各种类型的系统软件（比如操作系统、网络和系统管理软件）中广泛使用了一段时间。但是，事件处 理的重要价值体现在从业务上下文中识别事件的意义，并识别与该事件关联的适当响应。反过来，这可以允许企业对新机遇和竞争威胁做出快速响应，及时将相关信 息发布给适当的人员，支持主动问题诊断，并有利于创建业务常规状态的一个实时视图。

事件处理可以帮助企业识别趋势和威胁，抓住机遇来减小风险，缩短价值实现时间，并支持快速的感知和响应周期。事件处理在各个行业中的市场越来越大，比如：

• 资本市场中的交易者希望对细微的价格差异做出反应。
• 军事或情报分析人员评估卫星流和传感器数据来确定适当的进攻和防御行动。
• 运输和后勤企业利用交通工具实时遥感探测技术来更有效地管理车辆和船舶。
• 银行家持续跟踪交易来发现欺诈、洗钱和金融违规行为。
• 通信服务运营商寻求最小化网络中的平均维修时间（mean-time-to-repair）故障。
• 石油公司基于实时操作数据动态确定钻探的深度和宽度。
• 汽车配件供应商利用复杂的制造决策来为制造商实施 “零库存” 生产提供配件

在所有这些情形和其他情形中，都有实时处理大量复杂数据的内在要求，而事件处理能够提供这个能力。企业从批处理转变到实时处理以进行快速决策 的需求是推动事件处理需求的另一个原因。新兴的工作负载的特征也需要接近实时的复杂事件处理，这不仅涉及数据事件，还涉及源自语音和视频等非常规源的事 件。

这个观点得到一些行业分析师的支持，比如 Gartner，他指出，几种形式的事件（从简单事件到复杂事件）将在业务应用程序中得到更广泛的应用。实现事件驱动的业务流程有巨大的财务和战略好处，因为它们适合真实世界中的许多方面所固有的事件驱动特性。

事件驱动流程不只是运行更快的传统流程；相反，它们拥有区别于 “传统业务” 的特有特征。事件驱动的应用程序允许快速修改流程，从而响应干扰传统流程的错误和异常情况。随着企业致力于降低成本并提高对客户、供应商和整个世界的响应 性，事件驱动设计的概念得到了越来越广泛的应用。企业正在通过实现事件驱动的业务流程而获得好处，这不仅因为这种业务流程符合业务固有的事件驱动特性，而 且因为这种业务流程向他们提供了成本和价值实现时间方面的竞争优势。

 

事件处理场景概述

为阐述本文表达的概念，我们将在后面各个小节中开发三个不同的事件处理场景，它们将展示在这个概述中描述的部分价值。

• 车队管理（Fleet Management）场景
• 公共健康警报（Public Health Alert）场景
• 通信服务供应商（Communication Service Provider）场景

介绍这些场景之后，我们将把各种事件处理概念映射到各个场景，并解释事件处理对每个场景的附加价值。第一个场景（车队管理）将进行详细介绍，因为我们将在这个场景中介绍一些公共特性。

我们首先介绍这些场景的业务上下文，然后在本文后面讨论涉及的事件以及到这个概念模型的各个方面的映射。

车队管理场景

这个场景描述一个 “快速递送” 公司，该公司通过一个车队专门在相对短的距离内交付小包裹；每辆车都安装了持续广播其位置的 GPS，且包裹粘贴了 RFID 标签。根据承诺的服务水平，要么立即对包裹进行点对点递送；要么将包裹递送到一个发货中心，在那里，（可能）由另一辆车将包裹递送到目的地。每个包裹都有 一个承诺的送达时间，超过这个时间将支付违约金。有些送货是固定的（在每月计划中），而有些送货则是客户通过电话（或网站）临时请求的订单。

图 3. 车队管理概述

这个场景的理念已经基于针对车队优化的 IBM 解决方案进行了优化。对于卡车和小车车队经理而言，下面是他们的一些业务管理和维护目标：

• 降低燃料成本
• 跟踪车辆和司机
• 向客户提供最新的精确到分钟的信息
• 找到简化装载、卸载和路径规划流程的最佳位置
• 提高资产利用率
• 改善客户服务
• 降低经营成本
• 减少计划外维护成本
• 降低风险以减少保险成本

为了以一种及时适当的方式来管理这个车队，该公司选择在他们的系统内利用事件处理。这样，该公司能够做出快速反应，当新的客户要求出现时能够 重新分配路线来满足这些要求，同时维持与每个客户的协议。该公司还能对风险做出反应，因为该公司能够通过在违反协议之前进行重新安排来解决问题。借助事件 处理，该公司能够对机遇和风险做出反应，其原因是：由于关于车辆、订单等的当前情况被持续监控并通过事件反映出来，因此该公司能够决定如何采取行动（来使 前面提到的指标受到控制）。该公司还能够放心地快速做出更改并将更改部署到流程中，这只需更改事件处理逻辑或应用程序，无需完成漫长的、容易出错的开发过 程。

在下面的小节中，我们将检查这个场景涉及的事件和事件处理概念。

公共健康警报场景

这个公共健康警报场景描述了将警报系统用于这样的场合：这些场合能够表明对公众存在风险的真实或潜在事件即将爆发。这样的事件的例子包括 SARS、禽流感（H5N1）或使用生化武器的恐怖袭击等。

这个场景考虑禽流感（Bird Flu）和禽流感 A（H5N1），但它也同样适用于其他事件爆发，比如 H1N1。

世界卫生组织定义的大流行病的阶段或状态显示从内部大流行状态（没有在人类当中检测到流感病毒）到大流行状态（在普通公众中出现持续的传染）的发展。这个场景主要考虑三个阶段 —— 没有检测到病毒，流行状态和大流行状态。

图 4. 公共健康警报概述

我们现在描述这个场景中将发生的事情。一个进行血液分析的实验室检测到一个病毒。根据有关规定，检测到一个特定病毒被发布为一个事件。事件接 收器（我们称为事件发送器）规范化这个事件并执行一些基本的质量和起源检查，然后将它传递到事件处理代理。这个事件在事件处理代理中被添加一些信息，然后 模式探测检查是否需要提交一个流行病爆发警报。如果需要提交流行病或大流行病爆发警报，对应的事件是发送通知。来自外部事件创建者（比如国际健康组织或外 国政府）的大流行病爆发警报以类似的方式处理。

涉及的事件和这个场景与事件处理概念模型之间的关系将在后面的小节中介绍。

通信服务供应商场景

这个场景描述一个通信服务供应商：YourCSP 公司。该公司向国内客户和中小企业提供各种有线通信服务，服务范围包括到 VOIP 的宽带 Internet 接入和虚拟专用网服务等。该公司的核心 MPLS (Multiprotocol Label Switching) 网络包含来自多个不同的制造商的网络元素，受到各种 Element Management Systems 的支持。他们采用了一系列网络技术来连接客户的经营场所，包括 Dial-Up、DSL 以及支持 Layer 2 和 Layer 3 VPNs 的技术。

根据客户购买的特殊服务包，该公司提供各种不同的服务水平协议（Service Level Agreement，SLA）。这些 SLA 包含保证承诺的服务水平的合同，服务水平根据一些指标来度量，比如服务持续性，可用网络带宽等。没有实现的 SLAs 将导致 YourCSP 支付违约金，并且会损害公司声誉。该公司根据对客户的承诺服务水平对客户进行分级。

与所有通信服务供应商一样，YourCSP 公司也采用了一个网络操作中心，该中心包含雇员、硬件和软件资产，专门用于保证公司核心网络的顺利运行，提供相应的服务。他们的目标包括：

• 最小化网络故障的平均维修时间，这些故障可能会导致网络停用或向公司客户提供的服务水平下降。
• 根据受影响客户的 SLA 来确定停用和故障的维修优先顺序，从而最小化公司的财务风险。
• 最大化网络资产的利用率。
• 最小化人力成本和能源消耗等经营成本。
• 在发生影响服务的故障时提供与客户的预先沟通，使其与上述故障的修复进度保持同步。

YourCSP 的网络操作中心使用网络管理和事件处理技术来实现上述目的。这些系统处理多种不同类型的事件，包括表示以下问题的事件：

• 网络中检测到的故障
• 网络元素的状态更改
• 包含网络设备的场所中的环境条件和网络设备本身
• 事件自动响应的结果
• 响应网络事件的操作人员的操作
• 故障解决的自动探测

对这些事件数据的访问，以及处理它们的工具允许网络操作中心：

• 监控核心网络包含的元素，获取健康、可用性和性能信息。
• 将网络事件规范化为一种公共格式，以便实现统一的虚拟化和处理。
• 向网络操作中心操作人员提供网络中已经发生的事件的最新交互式视图。
• 自动发现和维护核心网络的最新模型以便：
  • 维护已部署资产的可见性
  • 维护物理和逻辑网络拓扑的模型及其与提供的网络服务的关系
  • 向操作人员提供网络地图仪表板，以便进行问题诊断和故障排除
  • 对网络事件和服务停用执行基于网络拓扑的根源事件分析
  • 支持新服务的提供流程
• 执行大量网络失败场景的自动响应、诊断和修补。
• 执行关于事件的模式分析，进行关于原因和业务影响的网络事件推断。
• 执行基于技术、拓扑和业务上下文的网络事件充实。
• 定义在 YourCSP 的服务桌面应用程序中自动创建问题票据（trouble ticket）的策略，从而促进物理维修工作。

YourCSP 与中型企业 MediumCo 签订了一个合同，在 MediumCo 分散的工作场所之间提供 VPN 服务。这个合同带有一个关联 SLA，承诺提供高水平可用性。YourCSP 为 MediumCo 的每个工作场所提供并管理一个专用 Customer Edge Router (CE)，以便连接到 YourCSP 的核心网络。每个 CE 都连接到 YourCSP 的工作场所中的一个 Provider Edge Router (PE)。

如果 PE 路由器中出现一个故障，例如一个故障电路板（card），事件处理系统将接收从周边网络中的设备和元素管理系统发送的多个事件，表明出现了一些物理和逻辑 故障，包括 ICMP (Internet Control Message Protocol) ping 失败、链接关闭警报、路由协议邻接失败（adjacency failure）等。遇到这种情况，事件处理系统必须：

• 识别根源事件并向网络操作中心的操作人员突出显示，在本例中为电路板失败。
• 推断是否影响任何客户服务，在本例中为提供给 MediumCo 的 VPN 服务是否不可用。
• 根据适用的 SLAs 和网络中的其他停用确定这个服务停用的优先权，适当确定解决问题的先后顺序。在本例中，由于对 MediumCo 承诺的 SLA 很高，因此应该优先解决这个问题。
• 通知受影响的客户：故障已经确定，发出一个工作项目请求，派遣一位技术人员去解决故障。
• 探测故障的解决情况，通知操作人员和客户：常规服务已经重新建立了。

这个场景中涉及的事件和与概念模型的映射将在下面的小节中介绍。

 

概念模型

我们的概念模型呈现两个不同的事件处理系统视图，旨在抽象地描述重要的概念和它们之间的关系，并剔除了所有技术细节。Event Processing Network (EPN) 抽象了一个事件处理系统的输入、处理和输出元素的关键特性。在 EPN 概念的指引下，我们的概念架构识别可用于实现一个事件处理系统的抽象架构元素（或组件）以及它们之间的关系，以便提供业务价值。这个概念架构处在一个抽象 层面上，独立于可用于提供这些组件的技术、协议和产品。

这个概念架构的目标有两个：构成事件处理系统和事件驱动应用程序的基础；提供一个公共架构来指定、比较和对比不同的事件处理解决方案架构和实现。

我们的意图是：这个概念架构在一个概念层面上提供一组充足的组件，事件处理系统的实现可以基于这些组件构造；但是没有必要实现给定系统中不需要的任何组件，也没有任何遵从这个模型的暗含概念。

 

事件处理网络

我们的事件处理系统高级抽象应用来自事件处理网络构造（见图 5）的概念。如前所述，事件处理网路是一个概念构想，描述事件处理系统的结构和应该全部支持的公共特性。

图 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 表示为节点，带有指向节点和来自该节点的线。指向该节点的线的数量就是代理用于它的功能（比如探测模式）的不同事件通道的数量。来自该节点的线的数量就是 代理用于根据处理和发送定义发送事件的不同事件通道的数量。

总之，Event Processing Network (EPN) 就是通过事件通道连接的事件处理操作的有向图。网络中的 EPAs 提供事件处理服务和中介；即，获取一组由一个或多个事件组成的事件组作为输入，执行一些处理，然后返回一组由零个或多个事件组成的事件组（可能是新的）作 为输出。Event Processing Network 的主要职责是从创建者接收事件，将它们传递到一个事件处理代理组合，处理事件，然后将事件交付给适当的使用者。

 

事件处理网络场景

现在我们将事件处理网络定义和组件映射到 “事件处理场景概述” 小节中描述的场景中。

车队管理场景

以下是一些事件处理网络组件（创建者、使用者、事件通道、事件处理代理以及事件），它们仅仅描述前面提到的 “跟踪车辆和司机” 中的一个方面。这个公司实施了一些规章制度，以便确保司机的安全并避免事故，因此一名司机的一次倒班工作时间不能超过 8 小时。超过这个工作时间的所有司机都会被强制要求休息；为避免向客户延迟交货并支付罚金，递送的货物必须重新分配给其他司机。这个重新分配过程需要在公司 的一个设备中设置一个适当的会面地点来实现，以便将货物从一辆车转移到另一（几）辆车上，并重新计算路径，从而使延迟时间（如果有）降到最小。将提供一个 司机报告系统，其中生成司机倒班的开始和结束事件。只有基于这些事件和对车辆位置的持续监控，这个重新分配过程才能得以实现。另外，对事件进行补充、“超 过驾驶时间” 模式的探测和路径设置还有一些要求，它们被描述为事件处理代理。

表 1. 事件创建者

事件创建者	说明
Vehicle	GPS 广播位置，车载传感器（燃料、排放、重量等）
Driver Report System	电子穿孔卡片
Delivery System	订单管理，包裹分类和分配，车辆调度系统
Package RFID System	包裹跟踪系统，发货中心配备采集器，员工配备移动采集器（比如司机在收集、转移和运送包裹时使用）

表 2. 事件使用者

事件使用者	说明
Driver Display	路径、交货更改和警报的车载或移动司机显示器
Delivery Management Dashboard	完整的操作视图 —— 车辆位置、路径、订单、包裹等
Clients	订单发送器或接收器能够接收通知或查询它们的订单

表 3. 事件

事件类型 ID	事件类型	属性	注释
E1	Driver starts working	Timestamp; Driver ID	-
E2	Driver starts working enriched	Timestamp; Driver ID; Vehicle ID; Driver Name	-
E3	Driver ends working	Timestamp; Driver ID	可以基于 E1 的结构
E4	Driver Exceeded Driving Time	Timestamp; Driver ID; Vehicle ID; Driver Name	-
E5	Delivery Change	Timestamp; Driver1 ID; Vehicle1 ID; Driver2 ID; Vehicle2 ID; Sender ID; Receiver ID	-

表 4. 事件通道

事件通道 ID	事件类型	创建者	使用者	保留策略
EC1	E1	Driver Report System	A1	-
EC2	E2	A1	A2	-
EC3	E3	Driver Report System	A2	-
EC4	E4	A2	A3, Delivery Management Dashboard	-
EC5	E5	A3	A4	-
EC6	E5	A4	Clients, Driver Display, Delivery Management Dashboard	1 周

表 5. 事件处理代理示例 1

代理属性	说明
Agent ID	A1
Agent Name	Enrich Driver Starts Working
Agent Type	Enrich
Agent Context	-
Input Events	E1
Agent Specification	通过 Driver ID 补充，Vehicle ID 和 Driver Name 来自 Driver Details
Output Events	E2
Agent Comment	使用车辆 ID 等司机信息补充事件

表 6. 事件处理代理示例 2

代理属性	说明
Agent ID	A2
Agent Name	Driver Exceeded Driving Time
Agent Type	Detect Pattern
Agent Context	interval(E2,+8h) by Driver ID
Input Events	E3
Agent Specification	缺少 E3
Output Events	-

表 7. 事件处理代理示例 3

代理属性	说明
Agent ID	A3
Agent Name	Delivery Reallocation
Agent Type	Detect Pattern
Agent Context	-
Input Events	E4, Ex
Agent Specification	通过 Driver ID 充实，Vehicle ID 和 Driver Name 来自 Driver Details
Output Events	E5
Agent Comment	这个代理接收不同类型的事件来推断送货更改要求。这个代理的职责是决定哪辆车应该接管送货工作，以及如何使两辆车在一个发货中心或其他位置会面

表 8. 事件处理代理示例 4

代理属性	说明
Agent ID	A4
Agent Name	将 Reallocation Notification 路由给所需的用户
Agent Type	Router
Agent Context	-
Input Events	E5
Agent Specification	-
Output Events	E5
Agent Comment	将送货更改路由到不同的客户。客户可能会收到通知（将在 1 周之内反复尝试），司机将获取他们的新指示，操作将能够跟踪这些新指示

下面的图 6 以图表方式展示了这个 EPN 的组件。当一位司机开始他的工作时，Driver Report System 创建事件 E1 并将该事件发布到通道 EC1 上。事件 E1 由事件处理代理 A1 补充，生成派生事件 E2。8 小时以后，当该司机超过他的驾驶时间且没有交班时，代理 A2 创建事件 E4。事件 E4 被发送到 Delivery Management Dashboard 以便进行控制。代理 A3 通过通道 EC4 接收这个事件，并将该司机的订单重新分配给其他司机来送货，但是同时避免超过其他司机的驾驶时间。这个重新分配指示通过事件 E5 发送通知，代理 A4 路由这个事件并将其重定向给几个需要通知的使用者 —— 那位超过驾驶时间的司机、需要装载并运送他的订单的一位或几位司机，需要了解送货路径和到达时间更改的客户、以及用于控制的 Delivery Management Dashboard。只有当该司机将他的货物转移给其他司机时，他的这班工作才结束，且事件 E3 被创建（这个事件对前面描述的代理没有影响）。

图 6. 车队管理场景的 EPN 的图形表示

公共健康警报场景

下面的表列示了在 “事件处理场景概述” 中描述的公共健康警报场景的事件处理网络组件。这个场景的 EPAs 没有详细介绍。

表 9. 事件创建者

事件创建者	说明
Hospital	医院会检测可能的病毒或迹象并发送一个事件
Laboratory	实验室会检测可能的病毒或迹象并发送一个事件
Physician	医生会检测可能的病毒或迹象并发送一个事件
Foreign Government Agency	外国政府部门将发送一个事件

表 10. 事件使用者

事件使用者	说明
Pharmaceutical Company	制药公司订阅健康警报事件
Government Agency	政府部门订阅健康警报事件
General Practitioner	普通医疗从业人员订阅健康警报事件，这些事件可能会使用关于特征和探测模式的更多细节进行补充
Health Insurer	健康保险公司订阅健康警报事件
News Agency	新闻机构订阅健康警报事件
Homeland Security	国内安全部门订阅可能通过特定预警信息和探测模式补充的健康警报事件

还有一种 “中间人” 的概念，这个中间人实现这个 Event Processing Network (EPN)，提供事件创建者（不知道事件将由谁使用，如何使用）和事件使用者（不关心事件起源和原始事件的原始形态或意义）之间的分离。

除了事件创建者和 EPN 与事件使用者和 EPN 之间的关系之外，我们还可以想象一下这样的例子：创建者（通过一个 Web 页面或提要）公开提供事件且 EPN 检索到这个信息。另一方面，这个 EPN 也将这个事件公开提供（也许通过相同的机制）给事件使用者。这样，创建者和 EPN 与使用者和 EPN 之间就出现了分离，我们还可以想象一个没有中间人的直接分离场景。

表 11. 事件

事件类型 ID	事件类型	属性	注释
E1	Potential Epidemic Outbreak Alert	ID; Details	Converse Event 是 No Potential Epidemic Outbreak
E2	Potential Epidemic Outbreak normalized	ID; Timestamp; Location; Details	来自原始事件的 Normalized / Transformed Event
E3	Potential Epidemic Outbreak enriched	ID; Timestamp; Location; More Details	已补充的事件
E4	Epidemic Outbreak Detected Alert	ID; Timestamp; Location; Details	流行病爆发已经被检测到（模式检测）
E5	Epidemic Outbreak Alert	ID; Timestamp; Location; Details	-
E6	Potential Pandemic Outbreak Alert	ID; Timestamp; Location; Details	-
E7	Potential Pandemic Outbreak normalized	ID; Timestamp; Location; Details	流行病爆发已经被检测到（模式检测）
E8	Potential Pandemic Outbreak enriched	ID; Timestamp; Location; More Details	已补充的事件
E9	Pandemic Outbreak Detected Alert	ID; Timestamp; Location; Details	流行病爆发已经被检测到（模式检测）
E10	Pandemic Outbreak Alert	ID; Timestamp; Location; Details	-

图 7 提供了这个 EPN 的一个图形表示。

图 7. 公共健康警报场景的 EPN

通信服务供应商场景

下面的表列示了在 “事件处理场景概述” 中描述的通信服务供应商场景的事件处理网络组件（事件创建者、事件处理代理、事件使用者和事件）。

表 12. 事件创建者

事件创建者	说明
Network Monitor	轮询网络设备以获取可用性和性能数据的软件，通常使用 ICMP 和 SNMP 等协议。生成的事件表示对网络元素的明显更改，以及常规操作的例外
Network Element Probes	从网络元素接收警报，生成的事件表示网络元素及其物理和逻辑邻居中的明显更改和故障。通常使用 SNMP 等协议来监听警报
Element Management System Probe	从 Element Management Systems 接收表示受管理的网络元素中的故障和明显更改的警报。可能在广泛的标准或专有协议（包括 SNMP、SOAP、CORBA、平面文件）上使用标准或专有事件格式
Event Operator Dashboard	基于操作人员的操作生成事件，包括来自网络设备和服务停用的事件的确认、解决和完结

表 13. 事件使用者

事件使用者	说明
Operator Dashboards	针对网络操作中心操作人员的重要事件交互式视图，包括可定制的诊断工具和过滤功能
Network Engineer telephone handsets and email system	来自关键事件的 SMS 消息和电子邮件的接收者，这些关键事件已经被系统升级
Customer views	针对受影响的客户过滤的服务中的已探测到的停用的最新只读视图
Trouble Ticket system	从系统接收需要网络工程和维护团队采取动作的事件

表 14. 事件类型

类型 ID	事件类型	属性	注释
E1	Ping failed	Timestamp; Unreachable address	-
E2	Link Down	Timestamp; Port name of down link on PE router; Address of PE router	-
E3	Card Failure	Timestamp; Address of PE router; Card identifier	-
E4	Root cause event	As E3	E3 的副本，识别为根源
E5	Symptom events	As E1 and E2; Associated root cause	E1 和 E2 的副本，识别为症状
E6	VPN service affected	Timestamp; VPN Identifier	-
E7	VPN service affected enriched	As E6; Customer Contact Details	-
E8	Technician dispatched	Timestamp; Technician contact details	-
E9	Ping success	Timestamp; Pinged Address	-
E10	Link Up	Timestamp; Port name of re-established link on PE router; Address of PE router	-
E11	Card Up	Timestamp; Address of PE router; Card identifier	-
E12	VPN service active	Timestamp; VPN Identifier	-

表 15. 事件处理代理示例 1

代理属性	说明
Agent ID	A2
Agent Name	Service Impact Analyzer
Agent Type	Pattern Detection
Agent Context	-
Input Events	E4, E5
Agent Specification	如果客户的网络服务受到干扰，生成 Service Affected 事件
Output Events	E6
Agent Comments	使用网络元素和提供的服务之间的已建模关系来确定服务是否受到影响

表 16. 事件处理代理示例 2

代理属性	说明
Agent ID	A3
Agent Name	Customer Impact Analyzer
Agent Type	Routing, Enrich
Agent Context	-
Input Events	E6
Agent Specification	根据与 SLA 关联的策略升级 Service Affected 事件；使用客户联系人细节进行补充
Output Events	E7
Agent Comments	-

表 17. 事件处理代理示例 3

代理属性	说明
Agent ID	A4
Agent Name	Prioritization Module
Agent Type	Routing, Enrich
Agent Context	-
Input Events	E7
Agent Specification	使用相对优先权补充事件
根据优先权将事件路由到使用者	-
通过 Trouble Ticket 系统促成 Corrective Action	-
Output Events	E4, E5, E7, E8
Agent Comments	-

图 8 提供了这个场景中使用的事件处理网络部分的图形描述，截至派遣技术人员这个时点。

图 8. 通信服务供应商场景的 EPN

 

概念架构

这个概念架构构建在 EPN 的概念之上，方法是定义一个事件处理解决方案中可能涉及的各种组件。在 EPN 层面上，这些组件中的一部分等同于一个 EPA，或者一组互联的 EPAs，而其他组件则与事件流的关系更加紧密，等同于 EPN 中的通道。这个小节后面的图 11 将展示这个概念架构如何映射到 EPN。

支持业务事件处理的任何系统架构都应该支持事件处理逻辑的灵活定义：事件模式的探测、新事件的派生、以及基于需要的业务逻辑从创建者到使用者 的路由。这样，业务能够对变化做出反应，执行相关的流程，并影响基于这些变化的当前流程。另外，这样的事件处理定义应该容易修改，并根据业务需求（比如业 务流程和策略的更改）快速部署。

为理解这种业务价值如何从业务处理系统产生，重要的是考虑比事件处理网络更深的一层细粒度，即考虑可用于构造一个事件处理系统的组件及其交 互。这个流程的结果即我们所说的事件处理系统的概念架构。除了一个事件驱动系统的三个典型层 —— 事件创建者及其关联组件、事件使用者及其关联组件以及一个中间的事件总线层 —— 之外，这个概念架构还需要包含用于事件和事件流的安全、监控、分析和管理的组件。

在最简单的层面上，一组最小的概念组件要求一个事件处理系统包含一个事件发送器层来从事件创建者发送事件，一个事件总线层，以及一个事件处理器层（用于处理事件），以供事件使用者使用。图 9 展示了这个最小的事件处理概念架构，还包含一些事件创建者和事件使用者的示例。

图 9. 最小的事件处理概念架构

事件发送器（Event Emitter）层、事件总线（Event Bus）层和事件处理器/接收器（Event Handler/Receiver）层中也许还需要其他功能。在实践中，从事件创建者生成的事件并不总是能立即被事件使用者共享。由于在一个事件处理系统 中，事件创建者并不一定具有事件使用者意识，因此，创建者和使用者之间通常需要一个中间件层。这个中间件层执行其他事件相关任务，并允许使用者接收那些感 兴趣的事件，或者接收那些事件的派生事件。创建者生成的事件并不一定具有要求的格式，遇到这种情况时，这些事件需要在被发布到中间层之前转换为符合要求的 （企业标准）格式。在某些情况下，一个普通事件可能由一个事件预处理器（路由器、过滤器）评估以引起注意，导致生成一个新的显著事件。事件处理代理能够在 创建者的领域内过滤和调整原始事件。

类似地，并不是所有位于使用者端的事件都具有可以使用的形态。因此，使用者端可能需要一些处理和调整。在使用者端进行处理之前，一个普通事件 可能需要由一个事件预处理器（过滤器）进行评估以引起注意。使用者可能会选择不理睬接收到的部分事件。事件处理服务在事件处理器层实现这些预发布和预接收 事件处理要求。

图 10 展示了这个事件处理概念架构的所有组件。将这个概念架构作为概念层面上的基础组件集，任何事件处理实现都应该能够得以实现，但这并不是说每个实现中都需要 所有组件。类似地，对于任意给定场景，并不是所有组件都是必要的。我们稍后将回到上述三个场景，了解它们如何映射到这个概念架构，那时我们将看到，并不是 每个组件都会被涉及到，而且这种情况是很普遍的。

图 10. 事件处理概念架构 —— 一个事件处理系统中可能会涉及的组件

架构组件

这个概念架构中的事件流是从创建者到使用者，上图中展示的组件将按照这个顺序在这里进行总结。下一小节将详细描述这个概念模型中的处理流。在实现层面上，事件使用者通常也是事件创建者；但是在概念层面上，使用者和创建者的角色是分离的。

• 事件创建者。事件创建者在有关事项发生（或没有发生）时发出一个事件。事件创建者没有包含处理事件的逻辑，也不包含有关在何时发送何种事件的决策逻辑，生成的事件可能是冗余或不相关的。典型的事件创建者示例包括：
  • 事件传感器，它探测情况（发生的事情）并生成原始事件，或者从数据流或业务流生成事件 —— 温度的传输就是一个例子。
  • 监视器和探测器，它们生成关于系统内的可用性和问题的事件，比如一个 IT 网络中的故障。
  • 业务流程，它们在流程中的重要时点（比如里程碑和检查点）生成事件，或者在一个特定的流程任务到达或启动时生成事件。
  • 服务和应用程序，它们在流程中的关键点生成事件，比如当服务被调用或完成，或者当服务失败时。
  • 状态机器，它在状态改变时生成事件。
• 事件发送器（Event Emitter）。它在逻辑上（尽管并不一定在物理上）与事件创建者相关联，负责转换和打包来自创建者的原始事件，以便发送到事件总线（Event Bus）。事件发送器可能包含一个事件实例化器（Event Instantiator），它创建事件的实例，简单事件处理服务（Simple Event Processing Services，比如过滤和调整由单个创建者发出的事件，使用事件发生时可用的信息来补充事件），以及事件适配器（Event Adapter）。事件实例化器从创建者接收事件，执行任意（如果有）必要的操作来使其可用于进一步的事件处理或发送，这些操作可能包含事件的聚合、缓存 和序列化。事件实例化器可能需要用于操作事件头部，以便将 “语义元数据” 嵌入到事件消息本身中，从而使其具有自我描述功能（带有时间、日期、工具类型、处理 ID 等信息）。事件发送器可以通过在这个阶段（而不是在事件到达事件总线之后）执行简单的事件处理来提供优化。事件适配器可以提供事件的格式化和协议转换，将 其转换为可以被事件处理网络接收的形态，比如将事件记录封装为事件消息并将事件消息发送到事件总线。
• 事件总线。事件总线从事件发送器接收事件（事件的量可能非常大），并通过事件处理器调用使用者，作为事件的结果。事件总线的功能之一是处理事件，从进入的事件派生出事件量更少、信息更丰富的事件。事件总线的组件不必同时位于一个位置。下一小节将详细介绍事件总线。
• 事件处理器（Event Handler）。这个组件准备来自事件总线的事件，以便事件使用者使用，接收事件并决定如何反应。事件处理器拥有一些事件适配器，用于从事件总线接收事 件消息，打开消息包装，获取事件记录。事件处理器还能提供简单事件处理服务，这些服务执行使用者端处理，过滤和调整从事件总线接收的事件。事件处理器还能 确定将对事件做出反应的适当使用者，使用源自事件的上下文调用那些使用者。最后，事件处理器还能提供事件编排（orchestration）服务，管理对 使用者的事件分发。
• 事件使用者。事件使用者执行一些任务，以对事件做出反应。事件使用者不太关心事件的起源，只是意识到它正在被调用，这是事件及其相关上下文的结果。典型的事件使用者示例包括：
  • 事件执行器（Event Actuator），它们被调用来执行一些任务，比如操作阀门、开关或警报。
  • 操作人员仪表板，它们显示关于 IT 系统和受影响的服务的行为的信息。
  • 业务仪表板，它们显示关于业务流程的行为的信息。
  • 业务流程，它们可以被启动或恢复，以响应一个事件。
  • 服务和应用程序，它们可以被调用以响应一个事件，可以包含外部内容管理系统或事件存储库。
  • 状态机器（State Machine），它们的状态可以被更改，以响应一个事件。

这个概念架构视图基于每个组件的角色，但并不是说这个架构中的一个特殊参与者不能执行多个角色：一个事件创建者也可以执行事件处理并能充当一个事件使用者。尤其是，发布和订阅服务只在使用一个 “发布/订阅” 样式的模型时才需要。

这个概念架构可以认为是 “嵌套的”，因为任一参与者都可以在其中包含一个具有更多组件的网络。例如，一个事件创建者可以发送一个事件到主事件总线，但是在生成那个事件的过程中， 可以想象这个总体模型的一个 “微型” 版本，其中，一个创建者发送一个初始简单事件，以便与一个 “微型” 事件总线中的其他事件进行模式匹配，这个 “微型” 事件总线逻辑上驻留在这个总体事件创建者中。

事件总线组件

事件总线将事件从创建者传输到使用者，可以提供其他服务来处理和路由事件。事件总线可能拥有一个关联的事件注册表，可能拥有通过使用一个事件存储库来执行实时（in-flight）事件的（临时或持久）事务性存储的能力。

事件总线可以是本地的，也可以在企业层面上实现，接收到的事件需要根据业务要求来处理。这种处理通过使用简单和复杂事件处理服务来实现。这些服务通过一些事件处理代理提供，这些代理通过事件通道连接在一起。

事件总线提供的服务（或构建块）包括：

• 事件通道，它们将事件从事件发送器传输到事件总线，在事件总线的组件之间传输事件，以及将事件传输到事件处理器。
• 发布服务，允许创建者将事件发送到适当的通道。
• 订阅服务，支持创建者和使用者的动态注册，比如允许事件处理器找到适当的通道，并订阅来自那些通道的事件。
• 通知服务，在事件可用时通知已订阅的事件处理器，支持 “推” 和 “拉” 事件。
• 查询服务，允许查询一个存储库，获取事件