我们现在正在重构我们用 Vert.x 编写的消息传递应用程序。应用程序处理来自用户的传入消息。最初，它被实现为有一个单独的 Verticle 实例来监听事件总线中的一个队列并处理所有传入的消息。
我们正在考虑做的是重构它，使它的工作方式有点类似于演员模型：我们为每个活跃用户部署一个 Verticle 的实例，并让它监听一个用户特定的队列。通过这种方式，verticle 实例可以维护用户特定的状态，并且消息处理的并行化变得更加容易。
然而，问题在于，这会导致部署大量的 Verticle（30k - 50k 并行）和事件总线中的大量队列。而且我们还需要手动维护 verticles（取消部署未使用的 verticles，并在有来自新用户的消息时部署它们）。
问题是 - 这种 actor 风格的架构是否适用于 vert.x，它能否同时处理大量部署的 verticles 和 eventbus 队列？
【问题讨论】：
这里有一个主要的修正 - EventBus 是一个单一的队列。所以，你不会有“大量的队列”。将只有一个。您将在一个队列中拥有大量地址。
但是这个数字有这么大吗？那么，一个 50K 元素的 HashMap 算不算巨大呢？可能不是，至少在键方面。现在请注意，这仅适用于非集群模式下的 Vert.x。 Clustered Vert.x 是不同的（不过仍然应该可以工作）。
现在拥有这些verticles是另一回事。每个verticle都是一个单独的对象，如果你打算在里面存储一些数据，它会更大。但是，如果您能买得起具有不错 RAM (16GB+) 的机器，它应该可以正常工作。
不过，在这个解决方案中，我关心的是您计划按需部署 Verticle，然后取消部署它们。它确实会产生延迟，因此您的用户在发送第一条消息时会体验到性能下降。
【讨论】：
你所谓的“演员风格”并不意味着你必须为每个用户膨胀一个新的 Verticle 实例。如果这样做，您将获得一个具有 98% 冗余的系统。
为每个用户注册一个事件总线地址并使用某种持久存储来跟踪它们就足够了。这种存储可以是任何用于长期持久性的 DB，也可以是集群范围内的 SharedMap 用于短期，或两者的组合。
也许您甚至不需要按用户分配地址的方案。当用户通过某种EventBusBridge 不断地连接到您的系统时，这样的方案很好。如果不是这种情况，您可以为所有用户注册一个事件总线地址并根据有效负载处理消息。
【讨论】：