Actor模型的本質(zhì)：究竟是要解決什么問題
Actor模型的本質(zhì)已經(jīng)被強調(diào)了無數(shù)遍：萬物皆Actor。Actor之間只有發(fā)送消息這一種通信方式，例如，無論是管理員讓工作者干活，還是工作者把成果交還給管理員，它們之間也要通過發(fā)送消息的方式來傳遞信息。這么做看似不如直接方法調(diào)用來的直接，但是由于大量的消息可以同時執(zhí)行。同樣，消息讓Actor之間解耦，消息發(fā)出之后執(zhí)行成功還是失敗，需要耗費多少時間，只要沒有消息傳遞回來，這一切都和發(fā)送方無關(guān)。Actor模型的消息傳遞形式簡化了并行程序的開發(fā)，使開發(fā)人員無需在共享內(nèi)存（確切地說，其實是共享“寫”）環(huán)境中與“鎖”、“互斥體”等常用基礎元素打交道。不過，使用Actor模型編寫應用程序，需要開發(fā)人員使用一種與以往不同的設計思路，這樣的思路說難倒不難，說簡單也不簡單。等我們有了成熟、穩(wěn)固的Actor模型之后（例如高效的調(diào)度，合適的容錯機制，老趙正在為此努力），再回頭來探究這種特殊的架構(gòu)方式。
由于Actor執(zhí)行的唯一“事件”便是接受到了一個消息，而一個Actor很可能會做多件事情，因此我們一定需要一種機制，可以把消息“分派”到不同的“邏輯段”中去，并為不同的邏輯指定各自所需要的參數(shù)。例如，Person是一個Actor類型，它有三種任務，不同的任務會帶有不同參數(shù)：
◆聊天（Chat）：指定另一個Person對象（聊天的另一方），以及一個Topic對象（聊天的話題）。
◆吃飯（Eat）：指定一個Restaurant對象（餐館）。
◆干活（Work）：指定一個Person對象（工作完成后的匯報人），以及一個Job對象（任務）。
當Person對象獲得一條消息時，它需要將其識別為聊天、吃飯或干活中的一種，再從中獲取到這個行動所需要的數(shù)據(jù)。如果用一幅示意圖來表示，它可能是這樣的：
如何在C#中把一條消息轉(zhuǎn)化為一段邏輯的執(zhí)行，并且盡可能確保一些優(yōu)勢（如易于編寫，靜態(tài)檢查，代碼提示，重構(gòu)，單元測試……），這便是這系列文章唯一的目的。正如文章的標題，我們關(guān)注的是“消息執(zhí)行方式”，而不是：
◆“消息傳遞”與“共享內(nèi)存”兩種并行方式的比較
◆講述Actor模型的應用程序設計方式。
◆提出消息傳遞時的解耦方式。
……
文章使用Actor模型作為示例，是因為我編寫的ActorLite組件易于說明問題，并且是典型的“消息傳遞”場景。事實上，文章所表達的內(nèi)容，適合任何基于消息傳遞的C#場景，例如內(nèi)存中的消息隊列、生產(chǎn)者/消費者模式、消息總線……它并沒有限制Actor模型這一種架構(gòu)方式。
【編輯推薦】
