基于事件驱动的分布式微服务架构

什么是事件？

广义上真实世界广泛存在各种各样的事件

有一定社会意义或影响的大事情

泛指一般的大事情;具体事务

事件（event）是由信息子排布引发的

狭义上特质计算机世界的事件

事件是可以被控件识别的操作，如按下确定按钮，选择某个单选按钮或者复选框。每一种控件有自己可以识别的事件，如窗体的加载、单击、双击等事件，编辑框（文本框）的文本改变事件，等等。

本文所谓的事件

计算机世界的事件都是操作级别的，例如各类窗体应用的各种用户操作都用事件形式反馈给控制层进行各种相应的处理，在比如在互联网圈，大名鼎鼎的redis和netty都是基于事件驱动的，这两者可是各自领域性能的代名词，由此可见事件驱动的一个好处就是性能担当，另外一个不言而喻的好处是事件驱动在持续事务管理过程中，进行决策的一种策略，即跟随当前时间点上出现的事件，调动可用资源，执行相关任务，使不断出现的问题得以解决，防止事务堆积，所以说事件驱动广泛存在于计算机世界！

本文所谓的事件也是狭义上特质计算机世界的事件，但是对事件进行业务化具象，是业务级别的事件例如订单已取消事件、商品已下架事件等等…

此类事件具有以下几个特征

• 关键性(对整个业务流程具有比较重大的影响)
• 唯一性(不能具有二义性)
• 客观事实性(绝对表达事实不能模棱两可)
• 事件由事件主体+事件标识+事件顺序号组成；事件主体就是业务的唯一编码例如订单号商品编码等；事件标识标则标识了是什么事件；是订单已支付还是订单已取消？除此之外无其他任何额外信息，说白了事件仅表明：谁(事件主体)发生了什么(事件标识)再带一个此次事件的唯一标志。唯一标志通常是顺序号，此顺序号可以识别出到底是事件源发出了多次相同的事件(事件主体和事件标识唯一代表一个事件)，还是一个事件被重复投递了，对此事件的消费方可以做出不同的响应。

基于事件驱动的微服务架构有哪些好处？

• 首先事件作为一种实时异步的消息通知自然带来的好处就是微服务间绝对解耦，每个微服务只需处理自己的业务并把一些关键事件发出去即可，而不用关心该调用其他微服务的哪些接口来改变对方的状态。
• 每个微服务订阅自己关注的事件并且在收到相应的事件后，能够根据事件的真实业务含义做出相应的响应通常是自我更新。如果除事件本身的信息量外还需要其他的非本微服务能够提供的信息，则可以通过事件主体反查其他微服务获取足够的资源(restful)最终实现自我更新。
• 每个微服务就都不提供引起自身状态改变的接口(也就是更新接口)，只提供查询接口提供各种各样的资源给其他微服务,完美的restful思维——无状态。
• 每个微服务都是无状态的自我更新的，那么几乎等同于此种微服务架构是天然没有分布式事物问题的。

基于事件驱动的微服务架构什么样？

前言：本文样例所谓的微服务特指基于springCloud的微服务架构

如图，事件驱动分为客户端的starter和服务端的中间件两部分组成，starter提供收发事件的sdk和一些收发的配置，例如声明发什么事件，声明关注的事件列表，服务端事件中间件负责做事件的转述与投递记录，隔离收发的不同微服务避免直连。并且可以根据微服务的配置元信息绘制出全局的事件收发图谱。