前言

　　Actor模型為並行而生。由於現在單臺機器中獨立的計算單元也越來越多，Actor模型的重要性也越來越大。Actor模型的理念非常簡單：天下萬物皆為Actor，Actor之間通過傳送訊息進行通訊。不同的Actor可以同時處理各自的訊息，從而獲得了大規模的併發能力。

　　Erlang基於Actor模型實現，我們甚至可以這樣認為，沒有Erlang在業界豎立的豐碑，Actor模型便不會如此受人關注。目前，幾乎所有的主流開發平臺上都有了Actor模型的實現，如Java平臺下的Jetlang以及.NET平臺下的MS CCR和Retlang；還有一些Actor框架專為特定語言設計，如F#的MailboxProcessor以及Scala的Actor類庫；甚至微軟還基於MS CCR構建了一門新的語言Axum。

　　不過對於.NET平臺下的開發人員來說，我們最常用的語言是C#。無論您是在使用MS CCR還是Retlang（亦或是我寫的ActorLite），在訊息的執行階段總是略顯尷尬。本文的目的便是提出一種適合C# Actor的訊息執行方式，而這種執行方式還會成為我以後公開的C#中“模式匹配”的基礎。

Erlang中的執行方式

　　本文將分為三個部分，您目前正在閱讀的第一部分，將會觀察Erlang是如何執行訊息的。有對比才會有差距，也正是由於Erlang在Actor模型上的示範作用，我們才會意識到C# Actor在使用上有多麼的不方便。

　　作為示例，我們還是使用最經典的乒乓測試。乒乓測試的效果很簡單：ping和pong為兩個Actor物件，首先由ping向pong傳送一個“Ping”訊息，pong在接受到Ping訊息之後，將會向ping傳送一個“Pong”訊息。在雙方“乒來乓去”幾個回合後，ping將會向pong發起“Finished”，從而停止互動。

　　乒乓測試的Erlang的實現程式碼如下：

-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的函數語言程式設計，尾遞迴，receive原語等特殊的語言特性，其乒乓測試的實現或語義上可能和其他語言有一定區別（詳見《天下無處不乒乓》一文）。不過我們現在還是關注Erlang在訊息執行時的特性：模式匹配。

　　雖然Erlang有諸多優秀特性，但是它的資料抽象能力非常有限。在Erlang中常用的資料結構只有三種：

• 原子（atom）：原子使用小寫開頭的識別符號來表示。您可以把原子認為是一種字串常量來看待，事實上它除了作為標識之外也沒有額外的作用。
• 繫結（binding）：大寫開頭的標示符則為繫結，您可以近似地將其理解為“只能設定一次”的變數。一個繫結內部可以儲存任何資料，如一個程式（Erlang的概念，並非指作業系統程式）的id，一個數字，或一個字串。
• 元組（tuple）：顧名思義，“元組”即為“單元的組合”，單元即為“原子”，“繫結”以及其他“元組”，通過某種方式結合起來。如上述程式碼中{ping, Ping_PID}便是一個由原子“ping”和繫結“Ping_PID”組成。當然您也可以寫成{do, {ping, Hello, World}, 7}這種巢狀的元組結構。

　　Erlang中的receive原語的作用是接受下一條訊息，直到有可用訊息時它才會執行下面的程式碼。Erlang使用了模式匹配（Pattern Matching）來表現接受到不同訊息時的邏輯分支。如pong的實現：

pong() ->
    receive
        finished ->
            io:format("Pong finished~n", []);
        {ping, Ping_PID} ->
            io:format("Pong received ping~n", []),
            Ping_PID ! pong,
            pong()
    end.

　　在這段程式碼中，receive將會設法將訊息與兩種模式進行匹配：

1. 原子finished，表示測試結束。
2. 元組{ping, Ping_PID}，表示一個元組，其中有兩個單元，首先是ping原子，其次是Ping_PID繫結。

　　在成功匹配了某個模式之後，其中的繫結也會隨之被賦上特定的值。如匹配了{ping, Ping_PID}之後，Ping_PID便被賦值為ping這個Actor物件的識別符號。而在接下來的邏輯中，便可以使用這些“繫結”中的值。由於元組的結構不會受到任何限制，因此開發人員可以使用它來表示任意的抽象資料型別——更確切地說，應該是“資料結構”吧。

Erlang的優勢與缺陷

　　Erlang在訊息執行方式上的優勢在於靈活。Erlang是弱型別語言，在實現的時候可以任意調整訊息的內容，或是模式的要求。在Erlang進行模式匹配時往往有種約定：使用“原子”來表示“做什麼”，而使用“繫結”來獲取操作所需要的“資料”，這種方式避免了冗餘的cast和賦值，在使用的時候頗為靈活。然而，世上沒有完美的事物，Erlang的訊息執行方式也有缺陷，而且是較為明顯的缺陷。

　　首先，Erlang的資料抽象能力實在太弱。如果編寫一個略顯複雜的應用程式，您會發現程式裡充斥著複雜的元組。您可能會疲於應對那些擁有7、8個單元（甚至跟多）的元組，一個一個數過來到底某個繫結匹配的是第幾項，它的含義究竟是什麼——一旦搞錯，程式便會出錯，而且想要除錯都較為困難。因此，也有人戲稱Erlang是一門“天生會損害人視力的語言”（令人驚訝的是，那篇文章居然搜不到了，我們只能從搜尋引擎上看出點痕跡了）。

　　而我認為，這並不是Erlang語言中最大的問題，Erlang中最大的問題也是其“弱型別”特性。例如，現在有一個公用的Service Locator服務，任意型別的Actor都會像SL傳送一個訊息用於請求某個Service的位置，SL會在得到請求之後，向請求方傳送一條訊息表示應答。試想，如果SL的功能需要有所修改，作為回覆的訊息結構產生了變化，那麼我們勢必要修改每一個請求方中所匹配的模式。由於訊息的傳送方和接受方在實際上完全分離，沒有基於任何協議，因此靜態檢查幾乎無從做起。一旦遇到這種需要大規模的修改的情況，Erlang程式便很容易產生差錯。因為一旦有所遺漏，系統便無法正常執行下去了。

　　您對Erlang的感覺如何？這是一門會影響您程式設計思維的語言。老趙建議，即使您平時不會使用Erlang，也不妨簡單接觸一下這門語言。它的併發或容災等特性給了我許多啟示。相信您會有不少收穫。