Event-Driven Architecture 事件驱动架构 2

接上篇 Event-Driven Architecture 事件驱动架构 1
上篇较为笼统地介绍了EDA的基本内容,以下会结合例子进行说明。

事件(Event)分成两部分:
– 事件头部:包含事件名称、时间戳、类型等基础信息。
– 事件主体:状态改变的细节。原则上数据直观,包括命名、描述方式,都应该一目了然。

再说说EDA架构的组成的三要素
– Emitter (发射器):负责事件的探测、收集与发送。
– Consumer(消费者):负责响应事件,一旦事件发出,即做出反应。
– Channel (通道):保证事件消息的传输。

以下通过简单的JS程序进行举例

class EventEmitter {
    constructor() {
      this.events = new Map();
    }

    on(event, listener) {
      if (typeof listener !== 'function') {
        throw new TypeError('The listener must be a function');
      }
      let listeners = this.events.get(event);
      if (!listeners) {
        listeners = new Set();
        this.events.set(event, listeners);
      }
      listeners.add(listener);
      return this;
    }

    off(event, listener) {
      if (!arguments.length) {
        this.events.clear();
      } else if (arguments.length === 1) {
        this.events.delete(event);
      } else {
        const listeners = this.events.get(event);
        if (listeners) {
          listeners.delete(listener);
        }
      }
      return this;
    }

    emit(event, ...args) {
      const listeners = this.events.get(event);
      if (listeners) {
        for (let listener of listeners) {
          listener.apply(this, args);
        }
      }
      return this;
    }
}

const events = new EventEmitter();
events.on('foo', () => { console.log('foo'); });
events.emit('foo'); // 控制台输出 "foo"
events.off('foo');
events.emit('foo'); // 没有任何响应

这个Demo中,定义了 EventEmitter 事件基类以及简单的业务实现。
从中可以得到两个结论:
1、当events.off()执行之后,events.emit(‘foo’)依然可以发生,程序也没有出错。
所以,事件发射器并不需要知道事件的消费者是谁。
2、当events.on()中定义了事件消费者,当消费者可以是某个函数,也可以调用其他函数,亦或者触发新的事件。
所以,EDA提供了一种非常松耦合的架构方式。

接着,通过业务模型来探究一下EDA的优越性。

W2A-DataDriven
W2A-DataDriven

有个系统现被称作W2A。
具体的业务逻辑如下:
Web端向服务器发送数据,由服务器端存储数据。
APP端向服务器端发起查询,如果有符合条件的数据,需要在该结果数据上做标记,并给APP返回结果。
实际操作中,服务器端每天会产生超500万条数据。而查询也将在近7天的数据中进行检索。实际上每次检索的数据量在5千万条。
在原始的方案设计中,Web端向服务器发起查询请求,而APP端发起查询请求,会立刻返回结果。
很显然,每次发起查询会产生极大的浪费,并且APP在查询过程中,一直处在等待结果的状态。
根据需求,我们需要做两件事:
1、在查询结果上做标记
2、给APP返回结果

这里稍微有一些考量,APP是否立即需要得到返回结果呢?
通过与产品狗的撕逼以及跟老板的博弈,这个返回结果可以有所延迟。

那么这个系统可以这样设计(此处用报告老板里的语气):
根据第二张图,APP发起查询后,查询请求即可完成,但没有立即返回APP想要的结果。
此时服务器端需要做三件事:
1、异步地查询(一段时间内的检索资源消耗)
2、在服务器端对结果进行标记
3、发送一个事件消息,通知APP已经有了结果。

这样,当APP接收事件通知时,再进行相关的业务逻辑。

以上,是一些实践过程,无论是针对程序还是系统,EDA架构设计模式的优势都是显而易见的。
因此传统的SOA架构也升级成为 SOA2.0(ED-SOA)。

发表评论

电子邮件地址不会被公开。 必填项已用*标注