复杂事件处理过去是否适合 SOA，现在是否适合云？

2002 年， David Luckham 引入"复杂事件处理（Complex Event Processing，简称 CEP）”一词。几年后，在关于 CEP 历史的论文中，Luckham 指出：几十年来，尽管事件处理已经是分布式系统和模拟的核心，CEP 仍在演化，随着上下文不断变化，它没有停滞不前。实际上，CEP 最好的概括是：

复杂事件处理技术针对真实世界的事件数据，进行低延时的过滤、关联、聚合和计算。

这些年来，CEP 在 SOA 的上下文中被讨论，认为它天性符合 SOA，而且多次被成为"计算领域的新物理学”，或是像 2008 年 WebSphere CTO Jerry Cuomo 说到的"明日之星”：

我开始听到有人在 SOA 的上下文中谈论 CEP，而且我坚信它是 SOA 的明日之星，也就是事件处理。我不知道你们听到多少，但是毫无疑问，我们对它非常严肃。我看到事件处理的光谱。有多种类型的事件处理，从其字面意义上说，在这方面我们做得都还不错。

一直有一些公司在提供和研发 CEP 产品，或是开源项目，比如 Esper 、 Drools Fusion 和 Sybase 。同时，我们看到人们在谈论是事件驱动架构（Event Driven Architectures，EDA）和事件流处理（Event Stream Processing，ESP），构建于事件和CEP 理念之上。像Gartner 和Oracle 甚至建议CEP 和SOA 的组合将会是下一代SOA 的发端，比如 SOA 2.0 ，不过在业界更大范围内，它发展得不太好。然而，正如 Eric Roch 最近指出的，CEP 这个词让其背后的理念很难得到认可：

CEP 这个词和其复杂性的理念被一些使用案例不断恶化，这些案例常常和技术相关。最常被提到的案例是交易算法。你去跟你的 CEO 说希望尝试 CEP，因为这是很棒的技术，华尔街也用它来做交易算法，这样的事情你能想象么？运气好，可能给你来一句："咱们的业务里面用这个有啥用啊？”或者就是一个恼火、轻蔑的眼神。

Eric 同意 Luckham 最初的分析：就像面向消息的中间件或者规则引擎什么的，在 CEP 背后没有多少新鲜东西。即使如此，还是有太多复杂的词汇，难以服众：

但是，当你抛出一大堆热门词汇——复杂事件、事件通道、推论引擎、Rete 网络、转发组链、状态机、组元、交易算法，听起来确实需要一个博士才能把这件事玩儿起来。

幸运的是，过去十年中，相关实现已经有不少改进，而且工具现在成为了重要组件：

CEP 工具，特别是最成熟的那些，是模型驱动的，很容易使用。你不需要知道推论引擎的内部，就可以写出业务规则。实际上，它们比写一大堆嵌套的 if 语句要更为容易。

不过，过去几年里面，对 CEP 的讨论和各种宣传已经减少了。这可能是由于对 SOA 宣传的减少。也可能因为 CEP 没有实现最初的承诺。或者更可能的是：就是像 Luckham 指出的，多年来，事件已经成为软件系统的一部分，CEP 现在是 SOA 实现核心的自然构成，人们觉得理所当然。

不错，随着云的广泛应用，还有利用现有软件投资的推动力，我们看到有一些讨论，建议将SOA 迁入云中，当然也包括与SOA 相关的所有东西，比如CEP。然而，看起来这也许不会像 Colin Clark 去年指出的那么容易：

也许因为目前的 CEP 产品不太适合网格式部署。目前没有产品提供消息总线或是缓存，这是网格部署的必要部件。很多人觉得 "我不关心消息来自哪里，也不关心它们去向何方”， 对于这样的人来说，因为缺乏上述关键组件，相关产品很可能没有进入架构的机会。这样的人越来越多，这样的世界越来越大，这样的世界已经准备好进入云计算的世界。

正如另一篇文章提到的，也许 CEP 背后的某些本质假设，比如低延时，或是当前实现的"复杂性”，阻碍了在云中使用 CEP。又或者 CEP 将会成为云的关键，正像它过去 50 年成为分布式系统的关键那样？InfoQ 的读者们，你们的 SOA 应用里面用到 CEP 了吗？它是不是你们 SOA 基础设施的核心部分？你们是否考虑在云中使用它？如果是的话，现有的实现是否符合你们的需求？还是我们需要更具备云特性的 CEP？

查看英文原文： InfoQ: Did CEP deliver for SOA and can it for Cloud?