看Erlang中Actor模型的執(zhí)行方式和優(yōu)劣
Actor模型為并行而生。由于現(xiàn)在單臺機器中獨立的計算單元也越來越多，Actor模型的重要性也越來越大。Actor模型的理念非常簡單：天下萬物皆為Actor，Actor之間通過發(fā)送消息進行通信。不同的Actor可以同時處理各自的消息，從而獲得了大規(guī)模的并發(fā)能力。
Erlang基于Actor模型實現(xiàn)，我們甚至可以這樣認為，沒有Erlang在業(yè)界豎立的豐碑，Actor模型便不會如此受人關(guān)注。目前，幾乎所有的主流開發(fā)平臺上都有了Actor模型的實現(xiàn)，如Java平臺下的Jetlang以及.NET平臺下的MS CCR和Retlang；還有一些Actor框架專為特定語言設(shè)計，如F#的MailboxProcessor以及Scala的Actor類庫；甚至微軟還基于MS CCR構(gòu)建了一門新的語言Axum。
不過對于.NET平臺下的開發(fā)人員來說，我們最常用的語言是C#。無論您是在使用MS CCR還是Retlang（亦或是我寫的ActorLite），在消息的執(zhí)行階段總是略顯尷尬。本文的目的便是提出一種適合C# Actor的消息執(zhí)行方式，而這種執(zhí)行方式還會成為我以后公開的C#中“模式匹配”的基礎(chǔ)。
Erlang中的執(zhí)行方式
本文將分為三個部分，您目前正在閱讀的***部分，將會觀察Erlang是如何執(zhí)行消息的。有對比才會有差距，也正是由于Erlang在Actor模型上的示范作用，我們才會意識到C# Actor在使用上有多么的不方便。
作為示例，我們還是使用最經(jīng)典的乒乓測試。乒乓測試的效果很簡單：ping和pong為兩個Actor對象，首先由ping向pong發(fā)送一個“Ping”消息，pong在接受到Ping消息之后，將會向ping發(fā)送一個“Pong”消息。在雙方“乒來乓去”幾個回合后，ping將會向pong發(fā)起“Finished”，從而停止交互。
乒乓測試的Erlang的實現(xiàn)代碼如下：
- -module(tut15).
- -export([start/0, ping/2, pong/0]).
- ping(0, Pong_PID) ->
- Pong_PID ! finished,
- io:format("ping finished~n", []);
- ping(N, Pong_PID) ->
- Pong_PID ! {ping, self()},
- receive
- pong ->
- io:format("Ping received pong~n", [])
- end,
- ping(N - 1, Pong_PID).
- pong() ->
- receive
- finished ->
- io:format("Pong finished~n", []);
- {ping, Ping_PID} ->
- io:format("Pong received ping~n", []),
- Ping_PID ! pong,
- pong()
- end.
- start() ->
- Pong_PID = spawn(tut15, pong, []),
- spawn(tut15, ping, [3, Pong_PID]).
由于Erlang的函數(shù)式編程，尾遞歸，receive原語等特殊的語言特性，其乒乓測試的實現(xiàn)或語義上可能和其他語言有一定區(qū)別。不過我們現(xiàn)在還是關(guān)注Erlang在消息執(zhí)行時的特性：模式匹配。
雖然Erlang有諸多優(yōu)秀特性，但是它的數(shù)據(jù)抽象能力非常有限。在Erlang中常用的數(shù)據(jù)結(jié)構(gòu)只有三種：
原子（atom）：原子使用小寫開頭的標(biāo)識符來表示。您可以把原子認為是一種字符串常量來看待，事實上它除了作為標(biāo)識之外也沒有額外的作用。
綁定（binding）：大寫開頭的標(biāo)示符則為綁定，您可以近似地將其理解為“只能設(shè)置一次”的變量。一個綁定內(nèi)部可以保存任何數(shù)據(jù)，如一個進程（Erlang的概念，并非指操作系統(tǒng)進程）的id，一個數(shù)字，或一個字符串。
元組（tuple）：顧名思義，“元組”即為“單元的組合”，單元即為“原子”，“綁定”以及其他“元組”，通過某種方式結(jié)合起來。如上述代碼中{ping, Ping_PID}便是一個由原子“ping”和綁定“Ping_PID”組成。當(dāng)然您也可以寫成{do, {ping, Hello, World}, 7}這種嵌套的元組結(jié)構(gòu)。
Erlang中的receive原語的作用是接受下一條消息，直到有可用消息時它才會執(zhí)行下面的代碼。Erlang使用了模式匹配（Pattern Matching）來表現(xiàn)接受到不同消息時的邏輯分支。如pong的實現(xiàn)：
- pong() ->
- receive
- finished ->
- io:format("Pong finished~n", []);
- {ping, Ping_PID} ->
- io:format("Pong received ping~n", []),
- Ping_PID ! pong,
- pong()
- end.
在這段代碼中，receive將會設(shè)法將消息與兩種模式進行匹配：
原子finished，表示測試結(jié)束。
元組{ping, Ping_PID}，表示一個元組，其中有兩個單元，首先是ping原子，其次是Ping_PID綁定。
在成功匹配了某個模式之后，其中的綁定也會隨之被賦上特定的值。如匹配了{ping, Ping_PID}之后，Ping_PID便被賦值為ping這個Actor對象的標(biāo)識符。而在接下來的邏輯中，便可以使用這些“綁定”中的值。由于元組的結(jié)構(gòu)不會受到任何限制，因此開發(fā)人員可以使用它來表示任意的抽象數(shù)據(jù)類型——更確切地說，應(yīng)該是“數(shù)據(jù)結(jié)構(gòu)”吧。
Erlang的優(yōu)勢與缺陷
Erlang在消息執(zhí)行方式上的優(yōu)勢在于靈活。Erlang是弱類型語言，在實現(xiàn)的時候可以任意調(diào)整消息的內(nèi)容，或是模式的要求。在Erlang進行模式匹配時往往有種約定：使用“原子”來表示“做什么”，而使用“綁定”來獲取操作所需要的“數(shù)據(jù)”，這種方式避免了冗余的cast和賦值，在使用的時候頗為靈活。然而，世上沒有***的事物，Erlang的消息執(zhí)行方式也有缺陷，而且是較為明顯的缺陷。
首先，Erlang的數(shù)據(jù)抽象能力實在太弱。如果編寫一個略顯復(fù)雜的應(yīng)用程序，您會發(fā)現(xiàn)程序里充斥著復(fù)雜的元組。您可能會疲于應(yīng)對那些擁有7、8個單元（甚至跟多）的元組，一個一個數(shù)過來到底某個綁定匹配的是第幾項，它的含義究竟是什么——一旦搞錯，程序便會出錯，而且想要調(diào)試都較為困難。因此，也有人戲稱Erlang是一門“天生會損害人視力的語言”（令人驚訝的是，那篇文章居然搜不到了，我們只能從搜索引擎上看出點痕跡了）。
而我認為，這并不是Erlang語言中***的問題，Erlang中***的問題也是其“弱類型”特性。例如，現(xiàn)在有一個公用的Service Locator服務(wù)，任意類型的Actor都會像SL發(fā)送一個消息用于請求某個Service的位置，SL會在得到請求之后，向請求方發(fā)送一條消息表示應(yīng)答。試想，如果SL的功能需要有所修改，作為回復(fù)的消息結(jié)構(gòu)產(chǎn)生了變化，那么我們勢必要修改每一個請求方中所匹配的模式。由于消息的發(fā)送方和接受方在實際上完全分離，沒有基于任何協(xié)議，因此靜態(tài)檢查幾乎無從做起。一旦遇到這種需要大規(guī)模的修改的情況，Erlang程序便很容易產(chǎn)生差錯。因為一旦有所遺漏，系統(tǒng)便無法正常執(zhí)行下去了。
您對Erlang的感覺如何？這是一門會影響您編程思維的語言。老趙建議，即使您平時不會使用Erlang，也不妨簡單接觸一下這門語言。它的并發(fā)或容災(zāi)等特性給了我許多啟示。相信您會有不少收獲。
【編輯推薦】
