事件驱动架构及实现

三斤牛仔

已于 2022-12-19 11:23:42 修改

阅读量2.5k

点赞数 3

分类专栏：传统企业数字化转型及落地文章标签：架构 java 开发语言

于 2022-12-15 15:14:40 首次发布

本文链接：https://blog.csdn.net/tonydark01/article/details/128330345

版权

传统企业数字化转型及落地专栏收录该内容

2 篇文章 0 订阅

订阅专栏

什么是事件驱动架构

事件驱动架构（Event Driven Architecture，EDA）一个事件驱动框架（EDA）定义了一个设计和实现一个应用系统的方法学，在这个系统里事件可传输于松散耦合的组件和服务之间。一个事件驱动系统典型地由事件消费者和事件产生者组成。事件消费者向事件管理器订阅事件，事件产生者向事件管理器发布事件。当事件管理器从事件产生者那接收到一个事件时，事件管理把这个事件转送给相应的事件消费者。如果这个事件消费者是不可用的，事件管理者将保留这个事件，一段间隔之后再次转送该事件消费者。这种事件传送方法在基于消息的系统里就是:储存（store）和转送（forward）。

什么是事件

事件表示含有业务语义的消息，对消息体大小，消息格式有严格的限制。

什么是生产者

生产者表示事件的发布方，将事件投递到事件中心。

生产者需要明确事件的定义，格式。

什么是消费者

消费者表示事件的消费方，接收事件并完成相应的业务动作响应。

传统的请求/响应式微服务架构

传统的请求/响应式架构，服务间需要通过API二方包来完成服务的发起和调用，比如我们常见的dubbo，或者springcloud中的feign。二方包的依赖导致服务间强耦合。

举一个常见场景：

交易成功后发货

随着业务发展业务人员提个需求，希望增加积分系统，交易成功后给用户增加积分

存在问题：

每次下游新增业务，都会导致上游系统变动。
由于是下游系统提供的接口，上游系统必须感知下游的数据协议。比如积分系统提供的API，里面可能涉及到其他系统字段，这时交易系统由于缺少这部分字段，必须再去其他系统中获取然后组装成积分系统的数据协议。

依赖倒置，上游系统依赖了下游系统的API。

基于消息的架构

因为不确定下游需要的数据协议，所以一般会在消息中带id信息，然后下游根据需求反查。

解决问题：

部分解耦上下游系统，但是由于消息协议不明确，下游系统还是要依赖上游的查询接口才能获得数据。
解决依赖倒置，上游系统不再依赖下游系统的API。
由上游统一数据协议。

存在问题：

当业务量/并发量大时，极大增加上游系统压力
通常为了保证最终一致，消费方会将消息保存下来再处理业务逻辑，通过补偿机制处理失败的消息，重复设计导致业务系统中侵入大量非业务代码。

事件驱动架构

解决问题：

解决统一处理消费异常等问题
完全解耦上下游
定义标准事件协议，系统内按照协议契约执行，避免扯皮

存在问题：

我们说的事件，本质上还是基于消息中间件(MQ)，所以在严格事务要求的场景下，不能完美的解决，当然有一些事务消息的解决方案，但并不是通用方式。
虽然大部分的MQ支持ACK，有精准一次，最多一次，至少一次功能，但是从性能和功能综合考虑，还是建议消费者端增加幂等逻辑处理。

为什么传统企业数字化更需要事件驱动

传统企业数字化业务流程更复杂

通过事件驱动能更好的解耦各服务间关系。

拿出差这一个简单场景来说，出差审核通过后就需要订机票，订酒店；然后自动财务结账核算；然后OA考勤自动打卡“出差”等等。当有新的下游需要接入时，只需要接对应的事件即可，且事件是约定标准的，也不需要上游的任何改动。

传统企业数字化未知场景更多

相较于消费互联网的已经被“玩烂”，产业互联网还是一块未开垦的处女地。我们说的一些系统（OA，SAP等）都是传统信息化遗留下来的产物，但真正深入每个行业，每个领域，未知的变化层出不穷。笔者就曾经碰到过需求一天一小改，3天一大改的场景。但是需求在变，其业务的本质或者说核心流程并没有变。事件驱动能很好的解耦变与不变，让开发人员将精力更多投入到变化中。