Dapr	Orleans
runtime 執行時	framework 框架
actor 只是其中的一個元件	actor + state
無分散式事務方案	提供最終一致性保障
依賴於 dapr 執行時	無除了 .net 環境的依賴
比較難進行 debug	偵錯開發無差別
docker 與 k8s 支援	裸金屬/docker/k8s 支援
多種語言 sdk 支援	僅 C# 語言
1.8 版本	3.6 版本，4.0 即將釋出

Actor 模型

對同一個 actor 的呼叫按順序執行
one actor 可以建立其他的 actor
給一個 actor 發訊息（呼叫它的執行方法）
不能自己去範例化和銷燬
同一個 identity 的 grain 在系統內只存在一共啟用的範例
actor 沒有共用資料
actor 的資料不可用被外部直接修改

我們有個工作 jd001，就是一個 actor，它會有一個 internal state，狀態裡面會有一個 identity，它是唯一的，不可改變的

有一個瀏覽工作的訊息，它把工作的 id，以及當前的瀏覽者資訊傳入進來，呼叫 jd001

jd001 會建立一個 activity actor ac001，然後呼叫 ac001 把瀏覽記錄下來，有一個活動型別 view

Orleans 的核心概念

單執行緒執行模型
多路通訊複用
其他優勢
Grain
叢集
最佳實踐

單執行緒執行模型

actor 在 Orlean 中叫作 grain 穀倉

執行時保證 grain 每次永遠不會在多個執行緒上執行，通過結合與其他 grain 的隔離，程式設計師絕不會在 grain 級別面臨並行情況，因此絕不會需要使用鎖或者其他同步機制來控制對共用資料的存取，非專家級程式設計師只需此功能便可方便地控制分散式應用程式的開發

多路通訊複用

Orlean 中的 grain 具有邏輯終結點，它們之間的訊息傳送跨一組固定的全交換物理連線（TCP 通訊端）進行多路複用，這使得執行時能夠託管數百萬個可定址實體，並且每個 grain 的作業系統開銷很低，此外，在註冊/取消註冊物理終結點（例如 TCP 埠或 HTTP URL）甚至關閉 TCP 連線時，啟用和取消啟用 grain 都不會產生成本

其他優勢

熟悉的物件導向的程式設計（OOP）正規化（grain 即是 .net 類）
啟用透明
位置透明
自動傳播錯誤
自適應資源管理

高效能

顯示非同步
多路複用通訊
高效計劃：執行時在自定義執行緒池中計劃大量單執行緒 grain 的執行（每個物理處理器核心一個執行緒），藉助採用非阻塞基於延續的樣式（Orleans 程式設計模型的一個要求）編寫的 grain 程式碼，應用程式程式碼會以非常高效的「共同作業」多執行緒方式來執行，沒有任何爭用，這允許系統達到較高吞吐量，並以很高穩定性採用非常高的 CPU 使用率（高達 90% 以上）執行。

Grain

概念
模式
持久化
特點
計時器和提醒

概念

grain = identity + behavior [ + state ]

identity : User/davidgri
behavior : class User : Grain, Iuser
state : in-memory, persisted, or stateless

模式

silo 內模式（叢集內）
silo 外 client-server 模式（叢集外：使用者端、伺服器端不在同一個 host 裡面）

持久化

啟用 grain 時，會自動讀取 grain 狀態，但 grain 需要負責在必要時顯示觸發任何已更改的 grain 狀態的寫入

IPersistentState<TState>

Grain<TState>（已過時）

通過 MongoDB 持久化

Orleans.Providers.MongoDB: https://github.com/OrleansContrib/Orleans.Providers.MongoDB

特點

Grain 類似於物件，但是，它們是分散式的，虛擬的並且非同步的
它們是鬆散耦合、隔離並且基本上獨立的
避免在 grain 之間進行瑣碎通訊
- 直接使用記憶體比傳遞訊息的開銷要小得多
- 將過於瑣碎的 grain 組合成單個 grain 可能更好
- 需要考慮引數和序列化的複雜性/大小
- 反序列化兩次可能比重新傳送二進位制訊息的開銷更大
避免瓶頸 grain