最近用 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('node@ip') 去连另外一个节点，回传 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 其实蛮不错 的，利用内建机制也可以做出简单的恢复机制。 --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 36.236.18.3 ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/PLT/M.1457543243.A.5EF.html 这一段时间有稍微看了一下 Elixir，其实熟 Erlang 就会发现两 者几乎相同，上手很快，但细节上还是有差异，然後那个 mix 真 的蛮让人心动的，不过 Elixir 在定义 module 这块上，我看过感 觉不太习惯。 以後有机会再试试看 Elixir 跟 phoenix。 ※ 编辑: drm343 (36.236.16.12), 03/21/2016 13:36:36