[Erlang危机](1.3)OTP应用

原创文章，转载请注明出处：服务器非业余研究http://blog.csdn.net/erlib 作者Sunface

OTP Applications

Library Applications

Library applications will usually have modules named appname _something, and one module named appname . This will usually be the interface module that’s central to the library and contains a quick way into most of the functionality provided.

  Applications库通常会由一些叫appname_XXX和一个叫appname的模块名（behaviour）组成，他们通常是连接libary核心的接口模块，并且包含相应的函数接口。

By looking at the source of the module, you can figure out how it works with little effort: If the module adheres to any given behaviour (gen_server, gen_fsm, etc.), you’re most likely expected to start a process under one of your own supervisors and call it that way.

  通过看这些模块的源代码，就能轻松理解behaviour(gen_server,gen_fsm等)是怎么工作的。这其中你最有可能遇到的问题是：在监控进程(supervisors)下创建一个工作进程(worker)。

If no behaviour is included, then you probably have a functional, stateless library on your hands. For this case, the module’s exported functions should give you a quick way to understand its purpose.

  如果在模块中没有include 任何behaviour, 那模块很可能是一个函数库文件，对于这种情况，这个模块导出的函数是为了提供外部接口和理解模块的功能。

   

Regular Applications

Dependencies（依赖库）

All applications have dependencies⁵, and these dependencies will have their own dependencies. OTP applications usually share no state between them, so it’s possible to know what bits of code depend on what other bits of code by looking at the app file only, assuming the developer wrote them in a mostly correct manner.
Figure 1.1 shows a diagram that can be generated from looking at app files to help understand the structure of OTP applications.

  所有的applications都有依赖项(dependencies),这些被依赖的项也还有自己的依赖项⁵。OTP applications之间通常是不共享状态的，所以你应该通过app文件获知各块代码之间的依赖关系，当然首先得假定这个application是开发者用正确标准的方式写出来。
  Figure 1.1 展示了一个由各个app文件之间的依赖关系生成的图表，可以帮助理解OTP applications的结构.

Using such a hierarchy and looking at each application’s short description might be helpful to draw a rough, general map of where everything is located. To generate a similar diagram, find recon’s script directory and call escript script/app_deps.erl⁶. Similar

 使用这种层次结构并且查看每个applications的简明描述，就能画出一个粗略的，但包含所有关键元素的图表。你也可以使用recon脚本：调用escript script/app_deps.erl 来生成类似的图表⁶。

Figure 1.1: Dependency graph of riak_cs, Basho’s open source cloud library. The graph ignores dependencies on common applications like kernel and stdlib. Ovals are applications, rectangles are library applications.

Figure1.1:riak_cs系统(Boaho开源云代码库)的各个依赖项图示，本图忽略了像kernel和stdlib类等常用的依赖application， 长方形表示application库.

hierarchies can be found using the observer ⁷ application, but for individual supervision trees. Put together, you may get an easy way to find out what does what in the code base.

  软件的层次关系还可以使用observer ⁷ application来查看，但只能查看相对独立的supervisior树。然后把上面所说的所有方法汇总，你就可以轻松地深入研究代码。

 

[2] A build system generates the final file that goes in ebin. Note that in these cases, many src/

.app.src files do not specify modules and let the build system take care of it.

[3] In some cases, the supervisor specifies no children: they will either be started dynamically by some function of the API or in a start phase of the application, or the supervisor is only there to allow OTP environment variables (in the env tuple of the app file) to be loaded.
[4] Some developers will use one_for_one supervisors when rest_for_one is more appropriate. They require strict ordering to boot correctly, but forget about said order when restarting or if a predecessor dies.

[5]At the very least on the kernel and stdlib applications
[6]This script depends on graphviz
[7]http://www.erlang.org/doc/apps/observer/observer_ug.html

[注2]：最终会用构建系统生成.app文件放到ebin/下,而且大部分的src/.app.src不会列模块列表，构建系统会自动加上去的。

[注3]：在某些情况下，监控进程不会有这些详细信息，他们会被用API动态的创建出来;或者从OTP的环境变量中获得app file加载。
[注4]：有些开发者在使用one_for_one的策略，但是实际上rest_for_one更合适。他们在进程死亡或重启时都需要遵守一定严格顺序。

[注5]：至少会依赖kernel和stdlib.
[注6]:此脚本依赖于画图工具(graphviz).
[注7]：http://www.erlang.org/doc/apps/observer/observer_ug.html