我對 Erlang 編程理念的理解：以分布式架構(gòu)師的角度寫代碼。

函數(shù)式編程

Erlang 里面的函數(shù)是數(shù)學(xué)里面的函數(shù)：必須有返回值。 只要是函數(shù)必然有返回值，函數(shù)是一個(gè)過程，以英文的句號(hào)為函數(shù)結(jié)束符。 函數(shù)結(jié)束之前的表達(dá)式就是該函數(shù)的返回值。 所以這也是在 Erlang 里面的函數(shù)不會(huì)看到任何 return 語句的原因。 C++ 等其他語言的函數(shù)和函數(shù)之前可以通過共享變量來實(shí)現(xiàn)消息傳遞。 Erlang 里面的函數(shù)不可以，消息的傳遞通過函數(shù)的傳入和傳出。 也只是為什么 Erlang 號(hào)稱天生之處并行處理的原因， 因?yàn)樗麄儾还蚕碜兞?，也就不需要加鎖。

很多人聽到函數(shù)式編程都會(huì)覺得高大上或者晦澀難懂。 因?yàn)楹瘮?shù)是編程沒有 for 循環(huán)語句， 但是在我看來，關(guān)鍵在于會(huì)使用【列表推倒】和【尾遞歸】來進(jìn)行循環(huán)遍歷。 說到函數(shù)式編程就會(huì)拿快速排序說事，下面這個(gè)示例是 Erlang 版本的快速排序：

很多人一直在鼓吹函數(shù)式語言馬上就要迎來朝陽， 但是在我看來，函數(shù)式編程永遠(yuǎn)只能是小眾語言， 這就像當(dāng)年的 lisp machine ，被鼓吹的天花亂墜還是夭折了。 現(xiàn)在主流的計(jì)算機(jī)架構(gòu)都是馮諾依曼體系的，并不是最適合函數(shù)式語言的生存土壤。

一切都是常量

沒有變量，也就沒有通過變量共享狀態(tài)導(dǎo)致的資源競爭，也就不需要加鎖。 任何狀態(tài)的變化都是通過函數(shù)的輸入輸出來進(jìn)行改變， 輕量級進(jìn)程的狀態(tài)變化也是靠消息傳遞（函數(shù)的輸入輸出）來實(shí)現(xiàn)。 這也是為什么有人說函數(shù)式編程適合高并發(fā)的原因，因?yàn)樗麄儧]有變量， 一切都是常量。

輕量進(jìn)程

Erlang 里面有 spawn 函數(shù)，可以快速的創(chuàng)建一個(gè) process ， 這里的 process 不是操作系統(tǒng)的進(jìn)程，而是 Erlang 自己的輕量進(jìn)程。 Erlang 輕量到超乎你想象， 構(gòu)建 kv 數(shù)據(jù)庫的時(shí)候，甚至可以對不同的 key 分配給不同的進(jìn)程。 而且進(jìn)程的表示單位是 Pid ，只要知道進(jìn)程的 Pid， 哪怕該進(jìn)程是在別的機(jī)器上面，都可以很輕易的發(fā)送給它。 原因是 Erlang 的【天生自帶RPC通信】和【自帶端口映射】

天生自帶RPC通信

進(jìn)程端口映射

節(jié)點(diǎn)之間發(fā)消息在代碼里面的表示也還是

Epmd是Erlang Port Mapper Daemon的縮寫，在Erlang集群中相當(dāng)于dns的作用，供給節(jié)點(diǎn)名稱到端口的查詢辦事，epmd綁定在總所周知的4369端口上。

有了 epmd ，寫分布式程序就好像寫單機(jī)程序一樣簡單。

嚴(yán)密的模塊化管理

Erlang 的模塊類似 C++ 中的 namespace(命名空間)，但是比命名空間更利于高效的軟件工程管理。

在 Erlang 項(xiàng)目源碼中處處可見如下代碼。

-module 指明模塊名，-export 指明導(dǎo)出的函數(shù)。 未被導(dǎo)出的函數(shù)都無法被外界調(diào)用。 從軟件工程上看的話，這樣使得模塊功能和使用方法更加清晰。 使用者只需要關(guān)心如何 -export 里面的函數(shù)即可。 相比較之下 C++ 對這方面特別不規(guī)范，而 Java 通過對類聲明為 public class 指明可以被外界使用, Node.js 也是使用 export 來顯示聲明可以被外界使用的函數(shù)。

行為模式

Erlang/otp 里面的【行為模式】概念等價(jià)于 OOP 里面的接口概念。 上面代碼示例的意思就是該模塊(ecomet_app)遵守的行為模式是(application)。 剛行為模式需要實(shí)現(xiàn)的兩個(gè)接口函數(shù)就是 -export([start/2, stop/1]). 。

另一個(gè)示例如下是遵守監(jiān)督者(supervisor)行為模式， 實(shí)現(xiàn)的一個(gè)接口函數(shù)是 -export([init/1]). 。

監(jiān)督者機(jī)制

Erlang/otp 的天生分布式特性在監(jiān)督機(jī)制里面體現(xiàn)的很好， 每一個(gè) otp 應(yīng)用啟動(dòng)的時(shí)候，都是啟動(dòng)監(jiān)督者(supervisor)和工作者(worker)。 他們的關(guān)系是樹形結(jié)構(gòu)，每個(gè)工作者的上級都會(huì)有監(jiān)督者， 每個(gè)監(jiān)督者的上級也可能有監(jiān)督者。 當(dāng)工作者異常退出的時(shí)候，監(jiān)督者會(huì)根據(jù)相應(yīng)的參數(shù)決定是否對工作者進(jìn)行重啟。 如果重啟失敗的話監(jiān)督者也會(huì)退出，而更加上層的監(jiān)督者收到信號(hào)后會(huì)對他們進(jìn)行重啟等處理。 這個(gè)監(jiān)督者機(jī)制非常好理解，其實(shí)就是 OOP 編程里面的 try ... catch 異常處理機(jī)制。 當(dāng)出現(xiàn)異常的時(shí)候一層一層的往上拋出，直到有人重啟。

otp平臺(tái)

Erlang 最強(qiáng)大的地方也是最讓我感覺難學(xué)的地方，就是它的 otp 平臺(tái)。 各種行為模式， 讓我感覺就像多年以前學(xué)習(xí) MFC 的時(shí)候， 感覺很強(qiáng)大，但是卻總是感覺自己被按死在一條特定的軌道上面奔跑， 有種不自由的疲憊感。

代碼熱切換

熱切換也叫熱升級，大部分情況下，如果需要對 C++/Java 程序進(jìn)程版本升級， 則需要重啟進(jìn)程。 Erlang 支持熱切換的意思就是可以在運(yùn)行的時(shí)候進(jìn)行代碼升級。 升級過程不影響進(jìn)程的運(yùn)行， 而且在過渡階段新舊版本還可以共存。 是不是碉堡了。這個(gè)功能對于那些需要 7x24 高可用的服務(wù)來說簡直就是爽爆了。

Erlang 進(jìn)程本身可以通過一個(gè)類似“后門”的控制臺(tái) erl 來實(shí)時(shí)的查看狀態(tài)， 甚至直接使用控制臺(tái)來修改配置等，非常方便，這對于大部分其他語言來說， 簡直就是黑魔法般神奇的存在。

典型缺點(diǎn)

1.文檔太少，出現(xiàn)問題搜索出來的答案也少。
2.Erlang 人才稀缺，招聘不易。
3.動(dòng)態(tài)語言最典型的就是調(diào)試不易。
4.上手門檻較高。

最后，我只是 Erlang 的入門初學(xué)者， 因?yàn)楣ぷ髦行枰褂?ejabberd (Erlang 的開源項(xiàng)目)， 從而學(xué)習(xí)了 Erlang ， 欠缺實(shí)戰(zhàn)經(jīng)驗(yàn)，所以這篇文章標(biāo)題起為 【Erlang初體驗(yàn)】。