事件驱动架构——如何更高效？答案

【问题标题】：Event Driven Architecture - How can it be more efficient?事件驱动架构——如何更高效？
【发布时间】：2020-08-08 17:56:42
【问题描述】：

我试图了解事件驱动架构如何比传统架构更高效。当然是松耦合的。

让我们想象一下。我们有 2 个 spring-boot 微服务。

微服务-A 引发一个事件，微服务-B 监听该事件并执行一些操作。使用 EDA 方法，微服务 B 依次处理所有这些事件。为了扩展，我必须运行多个微服务 B 实例。但如果我使用传统方法，多个 HTTP 请求将由单个服务器并行处理。那么，使用 EDA 方法，单线程和顺序处理不是一种很好的资源利用方式吗？

【问题讨论】：

为什么说事件是一一处理的呢？即使在单线程微服务中，大多数操作也需要大量的 IO 等待，因此它们可以高度并行化。
@FrancescCastells，我能这样理解吗？这是意料之中的。由消费者以非阻塞方式处理请求。要提高消息/事件处理速度，请水平扩展异步/非阻塞。
跟API场景没什么区别。由于多线程，api 和消息处理器都可以处理许多并发操作。如果操作也被实现为异步，那么您可以增加很多并发性，因为它们不会阻塞线程。在任何情况下，操作都是相同的，它们消耗相同的资源。不同之处在于消息传递是暂时解耦的（请求和执行不需要同时发生）

【解决方案1】：

事件驱动并不意味着线性事件流、事件排序或使用 Kafka。

就像它与事件溯源、领域驱动设计或 sagas 无关。您需要做的就是将事件发布到某些消息传递基础架构，以便下游系统可以使用它。

事件驱动本质上是消息传递。这不是新的，所有消息传递模式都在 Martin Fowler 的“企业应用程序架构模式”一书中得到了正确的描述。消息传递中没有任何内容提到顺序单线程处理。

就像您对 HTTP 调用进行负载平衡一样，您可以将 competing consumers 与消息代理一起使用以进行水平扩展。所有流行的消息代理都支持竞争消费者，这是业界使用了几十年的众所周知的模式。

【讨论】：

在我的示例中，competing consumer 只不过是微服务 B 的水平扩展。这本书可能不会说单/多线程。大多数消息处理将是顺序的。您的意思是 - 由消费者在收到消息后使用多个线程处理消息。
您将“传统方法”与 HTTP 负载平衡进行了比较，根据定义，HTTP 负载平衡不能进行有序处理。与此相比，EDA 没有任何变化。竞争消费者和负载均衡器的行为方式相同。关于排序，谷歌有一篇很好的文章cloud.google.com/pubsub/docs/ordering#do_i_really_have_order