SOA, EDA, 和 ESB的介绍和关系

  |   0 评论   |   958 浏览

    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 规则是独立的单元,它由引擎根据状态变化进行正向推理。

    评论

    发表评论

    validate