事件驱动架构_了解事件驱动架构

事件驱动架构

事件驱动的体系结构是一种软件体系结构范例&＃xff0c;可促进事件的产生&＃xff0c;检测&＃xff0c;使用和响应。

如何实现事件驱动的体系结构&＃xff0c;以及何时使用它&＃xff1f;

事件驱动的体系结构与微服务齐头并进。 发生操作时&＃xff0c;将创建一个事件&＃xff0c;然后将该事件用于在所有等待该事件发生的事件上做出决策。

服务不再绑定在一起&＃xff0c;因为在发布订阅类型模型中&＃xff0c;调用者不再同步调用被调用者。 相反&＃xff0c;被呼叫者以最终一致的方式对事件进行操作。

因此&＃xff0c;事件驱动的体系结构可以更可靠&＃xff0c;因为它们不必立即对服务调用进行操作&＃xff08;允许服务在成功之前都能够失败&＃xff09;&＃xff0c;但是很难预测何时执行操作&＃xff08;对于同样的原因&＃xff09;。

事件驱动架构的一个简单示例是Amazon。 如果您曾经在忙碌的时间&＃xff08;例如黑色星期五&＃xff09;在亚马逊购物&＃xff0c;则可以订购商品&＃xff0c;但之后只能发送电子邮件说明您订购的商品实际上无货。

如果您以事件驱动的体系结构来考虑此过程&＃xff0c;则它可能以下列方式工作&＃xff1a;

客户订购该项目并发布OrderPlaced事件Stock服务订阅了该事件&＃xff0c;但是在处理事件时&＃xff0c;它检查了库存&＃xff0c;现在为0 The Stock服务随后发布了OutOfStock事件电子邮件服务订阅了该事件并向客户发送电子邮件&＃xff0c;说明该商品无库存。

事件驱动的体系结构可以将队列与发布订阅模型结合使用作为支持模型。 这是为了保证在链中某些服务无法处理事件的情况下传递事件消息。

事件驱动架构的优缺点

有几个原因为什么使用事件驱动的体系结构比其他体系结构有优势。

• 松散耦合 —服务不需要相互依赖。 这应用了不同的因素&＃xff0c;例如传输协议&＃xff0c;可用性&＃xff08;服务在线&＃xff09;和正在发送的数据。 消费者仍将需要知道如何解释事件或消息&＃xff0c;因此在这两个服务之间仍应使用严格的合同&＃xff0c;但是合同的实现细节无关紧要。
• 可扩展性 —由于服务不再耦合&＃xff0c;服务1的吞吐量不再需要满足服务2的吞吐量。这可以帮助降低成本&＃xff0c;因为服务不再需要24/7全天候在线&＃xff0c;并且可以利用无服务器计算的无限扩展。
• 异步性 -由于服务不再依赖于同步返回的结果&＃xff0c;因此可以使用即发即弃模型&＃xff0c;这可以大大加快流程。 这可能会有一个缺点&＃xff0c;下面将对此进行概述。
• 时间点恢复 -如果事件由队列支持或维护某种历史记录&＃xff0c;则可以重播事件&＃xff0c;甚至可以及时返回并恢复状态。

使用事件驱动的体系结构也有缺点。

过度设计流程 -有时从一个服务到另一个服务的简单调用就足够了。 如果流程使用事件驱动的体系结构&＃xff0c;则通常需要更多的基础结构来支持它&＃xff0c;这将增加成本&＃xff08;因为它将需要一个排队系统&＃xff09;

不一致 -由于流程现在依赖于最终的一致性&＃xff0c;因此通常不支持ACID&＃xff08;原子性&＃xff0c;一致性&＃xff0c;隔离性&＃xff0c;持久性&＃xff09;事务&＃xff0c;因此重复处理或乱序事件的处理会使服务代码更加复杂&＃xff0c;并且难以测试和调试所有情况。

事件发生变化会怎样&＃xff1f;

想象一下一种情况&＃xff0c;当我想添加或更改事件的合同时&＃xff0c;例如在OrderPlaced事件中&＃xff0c;将数量从整数更改为浮点数。

如果不期望此更改&＃xff0c;这种情况将使订户中断。

您需要对事件的合同进行版本控制&＃xff0c;以防止这种破坏。 一个好的经验法则通常是&＃xff0c;对合同的任何增加都是可以的&＃xff0c;但是要删除或更改某些内容&＃xff0c;必须发布该事件的新版本&＃xff0c;而订户也希望有新的事件合同。

翻译自: https://hackernoon.com/understanding-event-driven-architecture-ub1k3umo

事件驱动架构