EDA事件驱动架构

      事件驱动架构应该说是一种非常流行的分布式架构模式,他的经常会被用在构建一个可伸缩性的应用上,当然小型系统也同样适用。
     

        Node用来表示一个节点,每个节点负责处理业务逻辑,Event表示这个节点处理完后产生的消息,通过通过消息中间件传递给另外一个Node。他不同于传统的SOA架构,rpc调用的方式,他是一个pub-sub的模式,节点与节点间不需要知道对方的存在,每个节点只关心自己要处理的消息,这个从耦合性上来说对比RPC调用是否非常低的,节点和节点之间不存在任何的依赖,通过mq进行消息的中转。这样设计有哪些好处呢?大家有没考虑过。
       

       举一个例子来说,之前我们项目做的一个送货机器人他的业务流程是-用户下单-》通知机器人前往货柜取货-》货柜放货-》取货完成,通知机器人送货-》下发验证码给用户-》通知用户取货-》取货完成,通知机器人前往充电。最早版本机器人、货柜、订单调度系统直接走的是tcp私有协议RPC调用,整个业务流程消息未走MQ,直接通过RPC调用的方式进行交互。不知道大家有没想过这里面隐藏着很多的问题我们没有去处理,我们是不同的系统走的TCP模式,在网络情况不稳定的时候,经常断线,业务发起方经常要负责业务重试,由于没有MQ,需要去编码消息存储,消息重试这一块的业务逻辑,工作量非常的大,效果还不好 。后边我们采取了EDA这种设计模式,在RPC后加入了MQ的形式一下就解决了这个头疼的问题。主要采取了以下的策略:1.消息的发送者在没有收到对方的ACK时会不断的重试,直到对方返回ACK结束。2.消息接收者在收到消息时,建消息存入MQ,成功后返回ACK给消息发送者。3.消息接收者从MQ消费消息,进行业务处理,产生新的消息通过TCP rpc调用消息处理者,如果出错,不断重试,直到消费者返回ACK后,对MQ的消息进行ACK,业务幂等处理。 这以上3点就是我在送货机器人订单调度模型的核心原则。

总结以上:

1.他保证了最终一致性(消息链路断开,不断重试),MQ保证消息不丢失。
2.每一个Node节点都必须保证自己完成后才发送ACK给MQ 
3.Node处理的消息都能够保证幂等性。
仔细思考,你会发现他其实就是EDA事件驱动的架构模式。整个架构具有MQ带来的所有优点:异步解耦、削峰、降低业务复杂度

你可能感兴趣的:(架构设计)