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模型這一種架構方式。