云計算實踐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的，這也是我的得意設計哦。

未來還將繼續云計算實踐，期待有相同興趣愛好的朋友一起交流。