Actor模型的本質：究竟是要解決什麼問題

Actor模型的本質已經被強調了無數遍：萬物皆Actor。Actor之間只有發送訊息這一種通訊方式，例如，無論是管理員讓工作者幹活，還是工作者把成果交還給管理員，它們之間也要通過發送訊息的方式來傳遞資訊。這麼做看似不如直接方法調用來的直接，但是由於大量的訊息可以同時執行。同樣，訊息讓Actor之間解耦，訊息發出之後執行成功還是失敗，需要耗費多少時間，只要沒有訊息傳遞迴來，這一切都和發送方無關。Actor模型的訊息傳遞形式簡化了並行程式的開發，使開發人員無需在共用記憶體（確切地說，其實是共用“寫”）環境中與“鎖”、“互斥體”等常用基礎元素打交道。不過，使用Actor模型編寫應用程式，需要開發人員使用一種與以往不同的設計思路，這樣的思路說難倒不難，說簡單也不簡單。等我們有了成熟、穩固的Actor模型之後（例如高效的調度，合適的容錯機制，老趙正在為此努力），再回頭來探究這種特殊的架構方式。

由於Actor執行的唯一“事件”便是接受到了一個訊息，而一個Actor很可能會做多件事情，因此我們一定需要一種機制，可以把訊息“指派”到不同的“邏輯段”中去，並為不同的邏輯指定各自所需要的參數。例如，Person是一個Actor類型，它有三種任務，不同的任務會帶有不同參數：
◆聊天（Chat）：指定另一個Person對象（聊天的另一方），以及一個Topic對象（聊天的話題）。
◆吃飯（Eat）：指定一個Restaurant對象（餐館）。
◆幹活（Work）：指定一個Person對象（工作完成後的彙報人），以及一個Job對象（任務）。

當Person對象獲得一條訊息時，它需要將其識別為聊天、吃飯或幹活中的一種，再從中擷取到這個行動所需要的資料。如果用一幅來表示，它可能是這樣的：

 

如何在C#中把一條訊息轉化為一段邏輯的執行，並且儘可能確保一些優勢（如易於編寫，靜態檢查，代碼提示，重構，單元測試……），這便是這系列文章唯一的目的。正如文章的標題，我們關注的是“訊息執行方式”，而不是：
◆“訊息傳遞”與“共用記憶體”兩種並行方式的比較
◆講述Actor模型的應用程式設計方式。
◆提出訊息傳遞時的解耦方式。
……

文章使用Actor模型作為樣本，是因為我編寫的ActorLite組件易於說明問題，並且是典型的“訊息傳遞”情境。事實上，文章所表達的內容，適合任何基於訊息傳遞的C#情境，例如記憶體中的訊息佇列、生產者/消費者模式、訊息匯流排……它並沒有限制Actor模型這一種架構方式。

 

轉載：http://developer.51cto.com/art/200908/141595.htm