SOA, EDA, 和 ESB

SOA----面向服务架构，实际上强调的是软件的一种架构，一种支撑软件运行的相对稳定的结构，表面含义如此，其实SOA是一种通过服务整合来解决系统集成的一种思想。不是具体的技术，本质上是一种策略、思想。

ESB----企业服务总线，像一根“聪明”的管道，用来连接各个“愚笨”的节点。为了集成不同系统，不同协议的服务，ESB做了消息的转换解释与路由等工作，让不同的服务互联互通。

SOA主要是基于request、response的消息通讯机制的。它的设计适合同步通讯，但是并不大适合异步的通信。 所以我们还需要EDA。

EDA使用的是publsih/subscibe的消息通讯模式，它适合异步的消息发布和消息订阅。它与SOA注重的是不同的方面。所以SOA和EDA是互补的关系。而不是取代的关系。
那么对于一个企业，它同时需要SOA的同步机制，也需要EDA的异步机制，应该如何做呢？ 
这个时候我们就需要ESB了。
ESB是enterprise service bus，它通过服务总线的方式来提供上面说的SOA和EDA的同步和异步的功能。

ESB可以完成一些事情定义好的消息格式转换，消息protocol的转换等等。 
可以看为一个比较智能的总线，它专注于企业内部不同的应用程序的通讯。能把使用不同protocol和不同data 
format进行自动转换。它能提供request/response的同步消息通信机制，也能够提供publish/subscribe的异步消息通讯
模式。

一个事件驱动系统典型地由事件消费者和事件产生者组成。事件消费者向事件管理器订阅事件，事件产生者向事件管理器发布事件。当事件管理器从事件产生者那接收到一个事件时，事件管理把这个事件转送给相应的事件消费者。EDA事件驱动架构具有如下特点:

• 并发执行
• 事件触发/数据触发/时间规则触发
• 实时/增量响应
• 分布式事件系统处理

这里首先可以看到EDA的重点是事件驱动，是实时/增量的响应。而对于SOA本身服务的同步机制就可以实现服务的实时响应，为何还要引入EDA事件驱动架构的概念？这是必须要搞清楚的问题。对于SOA中的同步服务一般是关于到两个系统间，即A->ESB->B；但是很多时候实际的业务场景比这个复杂，即到达B还没有结束，B还需要去分发和通知消息和数据。即A->ESB->B->ESB->(C,D,E,F)，在这种业务场景下如果简单的谈SOA的同步服务是无法解决该问题的。

因此EDA的实际应用场景是源系统->事件产生者->事件消费者，三者之间可能是多对1，然后1对多的机制。而对于1对多的处理正好和我们说的发布/订阅模式是类似的。即EDA仍然是一种异步模式，但是却可以实现实时响应和并发执行，这就是EDA最大的一个特点。

这里先再举一个了发布订阅的例子：

张三开了一个书报亭，卖《时事快递》这个杂志，这个杂志不是定期发行而是根据实际的时事和焦点发行。现在甲，乙，丙三人都喜欢看这个月刊，原来的方式可能是隔断时间(定期轮询机制)就去报刊亭看下，看是否有最新的杂志可以购买，所以很多时候都空跑。

而新的方式是三人都给张三留下联系地址，告诉老板只有有新的杂志你就安排人给我送过来(订阅)，三人唯一要求就是要第一时间获取到该杂志，否则过期杂志无意义(实时性要求)。这个时候张三还得跟杂志社谈，他告诉杂志社出新期刊后一定要第一时间送到报刊亭(杂志社自己来说是很清楚是否产生了新期刊的)。

订阅过程完成后，杂志社将最新期刊送到报刊亭后返回(短周期事务，送到报刊亭事务结束)。报刊亭一看有三个人订阅了这个期刊(MQ消息队列)，然后安排一个人逐个开始送期刊给甲，乙，丙三个人。这个时候三人收到期刊的时间有差异，但是基本可以保证期刊的实时性。或者老板安排了三个人同时送货(并行执行)，保证三个人更快的收到杂志。

在送货的过程中，可能乙没有在家，这个时候报刊亭要暂时代存这本杂志，然后第二天接着送。(存储功能和异常重试功能)。杂志社只管送到报刊亭，而能否送到最终用户手里面是报刊亭的责任。

通过上面的例子，可以看到不同的场景和角色如下：

• 杂志社：产生数据源的系统，往往是业务处理系统，如采购管理系统，合同管理系统。
• 报刊亭：ESB总线，必须具备消息队列和临时性的数据存储，以支持逐个处理事件和支持重试。
• 甲乙丙：事件的消费者。首先是订阅事件，然后等待新事件推送给自己。

上面这个例子是我们常见的EDA的实现机制，即通过Pub/Sub实现增量和实时的响应。在这个例子里面可以看到ESB必须要有消息队列，支持数据的临时存储。对于订阅信息也需要在ESB上面存储，而不应该放在源系统和目标系统。通过这种方式可以看到，源系统将新增数据推送到ESB即返回，不用等待 ESB事件发布完，因此大大缩短了事务周期，实现较好的解耦。通过ESB本身有消息队列，支持异常下的重试，保证不会丢失数据。

从这个例子可以看到SOA服务和EDA的集成，对于订阅可以直接封装为服务，通过调研服务进行订阅。为了保证订阅数据能够进入目标系统，目标系统还需要做数据的导入服务，由ESB调用导入服务完成数据的推送。ESB本身也需要一个导入服务，保证源系统的数据能够导入到ESB总线做临时存储。

通过上面的分析，我们再来理解下CEP复杂事件处理。

还是按上面的例子，甲乙丙希望他们的杂志报刊亭能够进行不同风格包装后再送，或者各人还需要搭配其它东西一起送(业务规则)。在这个基础上即转变到CEP。因此对于CEP的技术理解可以是EDA+规则引擎，即CEP完成三个重要的动作，首先是接收事件和实时检测变化(多种方式，可以被动也可以主动监听)，然后是通过业务规则引擎对事件涉及的数据进行处理，最后是发布事件和处理的结果给消费者。

从这里可以看到业务规则和约束模型是CEP解决方案的核心，TIBCO BusinessEvents 采用类似于 Rapide 事件语言的模式。Rapide 语言是一种采用“事件-条件-行为”(ECA) 形式的、功能全面的事件和规则语言。ECA 规则是独立的单元，它由引擎根据状态变化进行正向推理