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

Question

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

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

但除此之外，我还有很多其他好处，例如

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

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

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

我能想到的一个批评是，是否值得为单体应用管理事件总线？ 如果我要使用像 apache kafka 这样的东西，它非常昂贵且难以管理，它可能不值得。

但是如果我要使用类似 NATS Streaming 或 Redis stream 的东西，它们或多或少地做与 apache kafka 相同的工作，但重量轻且更易于管理，那么我认为这也不是问题.

当我 google 找不到关于这些想法的文章时，我想知道我是否遗漏了一些重要的东西。

Answer 1

在我的新项目中，我尝试了“事件驱动的模块化单体”，到目前为止的开发体验非常棒。为此，我还制作了一个 npm 库 event-driven，以简化“事件驱动架构”。消息代理上有一个相当复杂的层，使 pub/sub 具有完美的重放功能和死信队列。它仍然是基本的，但如果有人感兴趣，请随时查看它。