Erlang到底好在哪里_Erlang的優(yōu)勢(shì)與缺陷

Erlang到底好在哪里？

因?yàn)槟芰τ邢?，?duì)Erlang的了解僅限皮毛，本文只做簡(jiǎn)單了解.

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

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

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

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

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

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

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

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

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

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

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)過(guò)一番這樣對(duì) Message 本身的設(shè)計(jì)和重構(gòu)之后，最終都能讓其恢復(fù)“秩序與美感”.而消息中的其他參數(shù)，如果其處理邏輯非常復(fù)雜的話，那么帶有模式匹配的子函數(shù)，又或著是 Tuple/Record 正是其用武之地.

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

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

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 是動(dòng)態(tài)語(yǔ)言，對(duì)其進(jìn)行靜態(tài)檢查比較困難（并非不能 R13 已經(jīng)有所動(dòng)作）.但，并不是說(shuō)沒(méi)有靜態(tài)檢查就會(huì)寸步難行.Erlang 同樣重要的語(yǔ)法特性是它還是函數(shù)式語(yǔ)言，遇到有疑惑的地方，不妨以函數(shù)的角度來(lái)思考.

Erlang 語(yǔ)言素有“難學(xué)”的名聲，其中一個(gè)原因就是因?yàn)殡m然其語(yǔ)法十分簡(jiǎn)單，但常會(huì)讓人心生 “就這樣了，然后呢？” 之惑——因?yàn)檫^(guò)于靈活而無(wú)所適從，而且也不存在著顯而易見(jiàn)的正確用法.這種困擾通常要在有了一定的實(shí)踐經(jīng)驗(yàn)之后才會(huì)漸漸消散.換句話說(shuō)，在“學(xué)會(huì)”和“用 好”之間存在著一堵模模糊糊的墻，而這一“未知區(qū)域”又需要一定的耐心和經(jīng)驗(yàn)方可穿越.