問題描述
12.19號，在對erlang應用做熱升級的時候，升級失敗，出錯信息如下：
<pre><code>
escript: exception error: no match of right hand side value {error, {code_change_failed,<7845.1231.0>,hook_heroes_sup,
225273894003706867532273251651138786370, {'EXIT', {undef,
[{mongo_user_info,init,[],[]}, {hook_heroes_sup,init,1,
[{file,"src/hook_heroes_sup.erl"}, {line,44}]}, {supervisor,code_change,3,
[{file,"supervisor.erl"},{line,607}]}, {gen_server,system_code_change,4,
[{file,"gen_server.erl"},{line,685}]}, {sys,do_change_code,5,
[{file,"sys.erl"},{line,477}]}, {sys,do_cmd,6,[{file,"sys.erl"},{line,405}]}, {sys,handle_system_msg,8,
[{file,"sys.erl"},{line,318}]}, {proc_lib,init_p_do_apply,3,
[{file,"proc_lib.erl"},{line,239}]}]}}}}
</code></pre>
問題分析
出錯信息分析
根據出錯信息來看，主要是mongo_user_info的init方法沒定義，而mongo_user_info的init()方法確實是這次熱升級新加入的方法。
relup文件分析
查看relup文件，重點來看看和這次熱升級失敗有關的三個模塊，這里一定要注意他們的出現的順序。
<pre><code>
{"2.16",
[{"2.15.28",[],
[{load_object_code,{hook_heroes,"2.16",
[...,mongo_index,...,hook_heroes_sup,...,mongo_user_info,...]}},
...
{load,{mongo_index,brutal_purge,brutal_purge}},
...
{suspend,[hook_heroes_sup]},
{load,{hook_heroes_sup,brutal_purge,brutal_purge}},
{code_change,up,[{hook_heroes_sup,[]}]},
{resume,[hook_heroes_sup]},
...
{load,{mongo_user_info,brutal_purge,brutal_purge}},
...
[{"2.15.28",[],[point_of_no_return]}]}.
</code></pre>
2.15.8的hook_heroes_sup和2.16的hook_heroes_sup代碼區別在于
增加了init方法中：
<pre><code>
mongo_index:init()
</code></pre>
mongo_index:init()方法實現如下：
<pre><code>
mongo_user_info:init().
</code></pre>
至此，可以從代碼級別到relup文件理清楚了：mongo_index、hook_heroes_sup、mongo_user_info三個模塊了，其中，hook_heroes_sup的行為模式是super_visor,是應用頂級監控樹。
hook_heroes_sup依賴于mongo_index，mongo_index又依賴于mongo_user_info。
relup文件就是執行熱升級順序的文件，按照官方文檔說明如下：
<pre>
The release upgrade file describes how a release is upgraded in a running system.
</pre>
分析為什么出錯
看relup文件中hook_heroes_sup的操作：
<pre><code>
{suspend,[hook_heroes_sup]},
{load,{hook_heroes_sup,brutal_purge,brutal_purge}},
{code_change,up,[{hook_heroes_sup,[]}]},
{resume,[hook_heroes_sup]},
</code></pre>
首先掛起hook_heroes_sup這個進程，然后把新的hook_heroes_sup代碼load進來，隨后，執行supervisor的code_change方法。查閱源碼
supervisor的code_change方法如下：
<pre><code>
code_change(_, State, _) ->
case (State#state.module):init(State#state.args) of
{ok, {SupFlags, StartSpec}} ->
case catch check_flags(SupFlags) of
ok ->
{Strategy, MaxIntensity, Period} = SupFlags,
update_childspec(State#state{strategy = Strategy,
intensity = MaxIntensity,
period = Period},
StartSpec);
Error ->
{error, Error}
end;
ignore ->
{ok, State};
Error ->
Error
end.
</code></pre>
看出來，當一個supervisor熱升級的時候，會重新執行init()方法。那么問題來了，新的init()方法里面有mongo_index:init()代碼，實際調用了mongo_user_info的init()方法，但是根據relup文件，
<pre><code>
{load,{mongo_user_info,brutal_purge,brutal_purge}},
</code></pre>
這個mongo_user_info的新代碼加載，出現在新hook_heroes_sup加載的后面，自然，執行新的hook_heroes_sup的init()方法，是找不到新mongo_user_info的方法的。所以出錯。
這里說明，rebar生成的relup文件，沒有對這種類型的模塊依賴做檢查。
驗證
- 對relup文件的模塊順序手動進行調整
{load,{mongo_user_info,brutal_purge,brutal_purge}}的代碼順序加載到{suspend,[hook_heroes_sup]}之前，再次對系統從2.15.28到2.16進行熱升級。
升級結果成功 - 反向驗證
再次把mongo_user_info調整到原來的位置，再次對對系統從2.15.28到2.16進行熱升級。仍然出現文章開頭的錯誤 - 正向驗證和反向驗證證明之前的分析是正確的。
深層次原因
從上面的分析，我們可以得到稍微抽象一點的描述，rebar生成熱更新文件的順序造成熱升級失敗問題：
暫且把這種依賴順序稱為"rebar-dead"依賴順序。
- 新增module1,方法f1(),
- f1()依賴于舊模塊的module2的新方法f2()
- 熱更新的時候，會執行module1的f1()。
這樣的依賴順序，rebar生成的relup文件就一定會報錯。因為rebar生成的relup文件把新增的模塊放在前面，修改的模塊放在后面。
至于rebar生成relup文件的過程，和新增模塊、刪除模塊、修改模塊的順序，后面會有詳細分析。
如何避免
避免這類問題對熱生級錯誤的方法有很多，分為代碼、工具、運維三個層面
-
代碼層面
- 避免在應用頂級監控supervisor的init()方法中，出現前面描述的模塊依賴"rebar-dead"依賴順序，因為這樣一定會出錯。
- 方法1:最粗暴的做法，就是永遠不改變supervisor的init()方法，這樣熱升級永遠不會執行init()方法。代碼層面，需要有一個類似于sys_init的函數，來封裝之后可能新加入的代碼；這樣上線后，需要手動執行方法。
- 方法2:新增module1的新方法，不要依賴舊模塊的新接口；(不過這點也許繞不過)
-
工具層面
分為熱升級文件修改和熱升級運行時修改：熱升級文件修改
- 方法1:修改rebar源碼，自己加入依賴順序檢測；有點兒類似于gc中的應用檢測，導致調整.appup文件，是我們想要的順序
熱升級運行修改：
- 方法3:修改release_handler函數，應該可以做到，暫時還沒想出來；
-
運維層面
- 每次熱升級前面，一定要在內網環境先嘗試；
- 使用release_handler:check_install_release()函數，先檢測是否能熱升級成功；
- 如果失敗，人肉檢測
總結：
- 線上問題，直覺很重要--@宋梟_CD
- 需要正反驗證問題，來證實猜想。正所謂：“大膽假設，小心求證”
- 關于熱升級
熱升級對于使用erlang構建的游戲服務端應用來說，非常重要；每一次的熱升級失敗，都必須排查原因。后續肯定還有沒有遇到的問題，還是要仔細分析。
- 關于避免rebar生成有問題熱更新文件的問題
- 工具層面代價比很高，需要深入掌握所有熱升級的每一個細節；代碼層面對于需求來說，也許繞不過；運層最簡單，人工成本最高。需要根據項目的大小、進展以及團隊的人員、技術深度來取舍。
- rebar 3.0也許會解決這樣的問題，期待。
- 這應該算是rebar工具的問題，不算是erlang系統的問題。erlang把生成app_up的文件權利給予了開發者。
