【事件架构】CEP与ESP——一篇文章（或者一篇咆哮）

一位同事要求对“CEP”和“ESP”这两个术语发表一些意见，特别是为什么，如果客户已经拥有流式处理产品，他们可能仍然需要一些替代或非流式技术来完成某些其他事件处理任务…

1.业界对“CEP”和“ESP”这两个术语的共识越来越多。

“事件流处理”用于诸如市场数据流（通常是事件吞吐量与查询数的高比率）之类的事务，而“复杂事件处理”是一个超集术语，也涵盖了逐个事件的处理和聚合(例如。处理各种来源的潜在无序事件（通常具有大量规则或业务逻辑）。

资料来源：

• a. The EPTS Glossary by most of the CEP vendor community covers these terms. In particular it defines Event Stream Processing as the processing of in-order events.
• b. The “inventor” of the term CEP, David Luckham, provides an excellent differentiation on his web site.
• c. Analyst comments on this differentiation by Bloor .
• d. 3rd party blog comments by Opher Etzion , by Jack vanHoof , and by Tim Bass .

2.通常，“流处理” (ESP)将事件流处理为“集合”并执行“集合类型”操作，通常使用“连续查询”（随时间和缓冲区窗口操作的SQL类型查询）.更广泛的“复杂事件处理”(CEP)术语还包括其他机制，如ECA(Event Condition Action)规则、生产规则等。因此，根据定义，ESP产品也是CEP产品，就像Edsels和Bugattis都是汽车一样。

虽然流式查询引擎是非常有用的技术，但它们并不是所有CEP问题的最佳选择，特别是它们在比较无序或流外事件、将决策和反应应用于事件模式等方面具有不同的特征。因此，多个CEP语言类已经发展，通常被描述为查询、规则和过程方法（到事件模式检测）。这也是为什么TIBCO BusinessEvents显式支持状态模型和生产规则以及连续查询的原因，并且其架构允许将来根据需要添加其他事件处理语言。

Sources:

a. TIBCO Blog on Queries based on TIBCO’s coverage of ESP. Other ESP vendors are commented on in another post.

b. EPTS Language Working Group is defining some differentiations here but have not published their work yet: we blogged on a preview at a recent conference.

3.因为ESP只是CEP的一个专门的子集，有些人可能试图将“ESP”与“CEP”同义。这仍然是一个非常灰色的区域，因为使用查询的事件流处理是非常有用的功能（即事件集处理和检测），使用推理规则的逐个事件处理和关联也是如此。

因此…在大多数企业中，通常有多种CEP类型的多个用例，这些用例最好由多种范式处理（如专家ESP、事件驱动的业务流程、规则驱动的事件处理、基于事件的业务规则、事件驱动的分析等）。人们不应该再期望一家大公司像依赖于单一的计算机硬件技术一样依赖于单一的CEP模式。

原文：https://www.tibco.com/blog/2009/08/21/cep-versus-esp-an-essay-or-maybe-a-rant/

本文：http://jiagoushi.pro/node/985

讨论：请加入知识星球或者微信圈子【首席架构师圈】