雲計算實踐2
上一篇《基於雲計算的價格查詢實現》就算是雲計算實踐1吧，所以這篇就叫《雲計算實踐2》。其實今年開始研究雲計算有一段時間了，約3個月前研究md5破解(http://www.shprog.com/HashCrack.aspx)，那個項目就是選來玩雲計算的，當時覺得md5破解這個小項目好玩，邏輯很簡單，密碼字母組合可長可短，規模可大可小，1臺機器不嫌少，1萬臺不嫌多，所以就選中了它，沒想到第一個md5破解版本後來演變成了主要是密碼數據庫的製造，雖然第一版沒有做成標準雲計算，但也算有個結果，而且存儲效率、製造速度還是令人滿意的，也就是說那個項目只是雲計算研究的副產品，我的本意並不是想做一個md5破解或者qq密碼破解，但結果就產生了這麼一個產品，也算是努力了一個多月的結果，期間對hash算法、存儲格式等絞盡腦汁思考了很久，也因此對雲計算倒是考慮得不多，最終偏離了大目標。
好在後續研究基於雲計算的價格查詢終於又回到雲計算上來了，而且仿照google的map/reduce做了一個標準的jobserver + tasknode形式的實現，雖然兄弟們未必對價格查詢項目看好，但對這個基於windows實現的雲計算框架還是一致看好的，價格查詢項目第一階段基本完成預定目標，所以昨天我又將以前md5破解的東西寫了一個在線版的dll，拿到雲計算框架裏面來試圖雲破解，不過這個不是特別成功，主要是即時計算耗時有些多，平均1個task計算1億組合大約需要30秒，因此在我現在只有2個點參與運算的情況下遍歷很大區間是很耗時的，也因此我沒有做一個在線雲破解md5的頁面，這個工作作爲研究性探索也只在我的控制端下了幾個雲計算的任務就告一段落，今後將致力於其他更實用的雲計算實踐。
爲了做這第二個雲計算的dll，我將原來定義的jobtask接口（可參見《基於雲計算的價格查詢實現》）修改了一下，不再使用原來的c風格接口，直接改成c++風格了，如下：
interface IJobTask
{
virtual HMODULE free() = 0;
//初始化函數，部署環境等
virtual bool init(bool tasknode) = 0;
//分割函數，分割輸入
virtual size_t split(const char *input, size_t len, std::vector<CAutoBuffer *> &vbuf) = 0;
//task執行函數
virtual bool map(const char *cmdline, CAutoBuffer &buf, CAutoBuffer &ibuf) = 0;
//reduce打包輸出函數
virtual bool reduce(std::vector<CAutoBuffer *> &vbuf, CAutoBuffer &buf) = 0;
//獲取執行錯誤
virtual char *geterror() = 0;
};
有朋友批評我，說我的接口使用stl容器，使用自定義類CAutoBuffer等不好，我以前也是這麼跟別人講的，接口不要使用這些東西，但看了google的map/reduce實現用的都是MapInput、ReduceInput之後我改變了看法，暫時就這樣定義吧，大不了各個dll都用同一版本的vc編譯就是了，也沒有什麼大不了的，如果不行整體升級一下總可以吧，爲了短時間盯住主要目標，也只能大刀闊斧不考慮過多細節了，這也算是一個平衡的結果吧。
這次修改除了修改了接口，簡化了實現之外，還實現了一些特性，動態卸載，上一個版本裝入之後就不卸載了，要關閉exe才能卸載這些dll，所以無法熱更新，這個版本實現動態卸載之後就支持熱更新了，關鍵就在那個free函數，
virtual HMODULE free() = 0;
該函數實例如下：
virtual HMODULE free()
{
HMODULE h = m_hlib;
delete this;
return h;
// if(h) FreeLibrary(h); 這裏釋放是有問題的，所以不能這樣釋放
}
在外部調用的地方
FreeLibrary(jf->free());
這樣就實現了動態卸載dll的功能
用上雲計算佈局的價格查詢的這段時間，還是有一些經驗教訓的，基於這種相隔很遠，網絡條件差別很大的機器佈局的雲計算環境，可靠性是很差的，大多數時間可能反應還是比較快，但有的時候反應就特別慢，可能網絡延時會相差200ms，或者500ms，或者更多，我特意記錄了每個task的實際執行時間和包括網絡傳輸在內的總時間，就是從這兩個時間看出差距的，所以如果要基於這種環境做實時性很高的計算還是不適合的，如果對節點反饋實時性要求很高，那一定要佈置類似局域網形式的計算環境，點點反饋時間1ms內，而且響應穩定不易受到影響。此外磁盤Log時間是不定的，我記錄最後一個task完成到job完成之間調用了兩次WriteLog，對大多數job來說，最後一個完成的task的時間和job完成的時間一致，但偶爾有少數job時間和最後一個完成的task時間差別很大，甚至有超過1s的，原先沒有這麼精細的測量，這次在jobserver寫了很多log，起初是爲了找錯誤，後來是爲了追蹤job和task執行，倒是意外的發現了一些問題，也獲得了一些意外的收穫。
雲計算好啊，早年我做過一個遠程控制的程序，當時做了一條命令broadcast，可以廣播其他任意命令，當時很得意於這個設計，也有指揮千軍萬馬的感覺，但當時各自執行，結果並不彙總，各個任務完全獨立。現在給雲計算環境下達一個任務，也有同樣的感覺，可能對使用我的價格查詢(http://www.oldworm.com/pps.aspx)的用戶或者使用google查詢的用戶根本感覺不到，他這一個查詢提交下去後面有那麼多機器聯動運算，但作爲開發人員，真真切切的看到後面那麼多機器在執行任務，真的是很爽的一件事情，一起看下我兩臺機器聯動執行任務的場面共勉吧：
圖看得不是很清楚，實際上第一個taskmanager是一臺機器，另一個taskmanager是另一臺機器，那兩個都是在遠程桌面裏面運行的，下面ie是我的網頁，可以看到我在網頁裏面查詢nokia的時候，上面兩臺機器的tasknodeapp裏面就接收到任務並執行了任務，那個tasknodeapp是我臨時用來演示的，事實上裏面都是調用tasknode.dll，tasknode的主要任務都是tasknode.dll執行的，爲這個dll做了好幾個不同的容器，有service的有普通mfc的還有console的，這也是我的得意設計哦。
未來還將繼續雲計算實踐，期待有相同興趣愛好的朋友一起交流。