当遇到一个你不熟悉的问题领域时，一开始就试图构建一个“通用”或“可扩展”的解决方案是错误的。你对问题领域的理解还不够深入，无法预测未来的需求。你会将不需要通用的东西做成通用的，增加了复杂性并浪费了时间。 更好的做法是就直接上手解决手头的问题。这让你能够完成需要做的事情，避免无用功。在你动手实践的过程中，你会越来越了解问题空间的复杂性。 Storm 的“求实现”阶段，是为期一年使用队列和工作进程（workers）来构建流处理系统的实践。我们学会了使用“ack”协议来保证数据处理。我们学会了通过队列和工作进程的集群来扩展我们的实时计算。我们了解到有时你需要以不同的方式对消息流进行分区，有时是随机的，有时使用哈希/取模技术，以确保同一个实体总是流向同一个工作进程。 我们甚至不知道自己正处于“求实现”的阶段。我们只是专注于构建我们的产品。然而，队列和工作进程系统的痛苦很快变得严重起来。扩展队列和工作进程系统非常繁琐，而且容错性远未达到我们的期望。很明显，队列和工作进程范式并未处于正确的抽象层次，因为我们大部分代码都与路由消息和序列化有关，而不是我们关心的实际业务逻辑。 与此同时，开发我们的产品促使我们在“实时计算”问题领域发现了新的用例。我们为产品构建了一个功能，用于计算一个 URL 在 Twitter 上的触达人数（Reach）。触达人数是指在 Twitter 上接触到某个 URL 的独立用户数量。这是一个困难的计算，单次计算可能就需要数百次数据库调用和数千万次的展示（impressions）来进行去重计算。我们最初在单台机器上运行的实现，对于难处理的 URL 可能需要超过一分钟，很明显我们需要某种分布式系统来并行化计算，使其变得快速。 催生了 Storm 的一个关键认识是，“触达人数问题”和“流处理”问题可以通过一个简单的抽象来统一。