Event-Driven Architecture 事件驱动架构 1

这是第一篇架构学习的日志。
说说我对架构学习的源动力,是在设计某种业务功能的技术方案过程中,发现所设计的系统及其子系统,存在着数据的外部输入输出,而在数据的流转是同步的。这样的设计是否正确?是否有优化空间?很难快速(考虑成本)从现实中找到依据,即使找到也可能是人云亦云。带着困惑,一瞬间我抬头望向天空,找寻那一盏明灯,于是我就想到了事件驱动。

以下是对参考资料的翻译以及结合实践的客观描述。

概念

EDA(Event-Driven Architecture)是软件架构模式的一种。
这里的“事件”被当做是一种状态的变化。既可以理解为软件系统状态,也可以理解为业务状态。

比如,我在一家饱满的餐厅前排队取票,当叫到我的号时,已知晓此时我可以进入餐厅就餐。这个过程中,可以抽象地认为排队的号码牌由Padding(排队中)的状态变更为Available(当前可用)。

那么是什么改变这个状态的呢?就是由叫号的人或机器,在那一刻喊出了我持有的号码。就像发起了一个通知消息。这个消息本身没有能力直接改变号码牌的状态,而是由人(我)或者设备主动将这个状态进行变更。

架构层次

  1. Event Generator:
    就是产生Event的终端或者sensor。将所要表述的信息封装成一个Event,并具有较好的可读性。
  2. Event Channel:
    主要就是event的传输机制。可能是TCP/IP,或者是XML格式等等。一般来说,事件处理引擎实时处理事件,事件通道的读取是异步的,事件都将被放在队列中,等待被处理。
  3. Event Processing Engine:
    用来辨识Event,并采取合理的Reaction。
  4. Downstream Event-driven Activity :
    很多时候,Engine只是触发合理的Reaction,而真正的动作是在这里完成的。所以,这一步并不是必须的。

在以上举例中,我与机器都对号码牌采用了某个action,就相当于事件处理引擎。

事件处理风格 (你有freestyle吗?)

答案是没有。只有三种:

Simple event processing:

简单事件处理就是一种最直接的处理方式。比如温度的改变连续触发状态的改变。

Event stream processing:

Event generator产生持续的Event,这些Event既有notable(重要的),但更多的是ordinary(一般的),这就需要事件处理引擎能够对event进行过滤和识别。

Complex event processing:

对于复杂event的处理架构,存在着大量的simple event,这些event之间有着各种联系。CEP系统要求能够发现这些联系,从simple events中提取出复杂的event。

通常,在EDA的架构中,这三种处理方式都会用到。

优点

1、分布式的异步架构,事件处理器之间高度解耦,软件的扩展性好
2、适用性广,各种类型的项目都可以用
3、性能较好,因为事件的异步本质,软件不易产生堵塞
4、事件处理器可以独立地加载和卸载,容易部署

缺点

1、涉及异步编程(要考虑远程通信、失去响应等情况),开发相对复杂
2、难以支持原子操作(*),因为事件通过会涉及多个处理器,很难回滚
3、分布式和异步特性导致这个架构较难测试

注解:
(*)原子操作:指不会被线程调度机制打断的操作,可以理解为操作一旦开始,就一直运行到结束,不会被打断。

参考
wikipedia – Event-driven architecture

下期:Event-Driven Architecture 事件驱动架构 2

发表评论

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