最近用 erlang 寫了一個簡單的 TCP server，功能很簡單就不
詳述了，其實寫 erlang 我自己有三點感受，第一點是我自己很
少用 try catch 這個語法；第二件事情，是整個 erlang/OTP
幾乎都是用 gen 或 gen_server 這個模組寫的；第三點，永遠
要有 plan B，在談這點時，我會介紹如何用 erlang 寫一個簡
單的監控程式來恢復這個 TCP server。
在 erlang 中，只要不是再起不能這種嚴重的錯誤，基本上執行
錯誤應該都會出現類似 {error,Reason} 這樣的計算結果，利用
這種結果，我可以故意在回傳值寫上 {ok, Result} 利用內建的
pattern match 來找出自己的邏輯錯誤，加上錯誤格式幾乎都是
上述說的那種，可以直接用 case of 的方式處理，我整個程式
中只有用到一次 try catch: 為了提供兩種不同格式的字串比對
方式，先用完整字串比對第一種格式，比對失敗才跑第二種，類
似下面這樣的處理方式。
handle_cast(string()) -> ok | {error, Reason}.
handle_cast("ping this machine") -> do_something.
handle_info([string()]) -> ok | {error, Reason}.
handle_info(["give", User, Something]) -> User! Something.
這部份如果直接用 case of 的方式處理，可能在 handle_cast
那邊就噴出 pattern not match 之類的錯誤，而讓連線斷掉或是
程式整個掛掉，所以必須用 try catch 處理，雖說是個人風格，
但其實寫 erlang 真的很少用到 try catch 就是。
關於第二點，erlang/OTP 其實才是整套 erlang 最關鍵的點，沒
有這個，erlang 真的沒辦法自稱 concurrency 最佳選擇，它的基
本想法就是把 concurrency 中通用的抽出來，不通用的讓使用者
自己寫，所以也可以用 callback module 這樣的方式來理解。
然後 erlang/OTP 其實只要會 gen_server，幾乎就能自稱懂 OTP
了，因為其他幾個 OTP module 幾乎都是用 gen_server 或 gen
這兩個 module 寫出來的，連 supervisor 這個監控模組都是。
然後我自己就寫了兩個自訂 OTP module，功能跟使用上沒那麼通
用，有針對自己的問題去寫，想來 erlang/OTP 其實有點通用過了
頭.....
第三點是 plan B，其實正確來說是指「erlang 所謂的容錯」。
翻開 erlang 相關的資料，常常會見到 NASA 被 erlang 使用者
抓出來做示範，這不是說 NASA 有用 erlang 來開發程式，而是
NASA 用 C 開發程式時，採用的觀念跟 erlang 幾乎是一樣的，
也就是「至少一隻監控程式可以恢復另一個程式」。
那我原本是把監控的部份做在同一個節點上，但後來拿掉改成一
台機器跑兩個節點，需求從原本「不同機器互相監控」變成「自
己玩自己的」。
這個 TCP server 很簡單，沒有太複雜的需求，因此監控跟恢復
TCP server 很相對很簡單，只要確保 TCP 可以正常運作即可，
直覺上就是監控程式自己連過去，只要斷線就重新連線確認到底
還有沒有辦法連上，沒辦法就重開 TCP server ，有辦法就繼續
正常運作。
關於重開 TCP server ，這邊還可以細分兩類，第一類是 OS 層
級的重開，第二類是 erlang application 層級的重開，關於 OS
層級的重開就不多提了，第二類會用到 erlang 內建的 rpc 跟
cluster 的功能，對，erlang 有內建 cluster 的功能，而且使
用上還簡單到我寫出來連 P 幣都騙不了的程度，只要確保兩個節
點的 cookie 相同，從其中一台使用 net_adm:ping('[email protected]')
去連另外一個節點，回傳 pong 就會形成 cluster，回傳 pang 就
代表失敗，沒了，建立 cluster 真的就這樣.........
好啦，其實建立 cluster 還是要注意一些事情啦，如果你有用過
erlang 寫的 Riak、ejabberd、CouchDB 之類工具，建立 cluster
如果發現變成兩個以上不同的 cluster，代表這兩個 cluster 沒
有互 ping，所以被切開了，只要從任何一台機器去 ping 另一個
cluster 中的任意一台機器，兩個 cluster 就會連成一個。
erlang 中對於 cluster 的處理是每台機器有各自的節點紀錄，過
一段時間時間就自己去 ping 全部節點，沒回應就把它刪掉，有回
應就保留，然後這個功能基本上是做在 erlang 或 net_kernel 這
兩個 module 裡面，詳細我就沒看了。
使用上雖然很方便，但想想那個指數級成長的 ping，其實頗可怕，
使用上真的要注意就是。
當兩個節點連起來後，使用 rpc:call 或 rpc:cast 這兩個函數，
就可以讓 remote 節點執行某些程式了，application restart 這
種功能就一定要用 rpc 的方式跑，至於 call 跟 cast，一個是寄
情書後站在對方前等對方回應，另一個寄完情書就跑走，過一段時
間回來問對方回應。
明明打了一大串，感覺自己發了一整篇的廢文...XD
總之如果是要建立簡單、小型的 cluster，用 erlang 其實蠻不錯
的，利用內建機制也可以做出簡單的恢復機制。