事件處理模型

1、事件處理概述事件是任何經(jīng)常發(fā)生或認為正在發(fā)生的重要事情一個事件要么完全發(fā)生，要么根本沒發(fā)生,且具有重要意義，因為它可能會影響某個動作。事件被認為正在發(fā)生是因為它可能是一個正在變成事實的事件，也可能是真實世界中的一個實體的轉(zhuǎn)變過程。事件可能是一個業(yè)務流程的一部分，例如，一個交易訂單已經(jīng)發(fā)出；或者，事件也可能關(guān)于IT基礎(chǔ)設施、中間件、應用程序和業(yè)務流程的監(jiān)控信息。圖1提供了事件處理的一個高級概覽。TurbulentDisparale,NQn-Dcljerministk4Non-ScquemialEvents事件處理概覽一個事件（企業(yè)內(nèi)外部發(fā)生的一件重要事情）可能會觸發(fā)一個服務的調(diào)用，一個業(yè)務流程的

2、啟動，和/或更多信息的發(fā)布或聚合。事件處理的任務就是處理一個或多個事件，其目的是識別事件云中有意義的事件。從業(yè)務價值角度看，事件處理是探測和響應一些特殊事件的能力，這些特殊事件表明企業(yè)內(nèi)出現(xiàn)了一些會影響業(yè)務的情況。例如，一條事件消息可能會表明添加了一個新客戶，出售了一個產(chǎn)品，收到了一批貨，打開了一扇安全門，通過GPS提供一個資產(chǎn)的當前位置，等等。事件創(chuàng)建者（或源）生成事件。事件創(chuàng)建者可以是應用程序、數(shù)據(jù)存儲、服務、業(yè)務流程、發(fā)送器、傳感器或者協(xié)作工具，比如即時消息傳遞或電子郵件應用程序。從創(chuàng)建者接收事件時，這些事件可以直接導致結(jié)果，或者針對事件處理模式進行評估。事件處理模式針對有關(guān)各方而不是事

3、件創(chuàng)建者的需求定義。事件處理結(jié)果包括（但不局限于）調(diào)用一個服務，啟動一個業(yè)務流程，將事件發(fā)布到一個訂閱中心，直接通知人員或系統(tǒng)，生成一個新事件，以及捕獲事件以備用。事件及其與業(yè)務服務之間的交互通常稱為事件驅(qū)動信息系統(tǒng)或事件驅(qū)動架構(gòu)。概念基礎(chǔ)支持事件處理的架構(gòu)（即事件處理系統(tǒng)）的概念構(gòu)建塊應該提供事件處理邏輯等核心功能，并通過事件連接事件創(chuàng)建者和使用者。用于考慮這樣的架構(gòu)和系統(tǒng)的一個有用的模型是事件處理網(wǎng)絡（EPN）構(gòu)造，這是一個概念構(gòu)想，用于描述事件處理系統(tǒng)的結(jié)構(gòu)和這些系統(tǒng)都應支持的公共特性。EPN將事件處理系統(tǒng)描述為相互交互的事件創(chuàng)建者、處理代理和事件使用者的集合。從這個意義上講，EPN的主

4、要職責是從創(chuàng)建者接收事件，將事件傳遞到適當?shù)氖录幚泶斫M合以處理事件，然后將處理后的事件交付給適當?shù)氖褂谜?。本文第二部分將詳細介紹事件處理網(wǎng)絡構(gòu)造，該部分主要介紹事件處理的概念模型。這個概念模型包含虛擬化、事件數(shù)據(jù)庫、事件驅(qū)動的中間件、事件處理語言，以及在從建模和編程到監(jiān)控和響應的整個事件生命周期中支持事件管理所需的所有組件。事件處理類型根據(jù)事件處理的復雜程度，事件處理功能可以寬泛地歸為以下兩類：簡單事務處理：簡單事件，即不聚合、表示或預示其他事件的事件，直接被過濾或路由，無需修改。這樣，一個明顯的事件發(fā)生，觸發(fā)下游動作，每個事件都被獨立處理。盡管稱為“簡單”事件，但這樣的事件能夠提供巨大的

5、價值和大量業(yè)務信息。事件被轉(zhuǎn)換，涉及轉(zhuǎn)換和分割事件，然后合并為一個或多個事件。簡單事件處理的例子包括：將事件架構(gòu)從一種形式更改為另一種形式，使用額外的數(shù)據(jù)增大事件負載，將事件從一個通道或流重定向到另一個，基于單個事件的負載生成多個事件。這種類型的事件處理并不能總是區(qū)分為一個單獨的類型。復雜事件處理：跨越多個獨立事件的模式受到檢測，以便派生新的“復雜事件”（復雜事件是聚合、表示或預示其他事件的事件）。復雜事件處理包括處理一組事件，以便檢測一個具有業(yè)務意義的情形。通常，這種處理涉及應用一個評估條件或約束集合到一個事件集合上。這些事件（顯著的或普通的）可能跨越不同的事件類型，且可能在一個特定的時間段

6、內(nèi)發(fā)生。事件可能在多個維度上相互關(guān)聯(lián)，包括偶然、臨時、空間和其他維度。應該要認識到來自復雜事務處理的信息雖然具有復雜性和豐富性，但是它們對于用戶來說并不是（也不應該）是復雜的。盡管各種編程模型被用于表達這些構(gòu)造，但是事件處理構(gòu)造的模型化和實現(xiàn)受到應用程序集成中間件以及各種網(wǎng)絡和系統(tǒng)管理平臺的支持。復雜事件處理工具和引擎在最近幾年才開始出現(xiàn)。事件處理可以結(jié)合分析技術(shù)來預測事件，挖掘模式并將實時分析嵌入到路由決策和事件派生中。使用這些種類的技術(shù)來進行實時事件分析將支持在決策制定周期中做出更明智的決策。業(yè)務事件處理業(yè)務事件處理以事件處理為基礎(chǔ)并進行了擴展，以一種可使用的方式提供給業(yè)務用戶。業(yè)務事件處

7、理將功能和工具擴展到業(yè)務用戶，允許應用這些技術(shù)來構(gòu)造有利于業(yè)務的事件驅(qū)動信息系統(tǒng)。感知一個事件或事件模式已經(jīng)發(fā)生或沒有發(fā)生（這表明一個可操作的業(yè)務情形）的能力使業(yè)務能夠?qū)C遇和威脅做出快速反應。EventProcessingBusinessUserInterfaceBusinessEventProcessing業(yè)務經(jīng)理和分析師理解可操作的情形，即關(guān)鍵事件或事件組合和為響應那些事件而即將采取的操作。他們每天都要處理這樣的情形，并直接負責了解它們發(fā)生的時間并管理響應。但是，他們沒有可用的解決方案來支持他們自己識別并響應這些情形的數(shù)量和復雜性。與此同時,盡管如今有數(shù)以百萬計的可操作事件正在IT基礎(chǔ)設

8、施內(nèi)自由流動，但支持高級事件處理功能需要一組專門的功能；但是大多數(shù)IT組織沒有有效且高效地支持這些要求的技術(shù)。BusinessEventProcessing是專門設計來應對這個挑戰(zhàn)的，即，利用流經(jīng)業(yè)務系統(tǒng)的信息來支持業(yè)務決策制定流程。BusinessEventProcessing的功能是：感知一個事件，表明一個可操作業(yè)務情形已經(jīng)出現(xiàn)，并在適當?shù)臅r間協(xié)調(diào)適當?shù)捻憫ú僮鳎?。BusinessEventProcessing提供一組集成的系統(tǒng)和基礎(chǔ)設施，在企業(yè)范圍內(nèi)監(jiān)控事件的發(fā)生。這種類型的處理在重要事件發(fā)生時識別它們，觸發(fā)警報，并發(fā)布關(guān)于這個事件的信息來啟動適當?shù)捻憫?。作為一個BusinessPro

9、cessManagement解決方案的一個組成部分時，BusinessEventProcessing提供及時的事件模式檢測和動態(tài)業(yè)務流程執(zhí)行的強大組合。BusinessEventProcessing向IT部門提供在高性能、可管理和可伸縮的環(huán)境中支持高級事件處理要求的功能。另外，通過包含一個非編程的圖形用戶界面，BusinessEventProcessing使業(yè)務用戶能夠自己定義事件處理交互和操作。事件處理的價值事件處理的基本原則已經(jīng)在應用程序集成中間件和各種類型的系統(tǒng)軟件（比如操作系統(tǒng)、網(wǎng)絡和系統(tǒng)管理軟件）中廣泛使用了一段時間。但是，事件處理的重要價值體現(xiàn)在從業(yè)務上下文中識別事件的意義，并識別

10、與該事件關(guān)聯(lián)的適當響應。反過來，這可以允許企業(yè)對新機遇和競爭威脅做出快速響應，及時將相關(guān)信息發(fā)布給適當?shù)娜藛T，支持主動問題診斷，并有利于創(chuàng)建業(yè)務常規(guī)狀態(tài)的一個實時視圖。事件處理可以幫助企業(yè)識別趨勢和威脅，抓住機遇來減小風險，縮短價值實現(xiàn)時間，并支持快速的感知和響應周期。事件處理在各個行業(yè)中的市場越來越大，比如：資本市場中的交易者希望對細微的價格差異做出反應。軍事或情報分析人員評估衛(wèi)星流和傳感器數(shù)據(jù)來確定適當?shù)倪M攻和防御行動。運輸和后勤企業(yè)利用交通工具實時遙感探測技術(shù)來更有效地管理車輛和船舶。銀行家持續(xù)跟蹤交易來發(fā)現(xiàn)欺詐、洗錢和金融違規(guī)行為。通信服務運營商尋求最小化網(wǎng)絡中的平均維修時間(mean

11、-time-to-repair)故障。石油公司基于實時操作數(shù)據(jù)動態(tài)確定鉆探的深度和寬度。汽車配件供應商利用復雜的制造決策來為制造商實施“零庫存”生產(chǎn)提供配件在所有這些情形和其他情形中，都有實時處理大量復雜數(shù)據(jù)的內(nèi)在要求，而事件處理能夠提供這個能力企業(yè)從批處理轉(zhuǎn)變到實時處理以進行快速決策的需求是推動事件處理需求的另一個原因。新興的工作負載的特征也需要接近實時的復雜事件處理，這不僅涉及數(shù)據(jù)事件,還涉及源自語音和視頻等非常規(guī)源的事件。這個觀點得到一些行業(yè)分析師的支持，比如Gartner，他指出，幾種形式的事件(從簡單事件到復雜事件)將在業(yè)務應用程序中得到更廣泛的應用。實現(xiàn)事件驅(qū)動的業(yè)務流程有巨大的財

12、務和戰(zhàn)略好處，因為它們適合真實世界中的許多方面所固有的事件驅(qū)動特性。事件驅(qū)動流程不只是運行更快的傳統(tǒng)流程;相反，它們擁有區(qū)別于“傳統(tǒng)業(yè)務”的特有特征。事件驅(qū)動的應用程序允許快速修改流程，從而響應干擾傳統(tǒng)流程的錯誤和異常情況。隨著企業(yè)致力于降低成本并提高對客戶、供應商和整個世界的響應性，事件驅(qū)動設計的概念得到了越來越廣泛的應用。企業(yè)正在通過實現(xiàn)事件驅(qū)動的業(yè)務流程而獲得好處，這不僅因為這種業(yè)務流程符合業(yè)務固有的事件驅(qū)動特性，而且因為這種業(yè)務流程向他們提供了成本和價值實現(xiàn)時間方面的競爭優(yōu)勢。概念模型我們的概念模型呈現(xiàn)兩個不同的事件處理系統(tǒng)視圖，旨在抽象地描述重要的概念和它們之間的關(guān)系，并剔除了所有技

13、術(shù)細節(jié)。EventProcessingNetwork(EPN)抽象了一個事件處理系統(tǒng)的輸入、處理和輸出元素的關(guān)鍵特性。在EPN概念的指引下，我們的概念架構(gòu)識別可用于實現(xiàn)一個事件處理系統(tǒng)的抽象架構(gòu)元素(或組件)以及它們之間的關(guān)系，以便提供業(yè)務價值。這個概念架構(gòu)處在一個抽象層面上，獨立于可用于提供這些組件的技術(shù)、協(xié)議和產(chǎn)品。這個概念架構(gòu)的目標有兩個：構(gòu)成事件處理系統(tǒng)和事件驅(qū)動應用程序的基礎(chǔ)；提供一個公共架構(gòu)來指定、比較和對比不同的事件處理解決方案架構(gòu)和實現(xiàn)。我們的意圖是：這個概念架構(gòu)在一個概念層面上提供一組充足的組件，事件處理系統(tǒng)的實現(xiàn)可以基于這些組件構(gòu)造；但是沒有必要實現(xiàn)給定系統(tǒng)中不需要的任何組

14、件，也沒有任何遵從這個模型的暗含概念。事件處理網(wǎng)絡我們的事件處理系統(tǒng)高級抽象應用來自事件處理網(wǎng)絡構(gòu)造（見圖5）的概念。如前所述，事件處理網(wǎng)路是一個概念構(gòu)想，描述事件處理系統(tǒng)的結(jié)構(gòu)和應該全部支持的公共特性。一個EPN包含4個組件：事件創(chuàng)建者、事件使用者、事件處理代理（簡稱為EPA）以及一個稱為事件通道的連接組件。EPN描述從創(chuàng)建者接收的事件如何通過代理傳輸?shù)绞褂谜?，這些代理通過（例如）執(zhí)行轉(zhuǎn)換、驗證或補充（enrichment）來處理這些事件。從一個組件流向另一個組件的任何事件必須流經(jīng)一個事件通道，如圖5所示，圖5展示了事件通道、使用者、創(chuàng)建者和處理代理之間的關(guān)系。事件通道是一些節(jié)點,它們將創(chuàng)建

15、者連接到EPN中的EPAs,根據(jù)需要將EPAs連接到一起，并將EPAs連接到使用者，導致事件從事件創(chuàng)建者流出，經(jīng)過EPN,到達事件使用者。圖5還展示：由EPN中的事件創(chuàng)建者創(chuàng)建的各種事件可以由通過通道連接的適當?shù)腅PAs組處理，以便那些事件（或由它們派生的事件）由EPN中的各種事件使用者所使用。事件通道事件通道是一種機制，用于將事件或事件流從事件創(chuàng)建者和EPAs發(fā)送到事件使用者和EPAs。在這個抽象級別，對于事件通道的屬性（比如是否每個通道可以移動一個以上的事件類型）或移動事件的機制沒有施加任何約束。事件通道可以從多個不同的事件創(chuàng)建者和EPA接收多個事件，也可以將來自幾個源的合并事件傳輸?shù)蕉鄠€

16、EPA或使用者。用于創(chuàng)建合并事件集合的來自不同EPAs和事件創(chuàng)建者的多個事件的順序是特定于實現(xiàn)的，且沒有被這個概念模型涵蓋；在有些情況下，不需要任何特殊的排序。但是，事件通道的職責是從事件創(chuàng)建者和/或EPAs接收事件，排序（如果需要）并合并，然后提供給適當?shù)氖录褂谜吆?或EPAs。事件通道的另一個職責是：根據(jù)決定任意已保留事件的保留期限和過濾條件的保留策略，呆留通過的事件的歷史，以便進行追溯事件處理。追溯事件處理是在事件歷史上發(fā)現(xiàn)事件模式,與在線事件處理相反，后者在新事件可用時探測預定義的事件模式。事件通道在EPN中表示為節(jié)點，帶有指向節(jié)點和來自節(jié)點的線（edge）。每個進入的線表示來自一個

17、事件創(chuàng)建者或事件處理代理的一些事件，這個事件創(chuàng)建者或事件處理代理將這些事件放置到通道上；每個出去的線表示發(fā)送到一個事件使用者或處理代理的事件，這個事件使用者或處理代理從通道接收這些事件。事件創(chuàng)建者和使用者事件創(chuàng)建者通過事件通道創(chuàng)建事件，供有關(guān)方面使用。有關(guān)方面可以是事件使用者或EPAs。概念模型沒有對從事件創(chuàng)建者或EPAs獲取事件的機制進行任何限制；如果要進行限制，可能會涉及“推”或“拉”模型。在一個由節(jié)點和線組成的網(wǎng)絡中，事件創(chuàng)建者表示為源節(jié)點，即這種節(jié)點只存在發(fā)出的線。從源節(jié)點發(fā)出的線的數(shù)量就是將一些事件從創(chuàng)建者移動到即將接收這些事件的EPAs或使用者所涉及的不同事件通道的數(shù)量。事件創(chuàng)建者

18、可以將一個事件發(fā)布或提供給多個事件通道；但是，作為一種設計實踐，最好將路由交給EPAs決定，以便更好地控制、設計和理解整個事件處理需求。事件使用者對允許它執(zhí)行其職責的事件感興趣。一旦事件使用者接收到感興趣的事件，它將執(zhí)行與這個事件關(guān)聯(lián)的一個或多個任務。事件使用者被表示為一個匯點，即只有指向它的線。指向它的線的數(shù)量就是將事件移動到這個使用者涉及的不同事件通道的數(shù)量。同一個事件可以通過多個事件通道接收;但是，何處、何時以及如何接收事件的邏輯最好留給EPAs決定，以便更好地控制、設計和理解整個事件處理需求。這并不是說事件使用者不可以是事件創(chuàng)建者，而是當它充當后面的角色時，它將作為EPN中的事件創(chuàng)建者

19、出現(xiàn)。事件處理代理在分布式和異構(gòu)系統(tǒng)中，事件創(chuàng)建者可能不會創(chuàng)建事件使用者期望接收的事件。這些事件可能與預期的語法（結(jié)構(gòu)）或語義含義不同，或者與兩者都不同。還有這樣的情況：單個事件將不會觸發(fā)由事件使用者執(zhí)行的操作，相反，這個操作由在不同的時間和不同的上下文中發(fā)生的多個事件的一個復雜組合觸發(fā)。需要EPAs（有時也稱為事件中介）來探測原始事件中的模式，以便通過補充、轉(zhuǎn)換和驗證來處理這些事件，最終派生新事件并發(fā)布它們oEPAs負責創(chuàng)建這些派生事件，并決定在何處、以何種方式提供這些事件。EPA擁有三個可能的階段：模式匹配：如果需要，這個階段負責選擇將根據(jù)一個指定模式進行處理的事件。執(zhí)行模式匹配的EPA稱

20、為“模式探測EPA”。處理：如果需要，這個階段負責將處理功能應用到滿足模式的選中事件，生成派生事件。發(fā)送：這個階段負責將事件或派生事件發(fā)送到一個通道。EPA從事件通道接收事件以進行模式探測或其他處理，非常類似于事件使用者從事件通道接收事件并處理事件。EPA在發(fā)送事件時通過事件通道送出事件，非常類似于事件創(chuàng)建者通過事件通道發(fā)送它創(chuàng)建的事件。在一個由節(jié)點和線組成的網(wǎng)絡中，EPA表示為節(jié)點，帶有指向節(jié)點和來自該節(jié)點的線。指向該節(jié)點的線的數(shù)量就是代理用于它的功能（比如探測模式）的不同事件通道的數(shù)量。來自該節(jié)點的線的數(shù)量就是代理用于根據(jù)處理和發(fā)送定義發(fā)送事件的不同事件通道的數(shù)量?？傊珽ventProc

21、essingNetwork（EPN）就是通過事件通道連接的事件處理操作的有向圖。網(wǎng)絡中的EPAs提供事件處理服務和中介；即,獲取一組由一個或多個事件組成的事件組作為輸入，執(zhí)行一些處理，然后返回一組由零個或多個事件組成的事件組（可能是新的）作為輸出。EventProcessingNetwork的主要職責是從創(chuàng)建者接收事件，將它們傳遞到一個事件處理代理組合，處理事件，然后將事件交付給適當?shù)氖褂谜?。概念架?gòu)這個概念架構(gòu)構(gòu)建在EPN的概念之上，方法是定義一個事件處理解決方案中可能涉及的各種組件。在EPN層面上，這些組件中的一部分等同于一個EPA，或者一組互聯(lián)的EPAs，而其他組件則與事件流的關(guān)系更加緊

22、密，等同于EPN中的通道。這個小節(jié)后面的圖11將展示這個概念架構(gòu)如何映射到EPN。支持業(yè)務事件處理的任何系統(tǒng)架構(gòu)都應該支持事件處理邏輯的靈活定義：事件模式的探測、新事件的派生、以及基于需要的業(yè)務邏輯從創(chuàng)建者到使用者的路由。這樣，業(yè)務能夠?qū)ψ兓龀龇磻瑘?zhí)行相關(guān)的流程，并影響基于這些變化的當前流程。另外，這樣的事件處理定義應該容易修改，并根據(jù)業(yè)務需求（比如業(yè)務流程和策略的更改）快速部署。為理解這種業(yè)務價值如何從業(yè)務處理系統(tǒng)產(chǎn)生，重要的是考慮比事件處理網(wǎng)絡更深的一層細粒度，即考慮可用于構(gòu)造一個事件處理系統(tǒng)的組件及其交互。這個流程的結(jié)果即我們所說的事件處理系統(tǒng)的概念架構(gòu)除了一個事件驅(qū)動系統(tǒng)的三個典型

23、層一一事件創(chuàng)建者及其關(guān)聯(lián)組件、事件使用者及其關(guān)聯(lián)組件以及一個中間的事件總線層一一之外，這個概念架構(gòu)還需要包含用于事件和事件流的安全、監(jiān)控、分析和管理的組件。在最簡單的層面上，一組最小的概念組件要求一個事件處理系統(tǒng)包含一個事件發(fā)送器層來從事件創(chuàng)建者發(fā)送事件，一個事件總線層，以及一個事件處理器層（用于處理事件），以供事件使用者使用。圖9展示了這個最小的事件處理概念架構(gòu)，還包含一些事件創(chuàng)建者和事件使用者的示例。EventProducersEventSen&arsBusinessServicesStateMachine?Monitors迦QPrcik?s.EventEmitterEventBusE吃w

24、nllEventConsumersEventChanneisEvent、ActuatorsBusinessProcessesn*uuSen/icesStateMachines,DeaboardLJEventHandler事件發(fā)送器(EventEmitter)層、事件總線(EventBus)層和事件處理器/接收器(EventHandler/Receiver)層中也許還需要其他功能。在實踐中，從事件創(chuàng)建者生成的事件并不總是能立即被事件使用者共享。由于在一個事件處理系統(tǒng)中，事件創(chuàng)建者并不一定具有事件使用者意識，因此，創(chuàng)建者和使用者之間通常需要一個中間件層。這個中間件層執(zhí)行其他事件相關(guān)任務，并允許使用

25、者接收那些感興趣的事件，或者接收那些事件的派生事件。創(chuàng)建者生成的事件并不一定具有要求的格式，遇到這種情況時，這些事件需要在被發(fā)布到中間層之前轉(zhuǎn)換為符合要求的(企業(yè)標準)格式。在某些情況下，一個普通事件可能由一個事件預處理器(路由器、過濾器)評估以引起注意，導致生成一個新的顯著事件。事件處理代理能夠在創(chuàng)建者的領(lǐng)域內(nèi)過濾和調(diào)整原始事件。類似地，并不是所有位于使用者端的事件都具有可以使用的形態(tài)。因此，使用者端可能需要一些處理和調(diào)整。在使用者端進行處理之前，一個普通事件可能需要由一個事件預處理器(過濾器)進行評估以引起注意。使用者可能會選擇不理睬接收到的部分事件。事件處理服務在事件處理器層實現(xiàn)這些預發(fā)

26、布和預接收事件處理要求。圖10展示了這個事件處理概念架構(gòu)的所有組件。將這個概念架構(gòu)作為概念層面上的基礎(chǔ)組件集，任何事件處理實現(xiàn)都應該能夠得以實現(xiàn)，但這并不是說每個實現(xiàn)中都需要所有組件。類似地，對于任意給定場景，并不是所有組件都是必要的。我們稍后將回到上述三個場景,了解它們?nèi)绾斡成涞竭@個概念架構(gòu)，那時我們將看到，并不是每個組件都會被涉及到，而且這種情況是很普遍的。EventProducersEventEmitterEventBusEventHandlerEventsQ-niDriflMndAra-ytic=寸aa.ruelesGouEmanceO0ndFeat巾dSecuiltyse.ceMit:Risp6$i：cfiesNolificationServicesJInfo