Erlang Hot Code加载不广泛使用？

Question

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

视频中有一部分是伯纳德说除了爱立信之外没有大的Erlang项目使用热码加载，因为很难保证事情能够奏效。它在minute 29附近。

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

Answer 1

事实并非如此。每个Erlang用户都以这种或那种方式使用热代码加载 - 无论是开发，测试，故障排除，一次性修复还是全面部署。这是Erlang的主要优势之一。也很独特。

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

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

其他人，如爱立信，在对明确的版本和补丁进行严格测试后，使用企业级部署和热代码加载。这里的目标是在不使用备用容量和排放和转移负载的特殊程序的情况下进行升级。在操作上，这可能比重启更简单，更有效，但测试可能更昂贵。

Answer 2

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

赞成使用它：

• 在开发过程中确保快速反馈循环显然非常有用。我总是使用一个开放的shell开发，并使用函数自动加载代码作为编译。
• 在极少数情况下，您需要实现具有高可用性要求的单一应用程序，它基本上是唯一的选择

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

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

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

等

除此之外，你正在运行一个具有长期生存状态的长生活服务器，这远非理想。

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