.NET的Actor模型Orleans是怎么樣的

這期內容當中小編將會給大家帶來有關.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方法大大簡化了編程模型。同時允許運行時加載和透明地從失敗中恢復。

上述就是小編為大家分享的.NET的Actor模型Orleans是怎么樣的了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注億速云行業資訊頻道。