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

標籤：des   http   os   java   使用   io   for   ar   art   

上周，《實現領域驅動設計》（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表示，雖然這隻是個簡單的樣本，但它已經包含了建立更複雜的情境時所需的各種基礎構建塊了。

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

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

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