为什么不采用单片事件驱动架构？

Question

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

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

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

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

此外，我们还有单体应用的好处：主要是减少了 devops。

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

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

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

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

Answer 1

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