我没有大量使用 heroku 的经验，更不用说 phoenix，所以这可能是一个愚蠢的问题……但我想确保我在托管方面做出了一个好的选择 :)
据我了解，扩展 phoenix 的方式是添加另一台服务器、启动另一个节点并连接它们，然后让 BEAM / OTP 发挥其魔力来处理工作负载平衡。在 heroku 上，dynos 不能真正通过本地网络一起交谈，据我所知，这是 BEAM 需要集群的东西。因此，添加 dynos 将导致更“传统”的扩展模型，其中您有一个外部负载均衡器平衡未连接节点之间的连接，数据库处于共享状态。
我的问题是这会产生多大的影响？当您达到严重的负载/规模水平时，这是否只是一个问题，还是意味着在基础设施上花费更多的钱是必要的？
【问题讨论】：
标签： heroku scalability elixir phoenix-framework
您将在支持集群的主机上获得最佳性能，但 Phoenix 有一个 PubSub 适配器系统，完全适用于像 heroku 这样的部署： https://github.com/phoenixframework/phoenix_pubsub
一行配置更改和 mix.exs deps 条目，您将通过我们的 Redis 适配器在 heroku 上拥有多节点通道。
【讨论】：
这是一个非常开放的问题，所以我确信我的回答不会全面。
在您的情况下，最重要的问题是：我会在凤凰城使用频道吗？
如果您使用普通的旧 HTTP，它可能大部分是无状态的。有很多方法可以模拟有状态连接，例如在 cookie 中存储会话。归根结底，您的后端服务器是否相互连接并不重要，因为它们每个都在进行独立的计算。您的负载均衡器可以随机选择任何服务器，并且它将始终有效。 http 的这个很酷的特性使这个协议能够很好地扩展。在这种情况下，你绝对可以使用 Heroku，它会很好用。
如果您使用 Phoenix 频道，事情就会变得复杂。您仍然希望能够连接到任何服务器，但您可能会实时向其他用户发送消息，并且他们可以连接到其他服务器。 Phoenix 通过使用 BEAM 进行集群为您解决了这个问题，这在 Heroku 上会很困难。甚至不可能。
总结：这不是小规模/大规模的问题。这是一个特征问题。扩展通道需要集群，而扩展普通的旧 HTTP 则不需要。
【讨论】：