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带来的所有优点：异步解耦、削峰、降低业务复杂度