当可以使用直接连接到 kafka 的微服务时，使用 storm 拓扑有什么好处。微服务方法似乎为以下方面提供了更好的解决方案：
虽然风暴拓扑似乎使用需要静态函数的普通 java。
那么使用风暴拓扑而不是微服务有什么好处？
这与单片与微内核设计的争论非常相似。在单片内核中，只有一个地址空间。 Storm 有点像这样——您必须使用它们特定的 API 才能使用 Storm 中的服务。如果您使用 Java 或受支持的 API，那么您很幸运。同样，这就像一个内核库——您查看内核为您提供的 API，然后使用它。
对于微内核，内核所做的就是传递消息。这就像卡夫卡。它只是一个消息传递架构。任何进程都可以参与集群，只要它可以发送适当结构化的消息。
就像整体内核与微内核一样，它归结为您的设计目标和个人哲学之间的相互作用。我的论点是你可以通过微服务构建一个类似 Storm 的架构，但它比开箱即用的 Storm 需要更多的工作。一个相关的论点是你不能通过 Storm 构建微服务架构。
可扩展性和弹性 - 使用微服务架构，您将必须为可扩展的弹性架构提供自己的模式。你说你可以用“更多的工作”自己构建它们，这是真的，但是分布式系统很难，所以最后你有时间和资源吗？
微服务是在 DDD 的上下文中定义和存在的，并且专门服务于域的原子有界上下文：它是业务逻辑的原子部分。此外，微服务作为构建盒可以成为许多应用程序的一部分。 Kafka 消息传递可以扮演事件和事件源的角色，这是微服务架构的编排模式所固有的。 Kafka 流可以是部分业务逻辑的脏实现，但是，它是一种分布式计算。 Storm 也是一样：它是一个分布式计算，Spouts 和 Bolts 只能在 Storm 集群内使用，不能在其他任何地方使用。