事件驱动系统如何在商业中工作

假设有人在等待包裹送到他们家。不耐烦的顾客不停地向窗外张望，等待送货卡车停下来。耐心的顾客一直在做其他的事情，直到他们听到门铃响。这个日常示例可以很容易地转换到计算机科学领域，其中存在两种类型的系统：轮询系统和事件驱动系统。

投票系统的行为就像不耐烦的顾客。在与商业相关的场景中，它不断轮询系统以获取新的更新，如订单和支付授权，而事件驱动系统依赖异步事件处理程序来通知它系统中的更新。

事件驱动系统更容易开发，效率更高，但它需要特殊的基础设施才能工作。好消息是，一些软件和平台(如Fabric)支持事件驱动系统。在商业中，这些系统创建了更精简的操作，以便客户更快地获得订单。

在这篇文章中，我们将定义什么是活动，以及零售商如何利用这些活动来创建更高效的系统。但是，在此之前，让我们看一个事件驱动系统如何支持零售商及其客户的示例。

在购物车中添加了多个商品后，Joe转到零售商网站上的结账页面。他填写地址和付款信息，然后下订单。但是接下来会发生什么呢？

通过投票系统，乔的订单存储在数据库中。一段时间后，脚本或人员查询数据库以查找任何新订单并处理付款。然后仓库中的另一个脚本或人员查询数据库并开始交付过程。

这种处理付款和履行的方式很慢，而且容易出错。现在，考虑到在线订购的增加，实时处理事件在商业中比以往任何时候都更加重要。

定期轮询系统可能会造成操作瓶颈，特别是在订单活动出现意外峰值的情况下。此外，在没有下新订单的情况下查询数据库会导致不必要的基础设施成本。

Joe的订单像以前一样存储在数据库中，但这一次将事件发送到事件路由器。

事件路由器查找可以处理此类事件的对象，并发现支付处理脚本负责该事件。

支付处理脚本使用适当的支付数据调用支付处理器(例如，条纹)。

支付处理脚本发出支付授权事件。此事件向Joe发起订单确认电子邮件，并向仓库发出通知以供履行。

计算机科学中的基于事件的系统可以追溯到20世纪50年代，在那里它们第一次被设计成处理输入/输出等异步事件。Edsger Wybe Dijkstra在Electrlogica X-1上设计了第一个中断处理程序，至今仍在现代系统中使用。现代赛事的概念是相同的，只是使用的环境不同。

当CPU中断出现时，系统会改变其行为以处理传入的中断。这可能是按下的新击键，也可能是该进程即将终止的通知。中断并没有告诉进程要做什么，只告诉它发生了一些事件。进程有责任处理中断并决定如何处理它。

事件驱动系统中的事件也会发生同样的情况。创建事件时，事件本身不应该决定发生了什么；它应该只描述发生了什么，无论是状态更改还是更新。例如，在现代商业技术堆栈中，事件路由器可以将废弃购物车事件发送到像Klaviyo这样的电子邮件平台，该电子邮件平台决定将Joe登记到废弃购物车电子邮件序列中。

事件的结构和发出方式在很大程度上取决于事件路由器。有许多不同类型的事件路由器，包括AWS EventBridge、Apache Kafka和Microsoft Event Hub。

事件是遵循特定方案的JSON文档。所有事件类型的顶级字段都相同，但每个事件的详细信息取决于应用程序。

例如，如果乔成功地从零售商订购了一件商品，他的“Order Created”事件将类似于下面的…。

{"；cartId"；："；314919ab8aed637123f804eb"；，"；orderCurrency"；："；USD"；，"；orderTotal"；：27.64，"；orderId"；："；314919ab8aed637123f804eb"；，"；Ship to"；：[{"；address"；：{"；name"；：{"；name"；第一个"；："；约翰"；，"；最后"；："；史密斯"；}，"；电话"；：{"；号码"；："；5555555555"；，"；种类"；："；手机"；}，"；电子邮件"；："；[email protected]"；，"；Street1"；："；1250main Street"；，"；，"；City"；："；Havre de Grace"；，"；State"；："；MD"；，"；Country"；："；US"；，"；邮政编码"；："；21078-3213"；，"；种类"；："；Shipping"；}，"；ShipmentCarrier"；："；联邦快递"；}]，"；项目"；：[{"；ITEMID"；：4912，"；价格"；：122.43，"；数量"；：1，"；总数"；：122.43}，{"；ITEMID"；：8123，"；价格"；：21.99，"；数量"；：3，"；总计"；：65.97}]}。

以自定义方式处理事件的最直接方法是使用函数即服务(FAAS)解决方案，如AWS Lambda，该解决方案本机支持Java、Go、Powershell、Node.js、C#、Python和Ruby，但提供Runtime API以允许使用任何其他编程语言。

由于AWS只对其运行时间收费，因此开发Lambda函数的操作更容易且成本更低。这被称为无服务器，这是我们在Fabric使用的另一项技术，它使商业更具可扩展性和可伸缩性。

事件驱动系统是商业的理想选择，因为许多商业设置包含不同的服务和微服务，这些服务和微服务可以从解耦中获益。支付、促销、定价、订阅、搜索和评论只是这些服务中的一小部分。

解耦允许更快的开发周期(因为每个服务都可以独立开发)，更便宜的运行时间(因为每个服务可以独立扩展)，以及更快的页面加载时间。事件驱动系统促进了服务的解耦，因为不同的服务可以通过事件路由器相互通信，而不是直接相互依赖。

事件驱动系统的另一个好处是它们处理故障情况的潜力。如果两个服务相互依赖，其中一个服务因任何原因而出现故障，则另一个服务将无法正常运行。但是，通过事件路由器的帮助，如果服务由于任何原因(如更新或错误)而变得不可访问，事件路由器将存储事件，直到可以将其传递给其预期的处理程序。例如，在支付处理脚本不可用的场景中，购物车应该仍然可以工作。

在这篇文章中，我们概述了事件驱动系统是如何简化商业流程的。有关事件和事件路由器如何让不同服务在商务技术堆栈中更好地通信的更详细视图，请查看AWS提供的此视频。