REST会消失吗？事件驱动架构如何搭建？

为什么“基于事件”和“事件驱动”这两个词现在几乎每个人都会挂在嘴边？能否使用现有的REST API来构建事件驱动的架构？本文将围绕这两个问题展开讨论。

技术改变世界，技术人一直热衷于让生活更加便捷。可以想象如下场景，快递公司1提供了包裹跟踪服务，会通知你包裹在哪一天以及什么时间范围内到达（有可能出现达到时间由于运输延误不正确的情况）；快递公司2主动通知你，当前包裹离你还有多少站。你会给予哪家快递公司好评？由此可见随着业务的不断发展，客户对实时应用和服务的需求也在不断增加。如果你的业务应用或服务是面向客户的，就需要关注客户期望获得更直接、实时的体验。事件驱动架构就越来越具有战略重要性了，因此事件驱动架构也受到各大公司的青睐。

实时应用之美和基于事件架构的重要性  

就个人而言，谁都不喜欢被消息类的通知一直狂轰滥炸。因此，大多数手机应用程序都关闭了此功能。但在某些情况下，用户又会需要实时或至少接近实时的更新。快递就是其中之一：用户往往更喜欢在递送人员按门铃之前就阻止他，因为门铃声会让家中的宠物狗歇斯底里的乱叫。基于此，用户希望有这样一个应用程序，它会在快递离自己家还有一站的时候就通知我。（通过实时消息的方式通知我，而不是让用户每十分钟就检查一次消息状态）或者想象有这么一个值机的应用程序，它会在更改登机口时向您发送实时推送通知 - 如果这种更改发生在航班起飞前半小时，这个应用就对你非常有用，特别是你正在遭遇交通拥堵，为了避免迟到而还不得不赶往登机口的情况下。消息推送服务与提供信息的载体无关，而关乎于如何主动为客户提供实时的、可用的服务。这也是如今被人津津乐道的客户体验。虽说客户体验并不能改变商业的游戏规则，但其产生的服务差异成为了选择航空公司的依据。多数情况下，应用之间的交换是通过API（通常是REST）实现的。例如，一个应用程序有一个更新——一个包裹已经发货，或者特定航班的登机口已经改变——而另一个应用程序接收到这个更新。问题是RESTful应用程序和服务本质上是 基于轮询的 。这意味着他们以特定的时间间隔获取数据，甚至仅在被要求时才要求这样做（通过刷新应用程序获取数据）。为了提升用户体验，并主动、实时地为用户提供信息，我们 需要一种与众不同的机制 ，以便立即触发业务应用程序、服务和系统从而响应特定事件。这就是基于事件架构存在的意义。

构建基于事件架构所需的组件  

虽然没有一种方法可以构建事件驱动的架构，并同时实现多种变体、协议和方法。但本质上，它由三个分离的组件组成——事件生产者、事件消费者以及事件代理。解耦使得异步处理事件成为可能——这确保了事件生产者和事件消费者独立工作。

事件驱动架构模式

事件生产者

事件生产者本质上是事件的发送者。在上图的例子中，可以将货物跟踪系统或门店管理系统作为事件生产者。

事件消费者 ​

从逻辑上讲，事件消费者是事件的接收者。它可以是手机上的应用程序，也可以是公司IT生态系统中的其他业务应用，用于检查或侦听特定事件的发生，以便做出相应的响应——例如，通过手机上的推送通知触发另一个应用。通常，这是通过订阅特定事件的事件消费者来实现的。

事件代理

现在，事件代理是构成了基于事件架构的重要组成部分，并实现了事件生产者和事件消费者的解耦。事件代理接受来自前者的事件，并长期存储它们，然后将事件发送给后者。根据事件消费者的数量，事件代理还负责将事件路由到正确的消费者。在这种情况下最常用的消息传递模式是pub/sub（发布/订阅）。异步模式可确保不会丢失任何消息。即使一个或多个事件消费者（即订阅者）在给定时刻由于某种原因不可用，事件也会按照产生的顺序排队等待消费。一旦事件消费者重新上线，将会消费排队的消息并恢复其先前的活动。

REST也能构建基于事件的架构  

大多数时候，当搜索有关如何创建事件驱动架构的资讯时，会发现诸如 “Streaming API”和“event-driven API”的术语。正如您可能知道或猜想的那样，这些都属于支持事件驱动通信的新型API。然而，现实情况是，大多数软件应用程序供应商不提供这些类型的API，要么是因为存在其他关键业务优先级，要么他们根本没有所需的资源。这就是 扩展现有API以使其适合基于事件架构 有趣的地方。在谈到增强已有的REST API时，可以根据API在事件驱动模式中的角色采取如下几种策略：这些API是事件生产者还是事件消费者？ 当REST API是事件生产者 时，解决方法通常非常简单；我们只需要一个支持各种API（包括 REST）和协议的事件代理——换句话说，它可以帮助将REST转换为AMQP或MQTT等消息协议。 当REST API是事件消费者 时，解决方法可能会更复杂，需要找到机制来设置对现有REST API或事件代理的主题订阅，并教他们如何基于事件订阅。这通常可以通过由webhook、pub/sub-services和服务器发送事件组成的事件驱动层来实现。

总结一下：如果公司实施的业务软件应用程序和系统仅提供REST API，您仍然可以围绕它们构建基于事件的架构。虽然这样做会让系统显得复杂，但有时需要利用一切可以利用的方法，特别是解决方案并不那么显而易见的时候， 显然增加现有API 是一种可靠的解决方法。 附注：尽管流和事件驱动的API受到如此多的关注，但REST API不会很快消失。因为，通过流/事件驱动的API和事件代理增加异步通信的案例没有REST API的案例数量那么多。从这个角度而言，将会出现更多融合了REST和流/事件驱动API的混合架构。

应用程序集成中的事件驱动方法 

基于事件的架构不仅可以通过应用和服务提供出色的客户体验。它应用集成方面也非常表现出色——除了可以实时数据同步，还可以节省大量资源。德国一家最大的私营啤酒厂希望建立强大的360度客户视图并简化其跨渠道的营销工作，旨在实现个性化消息传递并最终获得出色的客户服务和满意度。在该项目的第一阶段，他们的专注于应用节点的链接，他们将Salesforce CRM以及Exponea的客户数据和体验平台之间的数据进行互联互通。为了确保各种记录系统之间的无缝连接，该公司使用webhook和AMQP来 触发集成流 ，只要应用和系统支持webhook或事件总线推送数据的能力就可以顺利达成。并且在Pub/Sub的帮助下，将每个集成流程保持在尽可能小的范围内，从而 实现了模块化的流程架构 。此外，不仅在两个系统之间同步数据，还要将同步数据的系统数量提升到3-5个， Pub/Sub允许将 这些流分成小块 并在它们之间动态传播更新。

写在最后 

本文并不打算一步步地描述如何构建基于事件的架构，因为有太多的用例需要考虑，也有太多的支持技术需要提及，无法将其打包成一篇文章。同时也会有太多的变量需要考虑：例如IT 基础设施、技术堆栈的个人偏好以及可用资源等。希望通过本篇文章围绕“ 如何在现有的API环境 之上创建基于事件驱动的架构”这个问题的探讨，给各位朋友带来一些有意的思考。