Erlang到底好在哪里？

因為能力有限，對Erlang的了解僅限皮毛，本文只做簡單了解.

從技術(shù)上說，Erlang是一個平臺，她提供了一套完整的高性能、高可靠網(wǎng)絡(luò)服務(wù)開發(fā)所需要的基礎(chǔ)設(shè)施，并提供了原語給開發(fā)人員使用，她降低了開發(fā)類似系統(tǒng)的難度與門檻.有一個說法，Erlang讓一個中高級程序員，用一半的時間，一半的代碼量，就能提供頂尖C程序員開發(fā)的網(wǎng)絡(luò)服務(wù)80%性能的類似系統(tǒng)，并且可靠性不輸于甚至超過前者。實踐證明這是真的.

另一方面，Erlang也給了開發(fā)人員強大的自信，就如同前面開發(fā)DSF時的場景所述.有開發(fā)維護過線上系統(tǒng)的人應(yīng)該可以深刻的感受到，開發(fā)一個高可靠的網(wǎng)絡(luò)服務(wù)有多困難，維護一個線上系統(tǒng)有多勞心，當一個服務(wù)上線時，我們的運維與程序員即使睡覺都恨不得睜著一只眼睛.

采用Erlang開發(fā)的系統(tǒng)，其出現(xiàn)的bug量與用常規(guī)語言開發(fā)的絕對不是一個數(shù)量級；Erlang的監(jiān)控樹機制，更是讓我們的服務(wù)，天生就具備了高可靠的基因，只要稍花精力，仔細規(guī)劃我們的監(jiān)控樹與重啟策略，就可以讓本來就少了很多的bug及一些無法預料的外部故障，在即使出現(xiàn)時也有很大的幾率迅速恢復，給你修復bug排除故障一個緩沖的時間，更何況，Erlang可是具備熱更新能力的，那真的可以讓你延壽??！延壽！

如果你的老板問你，為什么要用Erlang，Erlang好在哪里，你可以這樣總結(jié)：省錢.你想想，一個資深的、頂尖的程序員與中高級普通程序員之間的成本差，普通的系統(tǒng)就只要普通的程序員就好啦，那不僅僅是省錢，是省很多很多的錢.

Erlang的優(yōu)勢與缺陷

Erlang在消息執(zhí)行方式上的優(yōu)勢在于靈活.Erlang是弱類型語言，在實現(xiàn)的時候可以任意調(diào)整消息的內(nèi)容，或是模式的要求.在 Erlang進行模式匹配時往往有種約定：使用“原子”來表示“做什么”，而使用“綁定”來獲取操作所需要的“數(shù)據(jù)”，這種方式避免了冗余的cast和賦 值，在使用的時候頗為靈活.然而，世上沒有完美的事物，Erlang的消息執(zhí)行方式也有缺陷，而且是較為明顯的缺陷.

首先，Erlang的數(shù)據(jù)抽象能力實在太弱.如果編寫一個略顯復雜的應(yīng)用程序，您會發(fā)現(xiàn)程序里充斥著復雜的元組.您可能會疲于應(yīng)對那些擁有7、 8個單元（甚至跟多）的元組，一個一個數(shù)過來到底某個綁定匹配的是第幾項，它的含義究竟是什么——一旦搞錯，程序便會出錯，而且想要調(diào)試都較為困難.因 此，也有人戲稱Erlang是一門“天生會損害人視力的語言”（令人驚訝的是，那篇文章居然搜不到了，我們只能從搜索引擎上看出點痕跡了）.

而我認為，這并不是Erlang語言中最大的問題，Erlang中最大的問題也是其“弱類型”特性.例如，現(xiàn)在有一個公用的Service Locator服務(wù)，任意類型的Actor都會像SL發(fā)送一個消息用于請求某個Service的位置，SL會在得到請求之后，向請求方發(fā)送一條消息表示應(yīng) 答.試想，如果SL的功能需要有所修改，作為回復的消息結(jié)構(gòu)產(chǎn)生了變化，那么我們勢必要修改每一個請求方中所匹配的模式.由于消息的發(fā)送方和接受方在實際 上完全分離，沒有基于任何協(xié)議，因此靜態(tài)檢查幾乎無從做起.一旦遇到這種需要大規(guī)模的修改的情況，Erlang程序便很容易產(chǎn)生差錯.因為一旦有所遺漏， 系統(tǒng)便無法正常執(zhí)行下去了.

這的確是對于動態(tài)類型語言很常見到的擔心，而且，確實，如果不加注意會成為嚴重的問題.這種困擾確實是因為 Erlang 的“動態(tài)類型”和“基于消息”而造成的.但，這并非無解，實際上，在 Erlang 編程規(guī)范之中，已經(jīng)給出了解決方案.

通常而言，Erlang 中的消息應(yīng)該是以“控制流”為主，在消息的數(shù)據(jù)結(jié)構(gòu)表達上，不同的消息通常都對應(yīng)著不同的處理流程，在這里“控制”是消息中最為關(guān)注的內(nèi)容.為此我們可以簡單的引入一個 atom 來予以表達，這就是 Tag Messages 的最佳實踐：

5.7 Tag messages

All messages should be tagged. This makes the order in the receive statement less important and the implementation of new messages easier.

Don’t program like this：

loop（State） ->

receive

...

{Mod， Funcs， Args} -> % Don‘t do this

apply（Mod， Funcs， Args}，

loop（State）;

...

end.

The new message {get_status_info， From， Option} will introduce a conflict if it is placed below the {Mod， Func， Args} message.

If messages are synchronous， the return message should be tagged with a new atom， describing the returned message. Example： if the incoming message is tagged get_status_info， the returned message could be tagged status_info. One reason for choosing different tags is to make debugging easier.

This is a good solution：

loop（State） ->

receive

...

{execute， Mod， Funcs， Args} -> % Use a tagged message.

apply（Mod， Funcs， Args}，

loop（State）;

{get_status_info， From， Option} ->

From ！ {status_info， get_status_info（Option， State）}，

loop（State）;

...

end.

可以相信，一段龐雜的代碼，在經(jīng)過一番這樣對 Message 本身的設(shè)計和重構(gòu)之后，最終都能讓其恢復“秩序與美感”.而消息中的其他參數(shù)，如果其處理邏輯非常復雜的話，那么帶有模式匹配的子函數(shù)，又或著是 Tuple/Record 正是其用武之地.

上面我們提到了“對 Message 的設(shè)計和重構(gòu)”，實際上，這只是問題的一個方面.另外一個方面是：無論 Message 的“協(xié)議”設(shè)計得有多精巧，其對外的接口都不應(yīng)該用消息來表達，而應(yīng)該是“接口函數(shù)”的形式.

Erlang 系統(tǒng)之中的消息是極度靈活的系統(tǒng)，但它并不適合用來作為模塊之間的接口，因為它過于靈活.更加適合這一角色的設(shè)施是“函數(shù)”.用來充當這樣角色的函數(shù)就被 稱作“接口函數(shù)”，在其實現(xiàn)代碼中，除了“按照約定的格式發(fā)消息以外”什么別的也不做——因為它包裝的正是以消息為載體的交互“協(xié)議”.它是函數(shù)，有著嚴 格的語法檢查，而且可以在多個模塊之間重用.一旦需要修改消息協(xié)議，起隔離作用的“接口函數(shù)”就會體現(xiàn)出其存在的巨大價值.

5.10 Interface functions

Use functions for interfaces whenever possible， avoid sending messages directly. Encapsulate message passing into interface functions. There are cases where you can’t do this.

The message protocol is internal information and should be hidden to other modules.

Example of interface function：

-module（fileserver）.

-export（［start/0， stop/0， open_file/1， ...］）.

open_file（FileName） ->

fileserver ！ {open_file_request， FileName}，

receive

{open_file_response， Result} -> Result

end.

...code...

Erlang 是動態(tài)語言，對其進行靜態(tài)檢查比較困難（并非不能 R13 已經(jīng)有所動作）.但，并不是說沒有靜態(tài)檢查就會寸步難行.Erlang 同樣重要的語法特性是它還是函數(shù)式語言，遇到有疑惑的地方，不妨以函數(shù)的角度來思考.

Erlang 語言素有“難學”的名聲，其中一個原因就是因為雖然其語法十分簡單，但常會讓人心生 “就這樣了，然后呢？” 之惑——因為過于靈活而無所適從，而且也不存在著顯而易見的正確用法.這種困擾通常要在有了一定的實踐經(jīng)驗之后才會漸漸消散.換句話說，在“學會”和“用 好”之間存在著一堵模模糊糊的墻，而這一“未知區(qū)域”又需要一定的耐心和經(jīng)驗方可穿越.