我一直在学习Storm和Samza，以了解流处理引擎是如何工作的，并意识到它们都是独立的应用程序，为了处理事件，我需要将其添加到也连接到流处理引擎的队列中。这意味着我需要将事件添加到队列中（这也是一个独立的应用程序，比如Kafka），Storm将从队列中选择事件并在工作进程中处理它。如果我有多个螺栓，每个螺栓将由不同的工人处理。（这是我真正不理解的事情之一，我看到一家公司在生产中使用了20多个螺栓，每个事件都在螺栓之间以特定的路径转移）
然而，我真的不明白为什么我需要如此复杂的系统。这些过程涉及太多的IO操作（我的程序->队列->风暴->螺栓），这使得控制和调试它们变得更加困难。
相反，如果我从web服务器收集数据，为什么不使用相同的节点进行事件处理呢？操作将通过我用于web服务器的负载均衡器分布在节点上。我可以在相同的JVM实例上创建执行器，并将事件从web服务器异步发送到执行器，而不涉及任何额外的IO请求。我还可以观察web服务器中的执行器，并确保执行器处理了事件（至少一次或一次处理保证）。这样，管理我的应用程序会容易得多，而且由于不需要太多IO操作，与通过网络将数据发送到另一个节点（这也不可靠）并在该节点中处理数据的其他方式相比，它会更快。
很可能我错过了一些东西，因为我知道很多公司都在积极使用Storm，我认识的很多人都推荐Storm或其他流处理引擎来进行实时事件处理，但我就是不理解。
我的理解是，使用Storm这样的框架的目标是从应用程序/web服务器上卸载繁重的处理（无论是cpu绑定、I/O绑定还是两者兼有），并保持它们的响应能力。
考虑一下，每个应用程序服务器可能必须为大量并发请求提供服务，而不是所有请求都与流处理有关。如果应用程序服务器已经在处理大量事件，那么它可能会成为较轻请求的瓶颈，因为服务器资源（比如cpu使用率、内存、磁盘争用等）已经与较重的处理请求绑定在一起。
如果你需要面对的实际负载没有那么重，或者可以简单地通过添加应用程序服务器实例来处理，那么复杂化你的体系结构/拓扑结构当然没有意义，这实际上可能会减缓整个过程。这实际上取决于您的性能和负载需求，也取决于您可以在这个问题上投入多少（虚拟）硬件。和往常一样，基于负载需求的基准测试将有助于决定走哪条路。
您认为通过网络发送数据将消耗更多的总处理时间是正确的。然而，创建这些框架（Storm、Spark、Samza、Flink）是为了处理大量可能不适合一台计算机内存的数据。因此，如果我们使用多台计算机来处理数据，我们就可以实现并行性。接下来，请回答您关于网络延迟的问题。对这是一个需要考虑的折衷方案。开发人员必须知道他们正在实现要在并行框架中部署的程序。他们构建应用程序的方式也会影响通过网络传输的数据量。