在.NET中實現Actor模型的不同方式

　　英文原文：.NET Actor Model Implementations Differ in Approach

　　上周，《實現領域驅動設計》（Implementing Domain-Driven Design）一書的作者 Vaughn Vernon，發布了 Dotsero，這是一個使用 C# 編寫的、基于 .NET 的 Actor 模型工具包，它的實現參考了 Akka API。Akka 工具包是對 Actor 模型的一種實現，目前為止已經有對應 Java 和 Scala 版本的 API。

　　今年早些時候，微軟 Research 部門也發布了一個基于 Actor 模型的框架，Orleans 框架的預覽版。這個框架采用了云端編程模型，編寫這個框架的目的在于盡可能減少創建互動式的服務時所面對的各種挑戰，這些服務往往對伸縮性和可靠性有較高要求。

　　Orleans 團隊認為，雖然 Erlang 和 Akka 這些 Actor 平臺已經在簡化分布式系統編程方面前進了一步，但由于它們提供了相對較低層次的抽象與系統服務，因此自身的復雜性依然很高。開發者們必須要成為分布式系統 方面的專家，才有可能使用這些工具創建正確的解決方案。為了避免這些復雜性，并吸引主流開發者，Orleans 團隊提升了 Actor 的抽象層次。雖然它仍然基于 Actor 模型，但與任何現有的基于 Actor 模型的平臺所不同的是：它將 Actor 視為抽象的，而不是物理的實體。

　　最近，Vaughn 與 Orleans 項目的帶頭人，來自微軟 Research 部門的 Sergey Bykov 在 推ter 上進行了一番討論。Vaughn 認為，Orleans 本質上并非是一種基于 Actor 模型的實現，其中部分原因在于它缺少了用以支持有限狀態機（FSM）的 Become 和 Unbecome 方法，而 Vaughn 認為這是 Actor 原始的定義中所必需的一部分。他同時也認為，由于在 Orleans 中 Actor 是始終存在的，那么當客戶端對某個本應不存在的 Actor 發起請求時，它難以意識到這一點，從而容易引發問題。

　　Sergey 在回應中 表示，Become 只是讀取定義的其中一種方式，并非 Actor 模型所必需的一部分。而從他的經驗來看，由于 Orleans 中的 Actor 始終存在，因而減少了競態條件的產生，并且簡化了恢復操作，從這方面來看由此可能產生問題的可能性比 Vaughn 所說要小很多。如果某個 Actor 不應該存在，那么可以通過由應用程序邏輯返回一個錯誤狀態的方式進行處理，雖然他也承認這種方式并不夠理想，但比起在創建 Actor 時遇到競態條件的情況還是要更好一些。

　　最近， Azure 方面的一位微軟 MVP，Richard Astbury 創建了一個簡單的物聯網網關應用程序，以此表明他對 Orleans 的觀點，即 Orleans 能夠幫助開發者在云端創建大規模、低延遲并且適應性良好的 .NET 應用程序。Richard 表示，雖然這只是個簡單的示例，但它已經包含了創建更復雜的場景時所需的各種基礎構建塊了。

　　今年三月時，有一份名為《Orleans：針對可編程性與伸縮性的分布式虛擬 Actor》的論文專門講解了 Orleans 背后的設計原則。

　　Vaughn 去年在一篇關于響應式領域驅動設計（DDD）的文章中談論了關于 Actor 模型的話題，并且在之前的一次演講中談論了 Actor Model 的產生以及 DDD 的相關話題。

                    <span id="shareA4" class="fl">                            
                        </span>