在heroku上攀登凤凰城

我对heroku没有太多的经验，对phoenix更是如此，所以这可能是一个愚蠢的问题。。。但我想确保我在主机上做了一个很好的选择：）

据我所知，扩展phoenix的方式是添加另一台服务器，启动另一个节点，并将它们连接起来，然后让BEAM/OTP发挥其魔力来处理工作负载平衡。在heroku上，dynos无法通过本地网络进行真正的交谈，据我所知，这是BEAM集群所需要的。所以，添加dynos将产生一个更“传统”的扩展模型，在这个模型中，您有一个外部负载平衡器来平衡未连接节点之间的连接，而数据库是共享状态

---

我的问题是这会产生多大的影响？这仅仅是当您达到严重的负载/规模水平时的一个问题，还是意味着需要在基础设施上投入更多的资金？

这是一个非常开放的问题，所以我相信我的答案不会很全面

在你的情况下，最重要的问题是：我会使用凤凰频道吗

如果您使用普通的旧HTTP，它可能大部分是无状态的。有很多方法可以模拟有状态连接，比如在cookie中存储会话。一天结束时，后端服务器是否相互连接并不重要，因为它们每个都在进行独立的计算。您的负载平衡器可以随机选择任何服务器，它将始终工作。http的这一酷特性使该协议能够很好地扩展。在这个场景中，你肯定可以使用Heroku，它将非常有效

如果你使用凤凰频道，事情会变得复杂。您仍然希望能够连接到任何服务器，但您可能会实时向其他用户发送消息，并且他们可以连接到其他服务器。Phoenix通过使用BEAM进行集群为您解决了这个问题，这对Heroku来说很困难。甚至不可能

---

总而言之：这不是一个小规模/大规模的问题。这是一个特征问题。扩展通道需要群集，而扩展普通的旧HTTP则不需要群集。

在支持群集的主机上，您将获得最佳性能，但Phoenix有一个PubSub适配器系统，完全适用于heroku：

---

一行配置更改和mix.exs deps条目，您将通过我们的Redis适配器在heroku上拥有多节点频道。

为每个dyno实例化Phoenix应用程序的成本不高（基本上就是这样的情况）？即使是一个简单的旧HTTP，它也不是一个很大的成本。如果您比较类似的Phoenix和Rails应用程序，Phoenix应该具有更低的内存和CPU占用。因此，如果您在一个dyno上耗尽了资源，只需旋转另一个dyno。我认为这也是一件可以缓解的事情，感谢您对一个不太好的问题给出了很好的答案：）-在Phoenix 1.2中，PubSub默认设置了PG2适配器；有没有理由在Heroku的当前默认版本上使用Redis？谢谢