关于事件驱动架构的思考
一、事件驱动
基于事件驱动架构的意义在于隔离各业务系统，并能够聚合分析各不同业务域的业务状态变更，进而根据业务状态决策下一步业务动作。事件处理系统承载了一部分根据业务状态决策业务动作的逻辑，这部分逻辑可以不归属于任何一个业务系统，但能驱动业务系统的各种服务、流程的调用和执行。
事件类型
简单事件
单个事件即能表达一种业务状态，足够触发业务决策。
复杂事件
由多个事件（相同或不同）聚合而成，具备一定的窗口属性，如时间、长度。
事件和消息的区别
事件本身即是具有特定业务含义的一种固定结构对象，而消息是数据传输过程中的载体。概念上宽泛来讲，事件可以称作是一种消息，而消息不能代替事件。事件反映的是特定的业务状态，比如订单创建、服务调用失败、应用宕机等。
一个事件对象描述的是谁在什么时间做了什么事情，看到这个对象，我们就能知道是发生了什么特定的事情。但是事件对象本身不承载数据传递的职能。
消息中间件实现的是消息的存储，解决的是解耦上下游业务系统。事件处理系统是更多的侧重对事件的分析处理，并驱动业务的进一步扭转。
二、基础模型
观察其他的基于事件驱动机制的系统或语言，比如node.js、nio等，不难发现其最终的基础模式就是观察者模式，只是不同的应用场景，也会有各自不同的侧重。
在需要结合复合事件综合分析的场景下，会牵涉到事件的存储、窗口、筛选规则等等，于是对应产生对事件存储能力、生命周期管理、规则解析能力的要求等等，而这部分需求也只是在基础模型上添砖加瓦做能力增强，其核心的基础模型还是保持不变。
三、实现方案
除了商用软件如Oracle CEP、IBM ODM外，基于开源产品包装，或者基于DB自建都能实现。为什么要基于DB自建，而不是一些缓存产品，主要还是考虑到DB天生支持对数据的各种复杂筛选能力，这一点是KV缓存很难做到的。当然基于DB的弊端即在于性能，在事件数量较少的情况下，用DB也是能够解决问题的，但是数据量增加，就很容易悲剧了。开源产品主要是esper和drools两款供君选择。
esper
基于Java的比较轻量级的实现方案，一个jar包就能行走天下。支持类SQL的EPL事件规则语言，时间窗口、长度窗口均能支持。事件数据存储在JVM中，进程宕机即导致数据全部丢失，且开源版本不支持HA。不过官方性能报告单机50W/s，已经足够应对很多场景了。
drools
曾经对drools做过了解，应该说drools更多还是一套规则引擎的产品，事件的创建是依附于规则的。规则执行过程中才会产生事件，这个跟通常的事件驱动架构略有区别。drools的一个主要优点在于规则引擎本身对规则语义化配置的要求较高，dsl已经可以定义关键字词汇，使得规则因子的提取、语义化等工作可能比较容易实现。
四、几个原则
事件对象携带尽可能少的数据。
事件对象表达的是某业务实体在什么时间发生了什么事情。在系统运行期间只是作为一个业务状态变更的一个信号，是一个业务状态的标志，所以事件对象本身不应携带过多的数据。同时，事件对象体积的控制也更利于内存回收。
解耦，解耦，解耦。（重三）
事件采集与采集端的解耦、运算规则与业务系统的解耦、规则指令与业务接口的解耦。事件处理系统本身相对独立，其核心业务逻辑在于事件筛选的规则，规则在运算期间不依赖业务系统，可以支撑更高的性能。规则触发后的决策指令同样可以基于异步策略调用业务服务接口，降低事件处理系统量级。
--未完待续--