復雜事件處理使得用戶可以及時收集到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支持引入新的維度。
京公網安備 11010502049343號