.NET的Actor模型：Orleans

Orleans是微軟推出的相似Scala Akka的Actor模型，Orleans是一個創建在.NET之上的，設計的目標是爲了方便程序員開發須要大規模擴展的雲服務, 可用於實現DDD+EventSourcing/CQRS系統。

傳統的三層體系結構包括無狀態的前端,無狀態的中間層和存儲層在可伸縮性方面是有限制的，因爲存儲層在延遲和吞吐量方面的限制，這對於每一個用戶請求都有影響。一般辦法是在中間層和存儲層之間添加緩存層來提升性能。然而，緩存會失去了大部分的併發性和底層存儲層的語義保證。爲了防止緩存和存儲池的不一致更新，應用程序或緩存管理器須要實現一個併發控制協議。

不管是否使用緩存，無狀態中間層並不提供本地數據，由於它使用的是數據裝載範式: 對於每一個請求，數據是來自存儲層或緩存加裝到中間層，若是是一個社會關係圖，一個請求將會激活關聯不少子實體對象，這就對緩存一致性帶來更大的挑戰。

Actor模型提供了一個解決這些挑戰的有吸引力的依靠函數裝載的範式。Actor容許創建一個有狀態的中間層，緩存的性能優點與封裝的數據局部性都經過特定於應用程序的業務實體封裝協調了（DDD的聚合根用行爲守衛狀態，聚合根保存在緩存中，聚合根實體的狀態字段也在緩存中，對狀態字段的操做只能經過實體行爲，保證狀態一致性）。此外,Actor容易實現中間層中水平的、"社會"、實體之間的關係。

分佈式系統編程的另外一個觀點是面向對象編程(OOP)。雖然OOP是一個創建複雜系統模型直觀的方法，可是他被受歡迎的面向服務的體系結構(SOA)邊緣化了。固然人們仍然能夠受益於OOP實現服務組件時。然而，在系統層面上,開發人員必須考慮鬆耦合的分區服務，一般會致使和應用程序的概念業務對象不匹配，這致使了目前主流方向由開發人員構建分佈式系統很是困難。Actor模型將OOP帶回了系統級開發，開發人員很是像熟悉交互的對象的模型。

例如Erlang和Akka的Actor平臺在簡化分佈式系統編程方面是向前邁出了一步。然而,他們仍然負擔與許多分佈式系統的複雜性，由於開發人員面臨相對低水平的抽象和系統服務。關鍵的挑戰是開發管理Actor生命週期的代碼，處理分佈式競爭、處理故障和恢復Actor以及分佈式資源管理等等都很複雜，所以，若是創建一個應用程序必須正確的解決這些問題，開發人員則必須是一個分佈式系統專家（難度太大）。

爲了不這些複雜性，微軟研究院建造了Orleans的編程模型，運行時它提升了Actor的抽象級別。Orleans的目標不是分佈式系統專家級別的開發人員，雖然咱們的專家客戶發現它也有吸引力。和現有的基於actor平臺有本質差別，它是把Actor做爲虛擬實體,而不是實際物理的。

首先，一個Orleans的Actor老是存在的，可是它不能被顯式地建立或銷燬。它的存在超越任何內存中任何實例的生命週期，從而超越了任何特定服務器的生命週期。

第二，Orleans Actor是自動實例化:若是內存沒有Actor實例，它會自動建立，發送到Actor的一個消息是當前服務器上建立一個新的實例。一個未使用的Actor實例做爲運行時資源管理的一部分自動回收。一個actor實例歷來不會失敗: 若是服務器S崩潰, 發送給這個S中Actor的下一個消息將被自動實例化到另一個服務器A，消除應用程序須要監督和人爲編碼顯式地重建失敗的Actor。

第三，Actor的位置實例對應用程序代碼是透明的,這極大地簡化了編程。

第四，Orleans能夠自動建立多個實例相同的無狀態的Actor，Actor能夠無縫地熱擴展。

Orleans給開發人員一個虛擬"Actor空間",相似於虛擬內存，使他們可以調用系統中的任何Actor，無論它是否存在於內存。虛擬化間接依賴從虛擬Actor到實際Actor的映射。這種級別的間接尋址爲運行時解決許多分佈式系統問題帶來機會，不然開發人員必須直接本身解決這些複雜問題，如Actor定位和負載平衡、失活未使用的Actor,復甦因服務器失敗的Actor,這是出了名的困難。所以,虛擬Actor方法大大簡化了編程模型。同時容許運行時加載和透明地從失敗中恢復。

 

Orleans官方文檔:https://github.com/dotnet/orleans/wiki

Orleans白皮書: http://research.microsoft.com/pubs/210931/Orleans-MSR-TR-2014-41.pdf

.NET Actor Model Implementations Differ in Approach

http://www.cnblogs.com/liwt/category/642869.html