本章涵盖

• 使用 Elixir 工具运行系统
• OTP 发布
• 分析系统行为

您花了很多时间构建一个待办事项系统，现在是时候为生产做好准备了。有几种方法可以启动系统，但基本思路始终相同。您必须编译您的代码以及依赖项。然后，您启动 BEAM 实例，并确保所有编译的工件都在加载路径中。最后，在 BEAM 实例中，您需要启动您的 OTP 应用程序及其依赖项。一旦 OTP 应用程序启动，您可以认为您的系统正在运行。

有多种方法可以实现这一目标，在本章中，我们将重点关注其中两种。首先，我们将探讨如何使用 Elixir 工具，特别是 mix ，来启动系统。然后，我们将讨论 OTP 发布。最后，我将通过提供一些关于如何与运行中的系统进行交互的建议来结束本章和本书，以便您能够检测和分析在运行时不可避免发生的故障和错误。

13.1 使用 Elixir 工具运行系统

无论您使用何种方法启动系统，一些共同原则始终适用。运行系统相当于执行以下操作：

1. 编译所有模块。相应的 .beam 文件必须在磁盘上的某个地方存在（如第 2.7 节所述）。所有运行系统所需的 OTP 应用程序的应用资源 (.app) 文件也适用此规则。
2. 启动 BEAM 实例，并设置负载路径以包含步骤 1 中的所有位置。
3. 启动所有所需的 OTP 应用程序。

可能最简单的方法是依赖标准的 Elixir 工具。这样做很简单，您已经熟悉 mix 、 iex 和 elixir 命令行工具的某些方面。到目前为止，您一直在使用 iex ，它允许您启动系统并与之交互。当您调用 iex -S mix 时，刚才提到的所有步骤都会被执行以启动系统。

在生产环境中运行时，您可能希望在没有启动 iex shell 的情况下将系统作为后台进程启动。为此，您需要通过 mix 和 elixir 命令启动系统。

13.1.1 使用 mix 和 elixir 命令

到目前为止，我们一直在使用 iex -S mix 命令来启动系统。也可以使用 mix run --no-halt 启动系统。该命令启动 BEAM 实例，然后与其依赖项一起启动您的 OTP 应用程序。 --no-halt 选项指示 mix 使 BEAM 实例永远运行：

$ mix run --no-halt          
 
Starting database worker.
Starting database worker.
Starting database worker.
Starting to-do cache.

在没有 iex shell 的情况下启动系统

与 iex -S mix 相比，重要的区别在于 mix run 不会启动交互式 shell。

一个稍微复杂一些的选项是使用 elixir 命令：

$ elixir -S mix run --no-halt
 
Starting database worker.
Starting database worker.
Starting database worker.
Starting to-do cache.

这种方法需要更多的输入，但它允许您在后台运行系统。

通过使用 -detached Erlang 标志，您可以以分离模式启动系统。操作系统进程将与终端分离，并且不会有控制台输出。启动分离系统时，将 BEAM 实例转换为节点也是有用的，这样您可以在需要时与其交互并终止它：

$ elixir --erl "-detached" --sname todo_system@localhost \
    -S mix run --no-halt

这将在后台启动 BEAM 实例。

您可以通过查看系统上存在的 BEAM 节点来检查它是否正在运行：

$ epmd -names
 
epmd: up and running on port 4369 with data:
name todo_system at port 51028                 

节点正在运行。

此时，您的系统正在运行，您可以使用它——例如，通过发出 HTTP 请求来操作待办事项列表。

您可以连接到正在运行的 BEAM 实例并与之交互。可以建立一个远程 shell——类似于与正在运行的 BEAM 实例的终端 shell 会话。特别是，使用 --remsh 选项，您可以启动另一个节点并将其用作 todo_system 节点的 shell：

$ iex --sname debugger@localhost --remsh todo_system@localhost --hidden
iex(todo_system@localhost)1>       

Shell 正在 todo_system 节点上运行。

在这个例子中，您启动了 debugger 节点，但 shell 正在 todo_system 的上下文中运行。您调用的任何函数都将在 todo_system 上被调用。这非常有用，因为您现在可以与正在运行的系统进行交互。BEAM 提供了各种良好的服务，允许您查询系统和单个进程，稍后我们将讨论这些。

注意，您将 debugger 节点设置为隐藏。如第 12 章所述，这意味着 debugger 节点不会出现在 todo_system 上 Node.list （或 Node.list([:this, :visible]) ）的结果中，因此它不会被视为集群的一部分。

要停止正在运行的系统，您可以使用 System.stop 函数 (https://hexdocs.pm/elixir/System.xhtml#stop/1)，该函数以优雅的方式关闭系统。它会关闭所有正在运行的应用程序，然后终止 BEAM 实例：

iex(todo_system@localhost)1> System.stop()

远程 shell 会话处于挂起状态，尝试运行任何其他命令将导致错误：

iex(todo_system@localhost)2>
*** ERROR: Shell process terminated! (^G to start new job) ***

此时，您可以关闭终端并验证正在运行的 BEAM 节点：

$ epmd -names
epmd: up and running on port 4369 with data:

如果您想以编程方式停止一个节点，可以依赖第 12 章中描述的分布式功能。以下是一个快速示例：

if Node.connect(:todo_system@localhost) == true do
  :rpc.call(:todo_system@localhost, System, :stop, [])    
  IO.puts "Node terminated."
else
  IO.puts "Can't connect to a remote node."
end

在远程节点上调用 System.stop

在这里，您连接到远程节点，然后依赖 :rpc.call/4 在那调用 System .stop 。

您可以将代码存储在 stop_node.exs 文件中（.exs 扩展名通常用于基于 Elixir 的脚本）。然后，您可以从命令行运行该脚本：

$ elixir --sname terminator@localhost stop_node.exs

运行脚本会启动一个单独的 BEAM 实例，并在该实例中解释代码。在脚本代码执行完毕后，主机实例将被终止。由于脚本实例需要连接到一个远程节点（您想要终止的节点），您需要给它一个名称，以将 BEAM 实例转变为一个合适的节点。

13.1.2 运行脚本

我到目前为止还没有讨论脚本和工具，但它们值得简单提及。有时，您可能想要构建一个命令行工具，进行一些处理，生成结果，然后停止。最简单的方法是编写一个脚本。

您可以创建一个普通的 Elixir 文件，给它一个 .exs 扩展名以表明它是一个脚本，实现一个或多个模块，并调用一个函数：

defmodule MyTool do
  def run do
    ...
  end
 
  ...
end
 
MyTool.run()   

启动工具

您可以使用 elixir my_script.exs 命令调用脚本。您定义的所有模块将被编译到内存中，任何模块外的所有表达式将被解释。所有操作完成后，脚本将终止。当然，Elixir 脚本只能在安装了正确版本的 Erlang 和 Elixir 的系统上运行。

外部库可以通过 Mix.install 添加 ( https://hexdocs.pm/mix/Mix.xhtml#install/2)。例如，以下脚本使用 Jason 库解析作为命令行参数提供的 JSON 内容：

Mix.install([{:jason, "~> 1.4"}])    
 
input = hd(System.argv())
decoded = Jason.decode!(input)       
 
IO.inspect(decoded)

安装 Jason 依赖项

使用 Jason 库

传递给 Mix.install 的列表遵循与 mix.exs 中使用的依赖列表相同的格式。

让我们试试这个。将上面的代码保存到名为 json_decode.exs 的文件中。然后，执行脚本：

$ elixir json_decode.exs '{"some_key": 42}'
 
Resolving Hex dependencies...    
Resolution completed in 0.011s   
New:                             
  jason 1.4.0                    
* Getting jason (Hex package)    
==> jason                        
Compiling 10 files (.ex)         
Generated jason app              
 
%{"some_key" => 42}              

依赖项安装和编译

脚本输出

当脚本第一次执行时，Mix 会安装依赖项，编译它，并将结果缓存到磁盘。后续的执行将使用缓存版本，因此脚本的运行速度将比第一次运行快得多。

一个 .exs 脚本适合简单的工具，但当代码变得更复杂时，它的效率就不高。在这种情况下，最好使用一个合适的 Mix 项目并构建一个完整的 OTP 应用程序。

但因为你并不是在构建一个持续运行的系统，你还需要在项目中包含一个运行模块——一个进行处理并产生输出的东西：

defmodule MyTool.Runner do
  def run do
    ...
  end
end

然后，您可以使用 mix run -e MyTool.Runner.run 启动该工具。这将启动 OTP 应用程序，调用 MyTool.Runner.run/0 函数，并在函数完成后立即终止。

您还可以将整个工具打包成一个 escript——一个单一的二进制文件，嵌入所有的 .beam 文件、Elixir .beam 文件和启动代码。因此，escript 文件是一个完全编译的跨平台脚本，只需在运行机器上存在 Erlang。有关更多详细信息，请参阅 mix escript.build 文档 ( https://hexdocs.pm/mix/Mix.Tasks.Escript.Build.xhtml)。

一种相似但更有限的选择是 Erlang 存档，这是一个包含已编译二进制文件的 zip 文件。与 escripts 相比，存档的主要好处是它们可以通过 mix archive.install 任务全局安装 (https://hexdocs.pm/mix/Mix.Tasks.Archive.Install.xhtml)。这使得它们非常适合分发系统范围内的 Mix 任务。一个流行的例子是 phx.new 任务，它用于生成一个由 Phoenix Web 框架驱动的新项目。您可以在 https://hexdocs.pm/mix/Mix.Tasks.Archive.Build.xhtml 阅读有关构建存档的更多信息。

13.1.3 为生产编译

如第 11 章所述，有一个构造称为 Mix 环境——一个编译时标识符，允许您有条件地定义代码。默认的 Mix 环境是 dev，表示您正在处理开发。相反，当您使用 mix test 运行测试时，代码是在测试环境中编译的。

您可以使用 Mix 环境有条件地包含代码，以便在开发或测试时方便。例如，您可以依赖 Mix.env/0 函数来定义函数的不同版本。以下是一个简单的示例：

defmodule Todo.Database do
  case Mix.env() do
    :dev ->
      def store(key, data) do ... end
 
    :test ->
      def store(key, data) do ... end
 
    _ ->
      def store(key, data) do ... end
  end
end

注意你如何在模块级别根据 Mix.env/0 的结果进行分支，而不在任何函数内。这是一个编译时构造，这段代码在编译期间运行。 store/2 的最终定义将取决于你用于编译代码的 Mix 环境。在开发环境中，你可能会运行额外的日志记录和基准测试，而在测试环境中，你可能会使用内存存储，例如 ETS。

重要的是要理解 Mix.env/0 仅在编译期间有意义。你绝不应该在运行时依赖它。无论如何，你的代码可能包含这样的条件定义，因此你应该假设在开发环境中编译时你的项目并未完全优化。

要在生产中启动您的系统，您可以将 MIX_ENV 操作系统环境变量设置为相应的值：

$ MIX_ENV=prod elixir -S mix run --no-halt

这导致代码及其所有依赖项的重新编译。所有 .beam 文件都存储在 _build/prod 文件夹中，Mix 确保 BEAM 实例从该文件夹加载文件。

提示 从讨论中应该很明显，默认编译的代码（在开发环境中）并没有经过优化。开发环境提供了更好的开发便利性，但使得代码的性能效率降低。当你决定测量系统在更大负载下的表现时，应该始终在生产环境中编译所有内容。在开发环境中测量可能会给你关于瓶颈的错误指示，你可能会花费精力和时间去优化在生产中根本没有问题的代码。

您现在已经了解了使用 mix 和 elixir 启动系统的基本知识。这个过程很简单，并且很好地融入了您的开发流程。

不过，也有一些严重的缺点。首先，要使用 Mix 启动项目，您需要编译它，这意味着系统源代码必须驻留在主机上。您需要获取所有依赖项并编译它们。因此，您需要在目标主机上安装所有编译所需的工具。这包括 Erlang 和 Elixir、Hex 和 Mix，以及您在 Mix 工作流程中集成的任何其他第三方工具。

此外，如果您在同一台机器上运行多个系统，调和不同系统所需的支持工具的不同版本可能会变得越来越困难。幸运的是，有一种解决方案，即 OTP 版本。