为什么不采用整体事件驱动架构？

Question

我一直在构建事件驱动的微服务。然后，我想知道为什么不使用事件驱动的整体应用程序。

现在的缺点是可扩展性问题。我无法为特定流量密集型域制作副本。

但除此之外，我仍然获得许多其他好处，例如

1. 最终一致性
2. 我个人还发现使用正确的设置进行调试更容易，因为我可以重播事件。
3. 降低复杂性。域之间的解耦（我们仍然在文件夹中管理域）

此外，我们还有整体优势：主要是减少了 DevOps。

当应用程序变得流行（以及更多流量）时，我们可以轻松地将其转换为微服务。我认为将代码从非事件驱动转换为事件驱动是最具挑战性的部分，因为它显着改变了整体架构。

我能想到的一个批评是，仅仅为了一个整体来管理事件总线是否值得？如果我要使用像 apache kafka 这样的东西，它非常昂贵且管理起来具有挑战性，可能不值得。

但是，如果我使用 NATS Streaming 或 Redis Stream 之类的东西，它们或多或少与 apache kafka 完成相同的工作，但重量轻且更易于管理，那么我认为这也不会成为问题。

当我用谷歌搜索时，我找不到关于这些想法的文章，所以我想知道我是否遗漏了一些重要的东西。

Answer 1

在我的新项目中，我尝试了“事件驱动的模块化整体”，到目前为止的开发体验令人惊叹。我还为此制作了一个事件驱动的npm 库，以便使“事件驱动架构”变得容易。消息代理上有一个相当复杂的层，通过重播功能和死信队列使发布/订阅完美无缺。它仍然是基础的，但如果有人感兴趣，请随意查看一下。