Erlang Hot Code Loading 没有被广泛使用？答案

【问题标题】：Erlang Hot Code Loading not widely used?Erlang Hot Code Loading 没有被广泛使用？
【发布时间】：2015-09-13 20:49:15
【问题描述】：

我刚刚从 LinuxConf.au 看到 this 2012 video 关于生产中的 Erlang。

Bernard 在视频中有一段说，除了 Ericsson 之外，没有大型 Erlang 项目使用热代码加载，因为很难保证事情会奏效。它在minute 29 附近。

这仍然是真的吗？是否有工具可以帮助测试热代码加载或使其变得更容易？

【问题讨论】：

Relups：除非你一开始就考虑到这种情况，否则很难做到正确（至少有一半是开发文档以及与可执行代码并行的规范）。 热代码加载：如果您做任何处理实时用户数据的事情（想想“游戏/聊天/业务应用程序/peer-[anything] 服务”），它就太有用了，不容忽视。对于此类大规模并发服务，“无热加载”与“热加载”在开发人员术语中类似于“等待巨大的 C++ 项目编译后才能测试更改”与“在 Python shell 中测试想法” "。

标签： erlang

【解决方案1】：

这不是真的。每个 Erlang 用户都以一种或另一种方式使用热代码加载来发挥他的优势——无论是用于开发、测试、故障排除、一次性修复还是全面部署。这是 Erlang 的主要优势之一。也比较独特。

例如，最大的 Erlang 用户之一 WhatsApp 几乎所有代码推送都依赖热代码加载。

我曾亲自处理过热代码加载，在这些场景中，每个更改都得到了很好的理解，并且通常由进行更改的同一个人执行。它工作得非常好，优秀的工程师在这方面没有任何问题。说到工具，使用l(...). 从Erlang shell 一个一个地加载模块，或者使用l(). 一次加载所有模块（参见here）就可以了。有些人更喜欢基于发布的工具，例如relx。

其他公司（如爱立信）在对明确的版本和补丁进行严格测试后，使用带有热代码加载的企业风格部署。此处的目标是在不使用备用容量和排空和转移负载的特殊程序的情况下进行升级。从操作上讲，这可能比重新启动更简单、更有效，但测试成本可能更高。

【讨论】：

+1 在“开发、测试、故障排除、一次性修复”位上。这些案例尤其有用。虽然我没有任何定期进行热更新的生产系统，但我也没有任何不会每天进行多次热代码更改的开发或测试系统——它非常有用。真正的 relups：（几乎）从不；热代码加载：总是和不断地。

【解决方案2】：

很难知道它是广泛使用还是很少使用的功能。现在有很多 Erlang 系统。但是，我可以想到为什么以及为什么不使用它的原因，因为我使用机器人选项已经有一段时间了。

赞成使用它：

在开发过程中确保快速反馈周期显然非常有用。我总是使用开放的 shell 进行开发，并具有在编译时自动加载代码的功能。
在极少数情况下，您需要实现具有高可用性要求的单体应用程序，这基本上是唯一的选择

正如演示文稿所述，不使用它的主要原因是：它很难。即使您设法准确了解它的工作原理（这不是最难的部分）。

在我看来，这不仅仅是工具的问题，而是因为现在您的代码是系统可变运行状态的一部分，您会遇到很多内在的复杂性。您基本上最终拥有一个可以改变行为的长期运行系统，因此您将这些添加到您已经遇到的问题中：

您不再确定重新启动系统不会从根本上改变行为。因此，您可能需要特别注意确保您加载的任何代码也写入磁盘。
更改模块的工作方式（即加载新代码）非常棘手，除非 a) 您永远不会破坏兼容性，b) 您以某种方式弄清楚模块应该更改的顺序，或者 c) 您假设可能发生的最坏情况是由于未定义的函数、函数或 case 子句等导致的一些崩溃，并希望最好（实际最糟糕的是当新旧模块以意想不到的方式交互时，而您还没有完成加载所有新模块和实际运行一些不可能逻辑）。
在加载新代码时，您几乎可以肯定最终会终止某些运行旧代码的进程。也许你的主管会帮助你，也许不会。无论如何，这可能会非常令人困惑且难以调试。
正如演示文稿所述，测试非常困难（如果不是不可能的话）。

等等

除此之外，您正在运行一个具有长寿命状态的长寿命服务器，这远非理想。

所以我的建议始终是，如果您可以摆脱分布式应用程序和滚动升级，那么您应该这样做。该选项更容易处理，并且根据我的经验，整体表现更好。

【讨论】：

平心而论，“运行具有长寿命状态的长寿命服务器”正是 Erlang 最初设计的问题类型。此外，滚动升级成为某些应用程序的简单选择，这正是因为 L2 和 L3 路由器/交换机/负载平衡器在九个九的可用性下保持实时状态，并且很少因维护而停止服务。在电信领域，在许多情况下，没有多少备用容量，迁移数百万个实时连接可能不切实际和/或比在此类系统上进行实时升级更难。
是的，Erlang 的热代码加载就是为此而设计的，并且确实以一种非常独特的方式解决了这个问题，这使得 Erlang 在这些场景中成为一个强大的工具。对于当今大多数生产 Erlang 环境来说，热代码加载是否具有优势？我不这么认为。仅仅因为 Erlang 可以进行热代码加载并不意味着您应该这样做。我的全部观点是维护这样的系统本质上是非常困难的，所以除非绝对需要，否则应该避免去那里。