EDA和SOA的融合以及实践

从上面的定义可以看出，ESB 更多地关注应用流程方面的信息，将业务流程剥离出来并将其交由 ESB 来统一管理。因此，有一个非常简单的标准来判断是否需要采用企业服务总线：就是看你的应用本身是否有很复杂的业务流程，而且可能这些流程会经常发生变化。依据这条标准，我觉得很多应用一开始都没有复杂到需要立即采用企业服务总线，比如说一个股票的后台管理系统，其业务流程相对来说比较简单固定，就没有必要引入企业服务总线这样重量级的解决方案。

当然，ESB 中分解流程信息的思想我们还是可以借鉴的，只不过我们可以用更简单的方法来实现。

EDA 的实现途径

在 EDA 中，按照事件简易程度的不同，事件处理模型可以分为以下三种：

简单事件处理 （Simple Event Processing）

流事件处理 （Stream Event Processing）

复杂事件处理 （Complex Event Processing， CEP）

在一个成熟的事件驱动架构中，这三种往往会混合在一起使用。目前，很多公司都推出了支持 CEP 功能的产品。但是在实际应用过程中，我们还是需要秉承由简入繁的原则。能用简单的事件处理解决问题，就没必要使用复杂的。

实现事件驱动架构最简单、直观的方式就是使用消息。在 JMS 的体系架构里，我们很容易来实现事件驱动的一些基础元素：事件的生产者、消费者和通道。下图为在发布 / 订阅模式下，消息发布者、订阅者以及消息通道和主题之间的交互。

图 2. 一个发布者、多个订阅者、事件通道和主题之间的交互

严格意义上来说，事件和消息是不同的概念。消息代表非直接交互时简短的信息，而事件往往代表状态的显著变化。可以把事件看作消息的子类，因为后者还包括包含数据的消息等。而且，在实际应用中，一个消息中往往同时包含事件和数据的内容。比如系统接收客户的订单后，它会发布一条消息：其中既包括事件（新增客户订单），又包括新订单的具体数据。

基础组件

在确定了系统的架构后，我们需要着手来实现它。经过这么多年的实践，人们也总结出一些基础的组件，这些组件对于事件驱动的面向服务架构来说是必不可少的，或者说经常被使用到的。

Web 服务基础架构 （XML，SOAP，WSDL，UDDI 和 Quality of services）

企业服务总线（针对复杂应用）

消息中间件

监控体系

异常处理的讨论

配置和规则引擎

其中第一、二项大家讨论得最多，第三项也经常被提及。作为消息运转的基础，消息中间件（Message-Oriented_middleware，MOM）必须做到安全、可靠和快捷。市面上有很多很成熟的产品，比如 WebSphere MQ，Apache ActiveMQ 等。而且还有些针对特定行业的特色化产品，比如 WebSphere MQ Low Latency Messaging 是一款专门针对金融行业的中间件，用来满足高吞吐量、低延迟的业务需求。

结束语

采用某个概念非常简单，我们实际需要的是如何结合自身项目的实际需求，真正地利用这些概念背后那些好的思想。利用这些智慧结晶来解决面临的问题，这就需要大家多从实际出发来思考问题。很多时候，过多的概念只会让你更加混淆，我们真正需要记住的不是这些名词，而是这些名词背后的思想——这些在软件架构中一直被传承的东西。