我費力費心的翻譯過官方的教程,但是本人英語詞匯量不高,可是架不住電子詞典啊…只要肯花時間,我這些內容誰都可以做出來.所以這個事例告訴我們一個道理,那就是碼農有三好,錢多話少死得早.我也許只有后兩好.

?????? 當初阿爾法狗在圍棋上戰勝人類的時候,人工智能一時大熱,不管老小,都大肆談論一番深度神經網絡學習算法等等,我當時也是一時興起去拿出我嶄新的書本,說起來都是淚,大學并沒有好好學習,都玩游戲了…不過不管如何,數學系畢業的,底子好點,翻看完必要的知識后,就去看深度神經網絡算法,去了解它們的原理,看到最后,我發現,這不就是一種全分類算法嗎?頓時覺得高大上的深度學習網絡沒有那么神秘了.經常看到這樣的圖片:

?

?

　　我們拿過來用,借用微軟的話:一個服務本質上是多個可通信actor的集合,用上面的圖片好像正合適.

?????? Grain類是輕量級的,為了更好的設計,現實中往往使用grain類來代表顆粒度很細的東西.比如一個商城,可以用GrainA來代表店鋪,用GrainB來代表商品…商鋪管理商品,所以GrainB就會和GrainA之間有互動,在系統中,對每個商品進行單獨控制,就需要很多的GrainB的實例,這在Orleans中很容易做到,更難得的是,可以對GrainB或者GrainA發生的事件進行記錄,實現eventsourcing. Actor的建模方式,使得eventsourcing顯得很自然,也很容易處理.

　　讓多個Grain互動起來才有更多的可能性,一個服務本質上是多個可通信actor的集合.所以在這個例子中,我們創造多個Grain實例,讓它們彼此之間有聯系.我們使用”現實中的經理于員工的關系”這樣一個背景模型來構造這個例子.

步驟

我把它們添加到basic項目里,接口如下圖

?

?

還是跟以前一樣,定義接口.這里注意這些接口只有方法,盡量避免使用屬性.雖然現實當中一個經理同時也是一個員工,但是這里的經理接口并沒有繼承自員工接口.這樣做是基于以下考慮:這兩個接口都要被擴展成Grain類,以后對員工和經理的狀態值進行持久化存儲的時候,”非繼承”的兩個grain類會帶來一些方便.稍微說一下持久化:意思就是對Grain類的各個字段進行持久化存儲(存到數據庫或者文件都可以),方便下一次Grain激活的時候讀取各個字段的值.

好了,不管如何,我就是這么勤快的人,直接寫了兩個接口,而不是選擇繼承.現在我勤快的實現這兩個Grain類.

如下圖:

?

?

大部分基礎工作做完了,我們再client調用它們.

?

?

運行之后的截圖如下:

?

?

上個例子雖然正確的運行了,但是隱藏一個小坑,真正正確的操作應該如下圖

?

?

這是因為Grain的方法都是異步的.如果不添加await,在一些耗時的操作中也許會出現先后順序的錯誤.不過對于這個例子,添加不添加與否,并不影響結果.

?

解釋一下

　　以前說過,Orleans是基于actor模型構建的,但是Orleans把actor模型做到了極致,它是虛擬的actor模型.一個grain的生命周期,是從一個激活開始,到一個反激活結束.它既然是”激活”而不是構造,這就要求grain類不應該有構造函數,即便是沒有參數的構造函數.一個grain從來不是??? 從構建到銷毀,而是處于激活或者非激活兩個狀態. 可以在OnActivateAsync()中控制Graini的激活行為,實現類似于”構造”的過程Orleans保證這個方法會在所有其他方法之前調用.在上一個例子中就展現了如何使用這個方法.

　　在多線程的編程中,最討厭的兩個事情是死鎖和錯誤處理.有時候,在開發的時候測試一百次都不會死鎖,但是到部署到客戶哪里,一次就給你死鎖.這一般是因為測試的環境簡單化了,沒有考慮到客戶環境的并發量以及并發的時間點.更因為這兩個因素很多時候根本無法考慮.

　　消息死鎖

　　Orleans編程可以做到全程無鎖,它同時使得多線程編程邏輯上更容易處理,錯誤更容易捕捉.但是這不代表不需要設計.為了展現一下,我再此修改員工和經理.這次我們設計一個問候消息如下:

public class GreetingData { ? ?
? ? public Guid From { get; set; } ?
? ??public string Message { get; set; } ?
? ??public int Count { get; set; } }

?

　　我設想,新員工加入的時候經理給一個問候,同時新員工回答thanks,這樣來來回回的消息,就像兩個乒乓球機器人一樣對發對打.加上一個count,本意是想著來回的次數不要超過3次.不然就進入了死循環了.

修改IEmployee?中的Greeting方法的參數.

Task Greeting(GreetingData data);

修改對接口的實現.

public async Task Greeting(GreetingData data) {Console.WriteLine("{0} said: {1}", data.From, data.Message); // stop this from repeating endlesslyif (data.Count >= 3)
? ? ? ? return; // send a message back to the sendervar fromGrain = GrainFactory.GetGrain<IEmployee>(data.From);
? ?await fromGrain.Greeting(new GreetingData From = this.GetPrimaryKey(),Message = "Thanks!",Count = data.Count + 1 }); }

?

也更新Manager類,這樣它就會發送一個新的消息.

public async Task AddDirectReport(IEmployee employee) {_reports.Add(employee); ?
??await employee.SetManager(this); ?
??await employee.Greeting(new GreetingData {From = this.GetPrimaryKey(),Message = "Welcome to my team!" }); }

現在經理說”Welcome to my team!" ,員工應該回復一個Thanks.

　　如果運行這個程序,就造成了一個死鎖,這是因為經理發送消息給員工,并等待回應,員工回答Thanks,并等待經理回應.問題就在于員工的消息永遠得不到回答,因為經理正在忙著等待它第一個消息完成呢,在經理那里,員工的回答必須排隊等待.這就是一個死鎖!!同樣的還有死循環.在Actor編程中死循環往往容易處理(在任何編程中都容易處理),因為它容易定位.但是死鎖就稍微困難點.

　　Orleans提供了日志,可以記錄并提示可能的死鎖,它一般用WARNING 體現出來,結尾是About to break its promise. 注意在服務器繁忙的時候,網絡不好的時候,都有可能出現這個警告.

　　為了 應對這樣的死鎖,Orleans提供了一個特性[Reentrant],它可以標志一個Grain,使得這個類在處理其他消息的時候,稍微富有”彈性”,可以同時接受其他新消息的到達,(只是”到達”這個步驟”彈性”化,”處理消息”這個步驟依然是剛性的”單線程約束”).使用方法很簡單.如下:

[Reentrant]
public class Employee : Grain, IEmployee {... }

?

?處理建議

　　Orleans系統分為客戶端和服務端.對于網站來說,Orleans客戶端通常是asp或者其他的http框架,而Orleans服務端通常是數據庫操作端等等.在一個中大型的Orleans系統中,多重Actor互相關聯,最好是自上而下的設計,遵循好消息流或者數據流的流動方向,讓它們的流動可以分支,但是小心處理回流,(需要回流的地方請小心設計,不過這種情況也不會很多,如果很多,請檢查自己的數據設計是否合理).

　　在用一個Grain去管理多個Grain類的想法中,還有一點要注意的是,盡量不要產生過于繁忙的Grain實例.由于Grain實例是”單線程機制”的,一個實例操作過于繁忙會影響效率.上例中,如果一個經理直接下屬有一百萬個人.那么這樣設計的程序過熱點就是這個經理.此時需要分散過熱點.一個簡單的辦法是按照員工主標識hash表分段,每一段分給一個經理…此時組合主標識就會派上用場.

　　吃瓜群眾應該覺得此處應該有總結:

接口項目就是平時說的”消息協議”.發送消息就是調用接口.在方法內部可以不用鎖而隨意讀寫字段.避免死鎖和過熱的grain實例.

　　上例中設計了單獨的問候類,在.net世界里,在作為參數傳遞和使用的時候,.net是傳遞實例的地址.但是這種機制在并發和多線程的情況下,并不能很好的工作.在Orleans世界里,作為消息的參數(即Grain方法的參數),傳遞的時候默認都是對類實例進行一個深度拷貝,在跨機器的情況下,這是很有必要的.但是如果消息發送的目的地就是在本地silo里,如果還是需要進行深度拷貝,就顯得多余和浪費了.Orleans提供了一個特性[immutable],用它來標明一個類一旦建立就不會再對它進行修改.如果消息目的地是本地silo,使用[immutable]標明的類作為參數時,Orleans就會跳過對此參數的深度拷貝,而是只傳遞一個引用.使用非常簡單.如下:

[Immutable]
public class GreetingData { ?
? ?public Guid From { get; set; }
? ?public string Message { get; set; } ?
? ?public int Count { get; set; } }

?????? 好了,第二個例子就說完了.有點Orleans實際項目的影子了,但是還是不夠…

?????? 似乎應該更進一步,那就是存儲,把Grain的狀態值保存起來,下一次激活的時候,恢復它的狀態值,這樣才能符合現實需要.可以嘗試在OnActivateAsync里控制讀取動作,在OnDeactivateAsync中控制存儲動作.不過微軟提供了更為通用的存儲中間件(StorageProvider),使得這些工作變得容易.所以完全沒有必要自己另外實現一個(當然你愿意也行).要想使用這些存儲中間件,就必須配置一下.可以使用配置文件,也可以在代碼里配置.所以持久化就按下暫且不表,我來說說配置.

相關文章：?

• .NET的Actor模型：Orleans

• 微軟分布式云計算框架Orleans(1)：Hello World

• 微軟分布式云計算框架Orleans(2)：容災與集群(1)

• Aaron Stannard談Akka.NET 1.1

• 使用Akka.net開發第一個分布式應用

• Orleans入門例子

• Orleans例子再進一步
  

原文地址：http://www.cnblogs.com/gaopang/p/7387607.html

---

.NET社區新聞，深度好文，微信中搜索dotNET跨平臺或掃描二維碼關注

總結

以上是生活随笔為你收集整理的Orleans稍微复杂的例子—互动的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。