不過後來發現，用上面兩個實在是沒必要....
一來這兩個是蠻龐大的 middleware，有的沒的要搞一堆，例如：certificate。
二來研究的重心並不是在 Grid 環境的架設與運作，而是要證明 Grid 是不是可以協助我改善某些工作的處理效率。
再加上最近看了 80/20 相關法則的書，所以.......決定還是找一套輕巧好用的 Grid middleware 就行啦! (其實是我有點懶.....@_@)
之後在 google 發現了 Alchemi，以下是 Alchemi 官方網站的介紹與架構圖：
Alchemi is a .NET grid computing framework that allows you to painlessly aggregate the computing power of intranet and Internet-connected machines into a virtual supercomputer (computational grid) and to develop applications to run on the grid.
乍看之下，哇~號稱 painless 耶! 真的有這麼好嗎?
接著仔細研究了一下，發現他幾乎都把底層的部分做完了，說實在省了 developer 不少的工，因此 developer 只要專注於程式要做什麼就好，不太需要瞭解 job 是怎麼丟出去或是成功回傳....等等太細節的東西；不過基本上還是要瞭解一下在 Grid 環境中程式的寫法，因為跟一般的程式差異頗大。
但說到底，還真是感謝有如此好物出現....讓我省了好多麻煩阿....雖然架構看起來很簡單，不過實在是足夠滿足我研究要做的東西了!
Alchemi 運作的基本概念如下：
- 是以 Manager 為中心，由 User 送出 Grid Application
- Application 中包含許多 Threads，每個 Thread 有其需要負責的工作，由 Manager 將每個 Thread 送到各 Executor 去執行
- 最後由 Executor 回傳處理結果，再由 Manager 整合
上面所介紹的僅僅是基本概念，當然按照此基本概念去寫程式，就會有一些侷限，例如：
- Thread Job 無法使用非 .NET Framework 所提供的 library (這個真的很麻煩，許多好用的 third party library 就無法使用了)
- Manager 僅能被動的等待 Executor 回傳處理結果再進行整合 (如此一來無法主導整個程式的運作，也不是很方便)
這是目前所遇見的問題，後來去找教授討論後，他要求程式要修改的更完善，後來思考很久，在原本的運作模式下根本無法達成要求，因此又回來重新仔細翻翻 Alchemi 的文件，發現了一件事情......原來我疏忽了很多東西阿!! 原來 Alchemi 提供了許多我需要的功能.....(此時要再次向作者跪拜....Orz)
當然以上所提只是基本概念，其中 Alchemi 還提供了幾個很重要的功能： (後來仔細翻文件才發現....)
- 在 run-time 期間，Application 與 Thread 其實都是可以控制的，Manager 並非只能被動等待 Thread 工作完成。(前提是權限足夠的情況下)
- 透過設定 module dependency 後，就可以使用 third party library，如此一來還可以減少 Manager 與 Executor 之間資料的傳輸 (這真是令人振奮的發現!!)
- 由於在某些情況下，不能保證剛開始就可以確定所有執行的相關資訊，因此可以在 run-time 期間增加 Thread 到 Application 中
最後，當然也是有美中不足之處，就是目前 Thread 之間沒有辦法作訊息的交換，因此在開發程式時需要注意到有此問題! 因此在 concurrency control 就無法非常精確(不過在大多數情況下，這並無傷大雅....)。
之後預計要推出 Java API，不過目前還沒看到，看樣子作者似乎也很忙，短時間內大概也不會出現吧! 不過沒關係，這套 middleware 基本上還可以算是麻雀雖小，五臟俱全啦!
沒有留言:
張貼留言