喷口的设计和目的是投票，所以你不能推他们。然而，许多人所做的是使用redis、thrift或kafka等服务，你可以将消息推送到这些服务上，然后你的朋友就可以对它们进行投票。

您对喷口何时何地运行的控制是有限的，因此让外部进程直接与喷口通信有点麻烦。这当然是可能的，但这不是最简单的解决办法。
标准解决方案是将消息推送到某个外部消息队列，并让您的喷口轮询此消息队列。
在storm contrib中，对于常用的消息队列服务（如kafka、kestrel和jms），有一些喷口实现可以做到这一点

我没有太多的经验，无论是风暴或Kafka/红隼或cep，总的来说，但我正在寻找一个类似的解决方案-推动风暴喷口。在事件源和风暴集群之间使用负载均衡器怎么样？对于我将syslog消息从rsyslog推送到storm的用例，负载平衡器可以跟踪哪些storm节点正在运行侦听端口，哪些节点已关闭，还可以根据不同的参数分配传入的负载。我不太倾向于在源和喷口之间引入另一层，比如消息总线。
编辑：我读了你的博客，总结一下，如果一个监听口的唯一问题是一个消息源如何找到它，那么一个消息总线可能是错误的答案。基于简单的网络状态或更高的应用程序级逻辑，有更简单/更好的解决方案在接收器处引导网络流量。但是，如果你想使用所有额外的消息总线特性，那么Kafka/红隼显然是不错的选择。

这不是storm的典型用法，显然不能将同一台机器上的多个喷口示例绑定到同一个端口。在分布式设置中，最好存储api的当前ip地址和端口，例如存储到zookeeper，然后存储到将请求转发到api的均衡器。
下面是一个在storm上使用简单rest api的项目：
https://github.com/timjstewart/restexpress-storm