翻译|崔浩策展|YunZhao为什么现在几乎每个人都在使用“基于事件”和“事件驱动”这两个词？是否可以使用现有的RESTAPI来构建事件驱动的架构？本文将讨论这两个问题。科技改变世界，科技人一直热衷于让生活更便捷。你可以想象这样一个场景，快递公司1提供包裹跟踪服务，会通知你包裹在哪一天、什么时间内到达（由于运输延误，到达时间可能不正确）；快递公司2主动通知您，目前多少站是您寄来的包裹。您会给哪家快递公司好评？可见，随着业务的不断发展，客户对实时应用和服务的需求也越来越大。如果您的业务应用程序或服务面向客户，您需要关注客户对更直接、实时体验的期望。事件驱动架构越来越具有战略意义，因此事件驱动架构也受到各大公司的青睐。实时应用程序的美妙之处和基于事件的架构的重要性就个人而言，没有人喜欢一直被消息通知轰炸。因此，大多数手机应用程序都关闭了此功能。但在某些情况下，用户将需要实时或至少接近实时的更新。送货就是其中之一：用户往往更喜欢在送货员按门铃之前阻止他，这会让家里的狗歇斯底里地狂吠。基于此，用户希望有这样一个应用，它会在快递员离我家还有一站路的时候通知我。（通过实时消息通知我，而不是让用户每十分钟检查一次状态）或者想象一个签到应用程序，它会在您更改登机口时向您发送实时推送通知——如果这个更改发生在您的登机口前半小时航班，此应用程序对您非常有用，尤其是当您遇到交通堵塞并且必须前往登机口以避免迟到时。消息推送服务与信息的载体无关，而是如何主动为客户提供实时可用的服务。这也是现在讲的客户体验。客户体验虽然不能改变商业游戏规则，但其产生的服务差异成为选择航空公司的依据。在大多数情况下，应用程序之间的交换是通过API（通常是REST）进行的。例如，一个应用程序有一个更新——包裹已经发货，或者特定航班的登机口发生了变化——而另一个应用程序收到了该更新。问题在于RESTful应用程序和服务本质上是基于轮询的。这意味着他们以特定的时间间隔获取数据，甚至仅在被要求时才要求这样做（通过刷新应用程序来获取数据）。为了提高用户体验，主动、实时地为用户提供信息，我们需要一种差异化的机制来立即触发业务应用程序、服务和系统以响应特定事件。这就是基于事件的架构存在的意义。构建基于事件的架构所需的组件虽然没有一种方法可以构建事件驱动的架构并同时实现多个变体、协议和方法。但本质上，它由三个独立的组件组成——事件生产者、事件消费者和事件代理。解耦使得异步处理事件成为可能——这确保了事件生产者和事件消费者独立工作。事件驱动架构模式事件生产者事件生产者本质上是事件的发送者。在上面的示例中，商品跟踪系统或商店管理系统可以用作事件生产者。事件消费者从逻辑上讲，事件消费者就是事件的接收者。它可以是手机上的应用程序，或公司IT生态系统中的其他业务应用程序，它检查或侦听特定事件的发生，以便它可以做出相应的响应——例如，由手机上的推送通知触发另一个应用程序。通常，这是通过订阅特定事件的事件消费者实现的。事件代理现在，事件代理是基于事件架构的重要组成部分，实现了事件生产者和事件消费者的解耦。事件代理接受来自前者的事件，长期存储它们，并将事件发送给后者。根据事件消费者的数量，事件代理还负责将事件路由到正确的消费者。在这种情况下最常用的消息传递模式是发布/订阅（发布/订阅）。异步模式确保没有消息丢失。即使一个或多个事件消费者（即订阅者）由于某种原因在给定时刻不可用，事件也会按照它们产生的顺序排队等待消费。一旦事件使用者重新联机，它将使用排队的消息并恢复其先前的活动。REST也可以构建基于事件的架构大多数时候，在搜索有关如何创建事件驱动架构的信息时，您会发现诸如“StreamingAPI”和“事件驱动API”之类的术语。您可能知道或猜到了，这些是支持事件驱动通信的新型API。然而，现实是大多数软件应用程序供应商不提供这些类型的API，要么是因为有其他关键业务优先级，要么就是他们根本没有所需的资源。这就是扩展现有API以适应基于事件的架构变得有趣的地方。在增强现有的RESTAPI时，根据事件驱动模式下API的角色，可以采取以下策略：这些API是事件生产者还是事件消费者？当RESTAPI是事件生产者时，解决方案通常非常简单；我们只需要一个支持各种API（包括REST）和协议的事件代理——换句话说，它可以帮助将REST转换为类似AMQP或MQTT协议的消息。当RESTAPI是事件消费者时，解决方案可能会更复杂，需要找到机制来设置对现有RESTAPI或事件代理的主题订阅，并教他们如何基于事件进行订阅。这通常是通过一个事件驱动层来实现的，该层由webhook、发布/子服务和服务器发送的事件组成。总结一下：如果一家公司实施仅提供RESTAPI的业务软件应用程序和系统，您仍然可以围绕它们构建基于事件的架构。虽然这样做会使系统显得复杂，但有时有必要使用所有可用的方法，尤其是当解决方案不是那么明显时，显然添加到现有API是一个可靠的解决方案。旁注：虽然流和事件驱动的API受到如此多的关注，但RESTAPI不会很快消失。因为，通过流/事件驱动的API和事件代理增加异步通信的情况不如RESTAPI多。从这个角度来看，将会有更多结合REST和流/事件驱动API的混合架构。事件驱动的应用程序集成方法基于事件的架构不仅仅通过应用程序和服务提供出色的客户体验。它在应用集成方面也表现非常出色——除了实时数据同步外，还可以节省大量资源。德国最大的私营啤酒厂之一希望建立一个强大的360度客户视图，并简化跨渠道的营销工作，旨在提供个性化的消息传递，并最终实现出色的客户服务和满意度。在项目的第一阶段，他们专注于应用节点的链接，将SalesforceCRM与Exponea的客户数据和体验平台之间的数据打通。为确保各种记录系统之间的无缝连接，该公司使用Webhook和AMQP来触发集成流程，只要应用程序和系统支持通过Webhook或事件总线推送数据的能力即可。并且在Pub/Sub的帮助下，每个集成过程都保持尽可能小，从而实现模块化的过程架构。此外，不仅要在两个系统之间同步数据，而且要将同步数据的系统数量增加到3-5个，Pub/Sub允许将这些流分成小块并在它们之间动态传播更新。写在最后这篇文章并不打算一步步描述如何构建基于事件的架构，因为要考虑的用例太多，支持的技术也太多，无法将其打包成一篇文章。同时，需要考虑的变数太多：比如IT基础设施、个人对技术栈的偏好、可用资源等。希望通过本文对“如何基于现有API环境创建事件驱动架构”这一问题的探讨，给各位朋友带来一些有趣的思考。原文链接：https://dzone.com/articles/creating-event-based-architecture-on-top-of-existi?fromrel=true译者介绍崔浩，社区编辑，高级架构师，18年软件开发经验和架构经验，10年分布式架构经验。他曾经是惠普的技术专家。乐于分享，撰写了多篇阅读量超过60万的热门技术文章。《分布式架构原理与实践》作者。
