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

在.NET中實現Actor模型的不同方式是怎樣的，相信很多沒有經驗的人對此束手無策，為此本文總結了問題出現的原因和解決方法，通過這篇文章希望你能解決這個問題。

《實現領域驅動設計》（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在twitter上進行了一番討論。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表示，雖然這只是個簡單的示例，但它已經包含了創建更復雜的場景時所需的各種基礎構建塊了。

看完上述內容，你們掌握在.NET中實現Actor模型的不同方式是怎樣的的方法了嗎？如果還想學到更多技能或想了解更多相關內容，歡迎關注億速云行業資訊頻道，感謝各位的閱讀！