讓我們來看看在.NET生態系中我們有哪些工具可以使用。在接下來的幾節中，我們將介紹流行的框架選擇。Orleans, Proto.Actor, Akka.Net, 和Dapr。我們將重點介紹它們的獨特功能和方法。
Orleans
Orleans框架是虛擬actor模型的前身。它來自於2010年開始的一個微軟研究計畫。它為【光環4】等知名遊戲的後台服務提供了支持。當它開始的時候，它的邊緣有點粗糙，有靜態類，大量的反射，XML配置等等。然而現在，經過幾次叠代後，它的使用已經相當愉快了。
Orleans只關註虛擬行為體模型--傳統的行為體階層不被明確支持。
Orleans實作了自己的集群機制，並依靠外部資料庫為集群成員提供成員資訊。Orleans也有自己的程式碼生成的序列器用於遠端資訊傳遞（盡管序列器是可插拔的）。同樣，網路協定也是奧爾良特有的。
優點
成熟的開源計畫，得到微軟的支持
全面的文件
龐大而活躍的社群
支持actor之間的pub-sub流
永續性的提醒--即使行為者已經停用，計時器也能發揮作用
流行資料庫的成員表實作，例如社群提供的Mongo DB。同樣地，許多持久化的實作也是可用的。
Orleans Dashboard是一個很好的補充，可以快速窺視集群的執行情況
分布式ACID事務--如果你真的需要的話（我們自己還沒試過這個功能）。
缺點
沒有明確地支持傳統的行為體階層
沒有可用的商業支持
對於我們的口味來說，"透過內容進行配置 "和其他自動魔法還是有點太多了
Akka.Net
Akka.Net是來自Java生態系的Akka計畫的一個移植。它是.NET基金會下的一個計畫，由Petabridge公司支持。它有一個開源的核心和作為商業外掛程式提供的工具和服務。
為另一個框架的近似移植，Akka.Net帶來了原版的所有好主意，但也帶來了有爭議的設計決定（例如HOCON配置）。
Akka.Net主要集中在傳統角色和監督層次的使用案例上。但它也有集群模組，可以跨多台機器建立角色系統。特別是，集群分片機制類似於虛擬行為體的方法。從使用者的角度來看，主要的區別是Akka.Net不處理單一的虛擬角色。它而是根據使用者指定的分片策略將它們分組為分片，然後將這些分片分配給集群中的機器。它在這方面有一些獨特的解決方案，這將在另一篇博文中討論。
Akka.Net遵循的路線是實作自己的集群機制以及網路協定和序列化（可以交換實作）。雖然開箱即用的1.4版本使用了Newtonsoft JSON序列化器，但我們的測試表明，使用Hyperion序列化器（目前正在測試）可以獲得更好的效能。
優點
有公司支持，有商業支持計劃
全面的文件和大量的例子和視訊資料
基於著名的Akka框架的概念
能夠將集群與本地監督層次結合起來
集群自動負載平衡和 "記憶實體 "機制
缺點
HOCON配置和其他一些從Akka匯入的怪異現象
一些必要的元件需要購買授權證，比如監控庫Phobos
專註於傳統的行為者模型
集群是基於種子節點的，這需要一些集群節點有穩定的網路地址。建議使用Lighthouse服務，例如將其作為Kubernetes中的一個有狀態的集合部署。
Proto.Actor
Proto.Actor是由Akka.Net的建立者建立的一個框架。它吸收了Akka.Net的經驗，但同時也將 "不要重新發明輪子 "作為其主要理念。
這意味著像序列化、訊息傳遞和集群等方面都重復使用了現有的和經過戰鬥檢驗的解決方案。特別是，Proto.Actor使用了帶有protobuf的gRPC。它還使用現有的集群提供者，如Consul、Zookeeper，甚至是原生的Kubernetes APIs。你可以選擇適合你的用例和基礎設施的實作。
虛擬actor是Proto.Actor中的第一類概念。該框架有很多方式支持這種編程模型，包括程式碼生成的基礎類別，這些基礎類別封裝了低層次的通訊問題。同時，也可以建立傳統的監督層次。這些方法在Proto.Actor中很容易混合和匹配。
Proto.Actor還提供了一個有趣的機制，叫做Local Affinity，我們將在後面的博文中探討。另一個區別在於該框架的Go版本。
優點
使用眾所周知和經過測試的通訊和集群標準
能夠將聚類與本地監督層級相結合
在我們的ping-pong基準中具有最高的訊息吞吐量
近幾個月來，文件得到了許多改進
在集群中分布和定位行為者的各種選項（分區身份查詢、分區啟用器查詢、資料庫查詢)
本地親和力機制
在我們的主觀意見中，最好的編程API
相容OpenTelemetry的監控
缺點
沒有可用的商業支持
仍未達到1.0版本，導致偶爾會出現一些破壞性的API變化
社群相對較小
關註事件來源的永續性，這在很多情況下是不相關的。幸運的是，提供你自己的持久化實作很容易。
Dapr
Dapr是另一個由微軟支持的開源計畫。它是一個更廣泛的框架，提供服務發現、服務間安全可靠的通訊以及儲存和pub-sub功能的抽象。但Dapr的一個額外的部份是虛擬角色模型的實作，其中有一些從奧爾良借來的概念。
Dapr以一種與技術無關的方式實作其功能。該框架本身是用Go編寫的，但它執行在實際套用的旁邊（例如在sidecar容器中），並透過HTTP或gRPC呼叫與之進行通訊。這很有趣，因為你可以用任何技術建立一個基於行為體的解決方案。然而，Dapr執行時並沒有照顧到一個關鍵的方面--角色的狀態。行為體應該把它的狀態保存在記憶體中，只有在需要時才與持久化儲存進行互動。如果你使用Dapr SDK之一，狀態會被緩存在記憶體中，否則你必須自己實作一個類似的解決方案。
缺點是，邊車的方法會引入開銷。看起來，Dapr的虛擬演員實作並不是為了高吞吐量的場景。
展示的應用程式，eShopOnDapr，使用虛擬角色來實作一個持久的工作流（流程管理器模式），這是一個有趣的用例。
優點
由微軟支持的計畫
使用Dapr開始工作相對容易
技術不可知（盡管使用其中一個SDK會使你的生活更容易）。
如果你已經使用了Dapr，就很方便
永續性的提醒--即使行為者已被停用，計時器也能工作。
缺點
sidecar和應用程式之間的HTTP通訊的開銷。
沒有明確支持傳統的角色階層
復雜的部署結構，需要多個元件，例如在Kubernetes中執行，包括用於配置的CRD。
需要在開發機器上使用Dapr執行時間
