技术改变世界，技术人一直热衷于让生活更加便捷。可以想象如下场景，快递公司1提供了包裹跟踪服务，会通知你包裹在哪一天以及什么时间范围内到达（有可能出现达到时间由于运输延误不正确的情况）；快递公司2主动通知你，当前包裹离你还有多少站。你会给予哪家快递公司好评？

由此可见随着业务的不断发展，客户对实时应用和服务的需求也在不断增加。如果你的业务应用或服务是面向客户的，就需要关注客户期望获得更直接、实时的体验。事件驱动架构就越来越具有战略重要性了，因此事件驱动架构也受到各大公司的青睐。

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

PART 01

事件驱动架构的简介

EDA使用事件触发解耦应用程序、微服务和连接设备之间的通信，并使信息能够实时流动。为了真正理解它的全部内容，回顾一下分布式软件系统架构的历史以及它在过去几十年中是如何发展的是非常有用的。

20世纪40年代的第一批软件程序使用子例程，根据一组指令执行任务。著名的是，ENIAC团队的程序员在第二次世界大战期间开发了计算导弹轨迹的子程序。

然后，计算架构设计逐渐演变为以能够远程执行多个子例程的编排器系统为中心。从这个结构中出现了请求-响应范式：编排器节点向不同的计算机发送带有请求的子例程，然后计算机处理请求并将响应返回给原始编排器。

1989年Tim Berners-Lee发明万维网后，HTTP成为部署分布式系统的首选方法，URL公开和访问子例程，这自然导致了API。随着业务重点更加关注实时体验，API成为当今企业创新的关键驱动力。

PART 02

使用事件驱动架构的好处

高效的开发——事件驱动的架构本质上是可扩展的，在应用程序开发中提供了很大的灵活性。虽然初始设置时间可能很长，但一旦启动并运行，几乎不需要任何努力来扩展。一个很好的例子就是电子商务平台，在这个平台上，客户通常会实时收到订单状态的通知，这让我们获得了下一个好处。

更好的用户体验——事件驱动的架构带来更好的整体用户体验。以前面的示例为例，应用程序记住客户的购买历史、订单状态、浏览行为和一般偏好的出色在线购物体验会带来更好的用户体验，从而提高客户保留率。

降低运行成本——从长远来看，事件驱动的架构可以降低企业的运行成本。但是请记住应该在何处部署事件驱动架构。如果您的应用程序没有太多流量，那么创建一个事件驱动的架构可能有点过头了。

弹性 – 事件驱动的架构可以使您的应用程序更具弹性。如果服务失败，它可以自动重新启动并处理来自事件数据存储的事件。这有助于避免交易损失。

PART 03

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

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

事件驱动架构模式

事件生产者

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

事件消费者

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

事件代理

现在，事件代理是构成了基于事件架构的重要组成部分，并实现了事件生产者和事件消费者的解耦。事件代理接受来自前者的事件，并长期存储它们，然后将事件发送给后者。根据事件消费者的数量，事件代理还负责将事件路由到正确的消费者。在这种情况下最常用的消息传递模式是pub/sub（发布/订阅）。

异步模式可确保不会丢失任何消息。即使一个或多个事件消费者（即订阅者）在给定时刻由于某种原因不可用，事件也会按照产生的顺序排队等待消费。一旦事件消费者重新上线，将会消费排队的消息并恢复其先前的活动。

PART 04

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的混合架构。

PART 05

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

基于事件的架构不仅可以通过应用和服务提供出色的客户体验。它应用集成方面也非常表现出色——除了可以实时数据同步，还可以节省大量资源。

德国一家最大的私营啤酒厂希望建立强大的360度客户视图并简化其跨渠道的营销工作，旨在实现个性化消息传递并最终获得出色的客户服务和满意度。在该项目的第一阶段，他们的专注于应用节点的链接，他们将Salesforce CRM以及Exponea的客户数据和体验平台之间的数据进行互联互通。

为了确保各种记录系统之间的无缝连接，该公司使用webhook和AMQP来触发集成流，只要应用和系统支持webhook或事件总线推送数据的能力就可以顺利达成。并且在Pub/Sub的帮助下，将每个集成流程保持在尽可能小的范围内，从而实现了模块化的流程架构。此外，不仅在两个系统之间同步数据，还要将同步数据的系统数量提升到3-5个， Pub/Sub允许将这些流分成小块并在它们之间动态传播更新。

PART 06

事件驱动架构在内容平台中的实践

在当今社会，内容“横行”的时代，内容平台企业需要有极强的灵活性和应变能力。特别是在中国这样一个内容行业（如视频）飞速发展的市场里，企业要求平台能够快速地对内容业务需求做出应对，否则就会丧失先发优势。这有点类似于现代战争条件下，各国都要求部队具备快速反应能力，这种能力主要体现在平台能够通过快速开发或者重用 / 整合现有资源来达到快速响应业务需求。

随着内容行业业务越来越庞大复杂，所涉及的存储类型、处理器、账号体系、效率工具、数据和结算系统等非常多，这就要求平台有很强的整合能力以及对异构环境的适配能力。

最后，由于内容行业的发展日新月异，特定类型的内容业务（如小视频）都会在其初中期发展后迎来一个快速膨胀期，业务量和业务类型会急剧增加，这也要求平台有很好的可扩展性。

来源：51CTO技术栈，K8S技术社区，高可用架构，认知计算与云安全