复杂事件处理过去是否适合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?