erlang杂记八---使用otp框架启动应用

续：这两天重新读<erlang/otp并发编程实战>，终于把之前头晕的一点东西看懂了。。

一.应用的组织形式

经典的组织形式：应用名+ 版本号下有：doc，ebin，include，priv，src。应用名+版本号的形式是为了管理方便->代码升级。

二.元数据

应用元数据文件用来告诉otp如何启动应用，以及该应用应该如何与系统中的其他应用相融合。主要的描述参数包括：description, vsn, modules, registered, application, mod.

通用配置信息不要写在这个配置文件中，而应该放到正规的配置文件中。

三.应用行为模式

每个主动应用都配有一个application行为模式的实现模块。该模块用于实现系统启动逻辑。它至少负责根监督者的启动，该监督者将成为应用中其他所有应用的鼻祖。

需要实现的内容应该有start和stop

start(_Type, _StartArgs) ->
cast xx_sup:start_link() of
{ok, pid} ->
{ok, pid};
Other -> {error, Other}
end.
stop(_State) ->
ok.

其中start内可以添加其他需要启动的内容，如启动ets

四.应用监督者

监督者负责启动otp应用进程，并负责在必要时重启进程。

监督者实现需要实现的内容有start_link和init

start_link()->
supervisor:start_link({local, ?SERVER}, ?MODULE, []).
init([]) ->
Server = {xx_server, {xx_server, start_link, []}, permanent, 2000, worker, [xx_server]},
Children = [Server],
RestartStratety = {one_for_one, 0,1},
{ok, {RestartStrategy, Children}}.

start_link是由元数据设置的启动入口，该入口会调用supervisor的start_link回调。

init设置初始化子进程的方式。RestartStrategy为重启策略。Server是启动的子进程的方法，中间的元组描述了启动调用的MFA。permannent表示需要重启，worker表示启动的是一个worker，而不是另一个supervisor，最后列出的是该进程所依赖的模块，仅用于代码热升级时告知系统升级顺序。

五.server应用

gen_server主要实现了很多回调，编写应用的时候，把每个消息都按照实际需求分别实现一个handle_call或者handle_cast就可以了。

code_change如果需要实现代码热升级的话，使用M:F，不要直接使用F，指定了M，当代码更新之后，F也会对应更新，否则F仍然是原来的F。

六.对外api

对外api将实现的内部细节屏蔽起来。使用逻辑调用实现过的方法就可以了。注意写保护增强容错~