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模型這一種架構方式。
【編輯推薦】
