事件驱动架构的优势

每天产生的数据正在呈现指数级的增长，不管这些数据是由各种传感器产生还是有用户点击网络产生，亦或是系统内容交互的数据，我们的应用需要处理和这些数据相关的事件将会越来越多。那么怎样设计一个很好的架构来处理这些事件呢？

本文，我们将会讨论什么是事件驱动的架构（EDA）以及这个架构是这样把事件放到系统的核心地位的。然后我们再聊聊这样的架构都有哪些优势。

什么是事件

所谓的事件，就是记录已经发生的事情，或者一个状态的改变。他们是不可改变的，并且是按照发生的顺序排列的。对这些事件感兴趣的部分可以注册这个事件，然后再根据这些事件来做相应的商业逻辑。

什么是事件驱动的架构

所谓事件驱动架构他是一个松耦合的系统，通过产生事件和抓取事件来交换信息。一个事件驱动的系统会把产生的事件广播出去，然后感兴趣的部分再抓取这个事件。

我们来看一个例子，下面这个图显示了一个打的的场景。这个图中，该场景有三个微服务：一个UI服务，主要是让用户可以订一个的士，一个fleet服务把相应的订单给到taxi，一个taxi汽车服务，用来收集taxi相关的信息，比如当前的位置等等。处于核心部分的圆柱体是用来连接各个服务的，它就是事件驱动的核心。图中的箭头就显示了事件流通的方向。各个事件的具体解释如下：

• 用户通过UI下了一个订单。UI会收集一些用户的信息，比如当前的位置，名字等等
• Taxi Fleet service订阅了taxi订单的信息
• Taxi Car Service收集每一个taxi的信息，比如taxi当前的位置，并且发送send current location 事件。
• Taxi Fleet Service同样订阅了send current location事件，然后他就可以根据taxi的位置和用户的位置来分配最近taxi给用户，并且发送allocate nearest taxi事件。
• Taxi Car Service会订阅allocate nearest taxi事件，这样他就会通知taxi司机去接相应的客户
• Taxi Fleet Service还可以实时监测taxi的位置，并且给用户实时更新当前taxi的位置。

一个事件驱动的架构需要一个信息传递的主干，可以把信息在产生者和订阅者之间进行传递。这个主干有很多的实现方式，比如传统的publish-subscribe（比如IBM MQ)，也可以是分布式的log（比如Apach Kafka）。前者允许很多人来订阅信息，信息会在所有的订阅者都接收到之后删除。而后者，理论上所有的事件都是可以重放的。这也就意味着，一个新的订阅者甚至可以选择从头开始接收所有的事件。

究竟该选择哪个事件的系统，这取决于具体的使用场景。主要是看需不需要永久保存，事件频率，事件大小或者时间产生者等等各种因素。

使用事件驱动架构的优势

现在流行的应用都支持事件驱动架构，为什么呢？这样做有什么好处？

事件驱动是一个架构，任何语言，任何系统都是可以使用这种架构形式的。下面我们来看看这种架构有什么好处？

真实地把生产者和消费者分开

事件驱动架构把系统中各种功能模块分开，这样消费者和生产者之间的逻辑就彻底分离了。

• 生产者不需要关心他们的信息是被哪个消费者怎样消耗的。
• 消费者不需要关心事件究竟是怎么产生的

正是因为这样的分开，微服务可以通过不同的语言或者使用不同的技术来实现各种特定的任务。因此，事件编码的方式也是没有关系的–可以是JSON,XML，Avro等等。

各个模块之间分割开来，也使得他们可以更好地进行扩展。开发者可以增加或者移除事件的产生者或者消费者，而不需要修改别的微服务的任何逻辑。

生产者完全不需要关心谁使用了他们的事件，同样的，对消费者来说，他只要订阅相关的事件就可以了。

比如在上面的例子中，我们可以很方便的加入一个Taxi Finance Service，订阅Taxi Car Service的事件，并收集相关的数据，比如油耗等等。有了这个新加入的服务，Taxi Car Service就可以做一些建议或者计算驾驶的效率，并发送相关的事件，Taxi Fleet Service就可以订阅这个事件，然后把它作为一个因素加入到分配订单中。

弹性（Resiliency）

各个模块之间的松耦合，意味着在事件驱动架构中，一个服务不需要担心另外服务的状态和健康状况。这样，即使一个服务挂了，另外的服务也可以按照他们的定义继续运行。因为相关的事件是存储在事件骨干中的，所以只要挂了的服务稍候恢复了，还可以继续从中取出相应的信息，并继续运行。

尽管这个弹性的优势并不是事件驱动架构中特有的，但事件如何到达的确提供了额外的优势。事件都是异步的，也就意味着当事件发生的时候，就会被发布。消费者可以随时使用这些事件。所以，当一个服务有问题，他们可以从有问题的地方继续，而事件产生者则完全不需要关心这些，他只要继续产生事件就可以了。这就和REST的架构很不一样，在REST中是同步的，也就要求另外的消费者必须是运行着的，产生者也需要实现各种retry的逻辑来防止各种意外的失败。

举个例子，事件驱动可以用在当你有一些设备经常出问题的场景，当它们回来的时候，可以继续执行相关的事件。比如在智能运输集装箱系统中，所谓的智能运输集装箱就是收集和分析相关的数据，然后没隔固定的时间把这些数据发送会中心系统。但是在船运系统中，网络可能很不稳定，经常会掉线，这样在你上岸后，有了网络之后，他们仍然可以把这些数据发送回来。同样的，假如中心有什么信息需要发送给这些系统，他们在网络稳定之后，他们就可以接受到这些信息了。

基于推送的信息传递

在基于请求的消息系统中，会有一个request/response的机制。客户端不停地的查询相关的信息。而事件驱动则是一个很简单的基于推送的消息系统。

在事件驱动架构中，客户端不需要查询就能够接受到相关的更新。这种更新在它发生的第一时间就可以被接受到，和pull不同的是，pull其实是一个查询的间隔的，所以实时性是有很大差别的。

商业叙述历史

我们可能都听说过这个术语：单一真理(single source of truth)。使用事件驱动架构，我们很容易实现这一点。

就像上面所说，事件是不可以改变的，所以一个事件流其实就是一系列不可改变的事件组成的。每次，任何组件有了状态的变化，就会有一个新的事件产生。这就和我们日常的生活很类似，都是由一系列不可改变的事件组成的。对商业数据的管理来说，这个”商业叙述”是非常重要的，他保存了这个系统中发生的所有事件的历史。

现在对于一个公司来说，如何解释“数据衍生”已经越来越重要了。而事件驱动则可以解释这一切，尤其对监管来说特别重要。就像我们所说，事件其实是可以重放的，有了这个，我们就可以重放所有的事件，并要它来做一些决策或者修一个问题。

数据科学的实时事件流

事件驱动架构，可以让商业决策更快地进行，甚至在微秒级。事件流可以使得应用能够根据不断变化的情景来决定该使用什么样的方案，我们可以根据历史的数据，和当前的情况来迅速做出决策。这样一来数据分析就可以实时进行，而不需要先把数据发送到某一个地方，然后再进行分析。这种实时的分析非常有用，尤其可以应用在一些欺诈探测，预测分析之类的场景。

加速机器学习和数据分析落地的步伐

最后，事件驱动架构可以加速机器学习model的落地。如何在产品中部署机器学习是一个很有挑战的部分。

机器学习可以使用事件的骨干，然后允许多个model同时分析数据，然后在不同时间选取最好的model的运行。所有的model都可以广播他们的结果，然后我们可以有一个服务来订阅这个结果，这样根据接收的各个model的结果，来决定用哪个model进行真正的处理。

总结

本文总结了事件驱动架构的优势，使用事件驱动架构可以创建一个完全分开的基于微服务的系统。有了这种独立分开的特性，就可以灵活地使用各种技术来开发各种模块。所以说事件驱动是微服务中最好的实践之一也就不足为奇了。

参考文章：https://developer.ibm.com/articles/advantages-of-an-event-driven-architecture/