我对 Erlang 编程理念的理解：以分布式架构师的角度写代码。

函数式编程

Erlang 里面的函数是数学里面的函数：必须有返回值。只要是函数必然有返回值，函数是一个过程，以英文的句号为函数结束符。函数结束之前的表达式就是该函数的返回值。所以这也是在 Erlang 里面的函数不会看到任何 return 语句的原因。 C++ 等其他语言的函数和函数之前可以通过共享变量来实现消息传递。 Erlang 里面的函数不可以，消息的传递通过函数的传入和传出。也只是为什么 Erlang 号称天生之处并行处理的原因，因为他们不共享变量，也就不需要加锁。

很多人听到函数式编程都会觉得高大上或者晦涩难懂。因为函数是编程没有 for 循环语句，但是在我看来，关键在于会使用【列表推倒】和【尾递归】来进行循环遍历。说到函数式编程就会拿快速排序说事，下面这个示例是 Erlang 版本的快速排序：

-module(sort).    -export([qsort/1]).    qsort([]) -> [];  qsort([Pivot | T]) ->      qsort([X || X <- T, X < Pivot]           ++ [Pivot] ++           qsort([X || X <- T, X >= Pivot]).

非常简洁，[Pivot | T] 就是拿列表的第一个元素当快排中的 Pivot 。

[X || X <- T, X < Pivot]

上式就是【列表推导】，含义就是找出列表 T 中所有元素小于 Pivot 中的元素组成一个新的列表。不过，这个例子显然性能不高，只是一个示例。

很多人一直在鼓吹函数式语言马上就要迎来朝阳，但是在我看来，函数式编程永远只能是小众语言，这就像当年的 lisp machine ，被鼓吹的天花乱坠还是夭折了。现在主流的计算机架构都是冯诺依曼体系的，并不是最适合函数式语言的生存土壤。

一切都是常量

没有变量，也就没有通过变量共享状态导致的资源竞争，也就不需要加锁。任何状态的变化都是通过函数的输入输出来进行改变，轻量级进程的状态变化也是靠消息传递（函数的输入输出）来实现。这也是为什么有人说函数式编程适合高并发的原因，因为他们没有变量，一切都是常量。

轻量进程

Erlang 里面有 spawn 函数，可以快速的创建一个 process ，这里的 process 不是操作系统的进程，而是 Erlang 自己的轻量进程。 Erlang 轻量到超乎你想象，构建 kv 数据库的时候，甚至可以对不同的 key 分配给不同的进程。而且进程的表示单位是 Pid ，只要知道进程的 Pid，哪怕该进程是在别的机器上面，都可以很轻易的发送给它。原因是 Erlang 的【天生自带RPC通信】和【自带端口映射】

天生自带RPC通信

ToPid ! Data

ToPid 是接受方进程的id ， Data 可以是 Erlang 的任何类型，比如

Pid ! {name, "yanyiwu.com"}.

也就是可以直接把任何数据结构当成消息发送，天生自带 RPC 通信。（虽然本来 RPC 的含义是“远程过程调用”，不过其实反正就是帮你序列化了数据结构，Erlang 的 ! 操作符也是如此。）

进程端口映射

节点之间发消息在代码里面的表示也还是

ToPid ! Data

也就是在写代码的时候，根本不用考虑该进程是在哪台机器上面，无论是本 Erlang 进程(这里的进程是操作系统级别的进程，不是 Erlang 的轻量进程) 内，还是其他机器的进程，都不用管。这是因为有 epmd 的存在。

Epmd是Erlang Port Mapper Daemon的缩写，在Erlang集群中相当于dns的作用，供给节点名称到端口的查询办事，epmd绑定在总所周知的4369端口上。

有了 epmd ，写分布式程序就好像写单机程序一样简单。

严密的模块化管理

Erlang 的模块类似 C++ 中的 namespace(命名空间)，但是比命名空间更利于高效的软件工程管理。

在 Erlang 项目源码中处处可见如下代码。

-module(my_app).  -export([start/2, stop/1]).

-module 指明模块名，-export 指明导出的函数。未被导出的函数都无法被外界调用。从软件工程上看的话，这样使得模块功能和使用方法更加清晰。使用者只需要关心如何 -export 里面的函数即可。相比较之下 C++ 对这方面特别不规范，而 Java 通过对类声明为 public class 指明可以被外界使用,Node.js 也是使用 export 来显示声明可以被外界使用的函数。

行为模式

-module(ecomet_app).    -behaviour(application).    %% comment: Application callbacks  -export([start/2, stop/1]).  -behavior(application).

Erlang/otp 里面的【行为模式】概念等价于 OOP 里面的接口概念。上面代码示例的意思就是该模块(ecomet_app)遵守的行为模式是(application)。刚行为模式需要实现的两个接口函数就是 -export([start/2, stop/1]). 。

另一个示例如下是遵守监督者(supervisor)行为模式，实现的一个接口函数是 -export([init/1]). 。

-module(ecomet_sup).    -behaviour(supervisor).    %% Supervisor callbacks  -export([init/1]).

监督者机制

Erlang/otp 的天生分布式特性在监督机制里面体现的很好，每一个 otp 应用启动的时候，都是启动监督者(supervisor)和工作者(worker)。他们的关系是树形结构，每个工作者的上级都会有监督者，每个监督者的上级也可能有监督者。当工作者异常退出的时候，监督者会根据相应的参数决定是否对工作者进行重启。如果重启失败的话监督者也会退出，而更加上层的监督者收到信号后会对他们进行重启等处理。这个监督者机制非常好理解，其实就是 OOP 编程里面的 try ... catch 异常处理机制。当出现异常的时候一层一层的往上抛出，直到有人重启。

otp平台

Erlang 最强大的地方也是最让我感觉难学的地方，就是它的 otp 平台。各种行为模式，让我感觉就像多年以前学习 MFC 的时候，感觉很强大，但是却总是感觉自己被按死在一条特定的轨道上面奔跑，有种不自由的疲惫感。

代码热切换

热切换也叫热升级，大部分情况下，如果需要对 C++/Java 程序进程版本升级，则需要重启进程。 Erlang 支持热切换的意思就是可以在运行的时候进行代码升级。升级过程不影响进程的运行，而且在过渡阶段新旧版本还可以共存。是不是碉堡了。这个功能对于那些需要 7x24 高可用的服务来说简直就是爽爆了。

Erlang 进程本身可以通过一个类似“后门”的控制台 erl 来实时的查看状态，甚至直接使用控制台来修改配置等，非常方便，这对于大部分其他语言来说，简直就是黑魔法般神奇的存在。

典型缺点

• 文档太少，出现问题搜索出来的答案也少。
• Erlang 人才稀缺，招聘不易。
• 动态语言最典型的就是调试不易。
• 上手门槛较高。

最后，我只是 Erlang 的入门初学者，因为工作中需要使用 ejabberd (Erlang 的开源项目)，从而学习了 Erlang ，欠缺实战经验，所以这篇文章标题起为 【Erlang初体验】。

原文地址：http://yanyiwu.com/work/2014/11/26/erlang-otp-experience.html