Dapr中的Actor模型，和Orleans的Virtual Actor一脈相傳， 聖傑寫過一篇文章Orleans 知多少 | .NET Core 分布式框架介紹過。簡單來講：Actor模型 = 狀態 + 行為 + 消息。一個應用/服務由多個Actor組成，每個Actor都是一個獨立的運行單元，擁有隔離的運行空間，在隔離的空間內，其有獨立的狀態和行為，不被外界干預，Actor之間通過消息進行交互，而同一時刻，每個Actor只能被單個線程執行，這樣既有效避免了數據共享和並發問題，又確保了應用的伸縮性。
Actor模型大大簡化了並發編程的復雜度，Dapr在Actor運行時中提供了許多功能，包括並發控制，狀態管理，生命周期管理如Actor的激活/停用以及用於喚醒Actor的Timer(計時器)和Reminder(提醒)。這些功能同樣也是通過API的方式予以提供。
- 調用Actor 方法：
POST/GET/PUT/DELETE http://localhost:3500/v1.0/actors/<actorType>/<actorId>/method/<method> - 創建 Timer：
POST/PUT http://localhost:3500/v1.0/actors/<actorType>/<actorId>/timers/<name> - 創建 Reminder：
POST/PUT http://localhost:3500/v1.0/actors/<actorType>/<actorId>/reminders/<name>
Dapr Actor 對於使用者，我們可以根據任意名稱去獲取一個Actor（無論它是否存在），然后就可以發送消息給這個Actor（無論它在哪里）。
作為對比我們可以看看傳統微服務架構：
1、通信模型上是節點與節點之間通信（采用RPC形式）
2、同一種服務的多個節點是等價的（因為它們大多數是無狀態）（也就是我們的請求發送給其中任何一個節點都是沒區別的）。
所以在目前的微服務架構里我們基本需要：
1、服務發現（某個服務部署在哪些節點）
2、負載均衡
因此也出現了各種 service mesh框架（比如Istio），來簡化微服務開發，幫我們做這些重復的事情，應用開發者只關心業務。
但即便如此，service mesh跟Dapr Actor 還是有一個顯著區別：Dapr Actor （從編碼來看）開發模型類似OOP，開發者關注的是對象之間的（RPC）通信/交互。 而service mesh仍然是將一個大系統拆分成多個小系統，交互方式仍然是系統與系統之間（服務與服務之間）(可以看做是面向過程，因為服務就類似一組函數)。
不過Erlang同屬Actor模型，跟Dapr Actor 就比較像，但也有一個差別：Erlang是顯式創建Actor，Dapr Actor 是隱式創建（用戶不需要主動創建，你調用它，它就必然存在）；所以從編碼上來看，Dapr Actor 無疑是更便捷的。（當然Erlang的某些特性，Dapr Actor 也是沒有的）：https://channel9.msdn.com/Shows/Azure-Friday/Learn-all-about-Distributed-Application-Runtime-Dapr-Part-2