oldworm

最近給自己換了個(gè)老板，忙了一段時(shí)間，所以有幾個(gè)月沒寫博客，今后還是要爭取多寫啊，呵呵。

換來新地方，第一件大的事情就是修改后端架構(gòu)和通信協(xié)議，架構(gòu)也設(shè)計(jì)得很普通，因?yàn)檫@邊的業(yè)務(wù)不需要太過復(fù)雜的后端，所以就簡單設(shè)計(jì)了一下，基本是參照web的模型，符合我一貫的向web學(xué)習(xí)的思想，弄了個(gè)gate管理入口，相當(dāng)于web下的webserver，后端其他服務(wù)器掛在該gate下，相當(dāng)于web模型下的appserver，或者fastcgi模型的fastcgi進(jìn)程，gate上管理連接、合法性檢測、登錄、加密、壓縮、緩存。Gate和后端通信本來想?yún)⒄?/span>fastcgi協(xié)議，但看了之后覺得fastcgi協(xié)議還是復(fù)雜了，所以就設(shè)計(jì)了一個(gè)更簡單的協(xié)議，gate和后端server之間可傳遞key:value型數(shù)據(jù)對，value不局限于字符串，可以是任意數(shù)據(jù)，這樣基本滿足了當(dāng)前的需求，第一版放上去之后也運(yùn)行良好，到今天也基本持續(xù)穩(wěn)定運(yùn)行快一個(gè)月了，沒出過什么事情。由于在gate這邊緩沖了job管理，所以后端server升級很方便，隨時(shí)可關(guān)閉更新，gate會(huì)在窗口時(shí)間內(nèi)將未執(zhí)行完成的任務(wù)重新提交，有此功能可放心大膽的升級后端，這個(gè)月這樣的工作做了幾次，在架構(gòu)修改之前這樣的事情幾乎是不敢做的，因?yàn)橐坏┥壦杏脩羧繑嚅_連接，而現(xiàn)在用戶則基本無感覺。Gate上的緩存層為后端減少了一些壓力，這個(gè)緩存是按照請求的md5為key做的，并根據(jù)協(xié)議配置時(shí)效，有此cache后端大多數(shù)服務(wù)可不設(shè)計(jì)緩存或降低緩存設(shè)計(jì)的復(fù)雜度。Gate上針對敏感數(shù)據(jù)統(tǒng)一做了加密處理，主要是辛辛苦苦整理的數(shù)據(jù)不能輕易讓競爭對手竊去了，呵呵。Gate也做了壓縮，現(xiàn)在是針對>=128長度的包進(jìn)行壓縮，使用了qlz，壓縮效率還是很不錯(cuò)的，速度很快。目前gate后端掛接的既有win上的server也有linux上的server，這是一開始就這么規(guī)劃的，現(xiàn)在看來當(dāng)初的目的達(dá)到了，混合發(fā)揮各自的優(yōu)勢，有的項(xiàng)目在原有系統(tǒng)上跑得好好的，沒必要重新開發(fā)嘛。

協(xié)議設(shè)計(jì)上本來我是計(jì)劃二進(jìn)制混合json格式，以二進(jìn)制為主，但嘗試了一個(gè)協(xié)議之后發(fā)現(xiàn)，這邊的小伙子們對直接操縱內(nèi)存普遍技術(shù)不過關(guān)，他們大多是從java開始的，后來才學(xué)習(xí)c，對字符串用得很熟練，權(quán)衡之下采用了json為主，混合二進(jìn)制為輔的方案，這樣修改之后的協(xié)議和他們之前使用的xml類似，就是更小更緊湊一點(diǎn)，使用方法上很類似，從現(xiàn)在的效果看還行，使用json格式為主的協(xié)議當(dāng)然不能跟使用pb之類的相比，解析效率上大約單線程每秒解析20來萬10個(gè)obj的對象，速度上不算太快但也不算太慢，對付一秒至多幾萬數(shù)據(jù)包的應(yīng)用來說還是夠的，因?yàn)楝F(xiàn)在cpu計(jì)算能力普遍過剩，使用json的另個(gè)好處就是增刪字段很方便，各個(gè)版本之間不需要太考慮版本的問題，要是全用二進(jìn)制格式就要麻煩很多了，在使用壓縮之后，目前的json格式協(xié)議比之前的xml協(xié)議減少了2/3的帶寬使用，總體效果還是可以的。使用json調(diào)試也很方便，我提供了一個(gè)工具，寫后端的就直接用該工具按照json格式收發(fā)數(shù)據(jù)，無需等client開發(fā)好了再去做后端，之后做client也很方便，請求發(fā)過去之后返回來的就是標(biāo)準(zhǔn)的json格式數(shù)據(jù)，同樣的解析方法，每個(gè)不同的應(yīng)用就按照不同的格式處理下即可，和web等模塊交互也很方便，這可算是額外的好處了。

總之，雖然json格式存儲(chǔ)效率和解析效率跟二進(jìn)制方式還差半個(gè)量級到一個(gè)量級，但合理使用還是可以的，特別是跟xml相比優(yōu)勢很明顯，權(quán)衡使用吧，當(dāng)然追求極致效率可能還是用pb之類的更合適一些，或者自己設(shè)計(jì)tlv格式。

07年我寫了一篇文章叫《我的網(wǎng)絡(luò)模塊設(shè)計(jì)》，姑且叫那個(gè)為第一版吧，由于持續(xù)對網(wǎng)絡(luò)模塊進(jìn)行改進(jìn)，所以現(xiàn)在的實(shí)現(xiàn)和當(dāng)時(shí)有很大改變，加上上層應(yīng)用越來越多，又經(jīng)過了幾年時(shí)間考驗(yàn)，現(xiàn)在的實(shí)現(xiàn)方式比之前的更靈活更有效率，也因?yàn)樽罱戳艘恍┤俗鼍W(wǎng)絡(luò)程序多年竟毫無建樹，一直要用別人寫的網(wǎng)絡(luò)模塊，所以有感而寫此文，為了使得此文不受上一篇《我的網(wǎng)絡(luò)模塊設(shè)計(jì)》的影響，我決定寫之前不看原來的文章，所以此文跟原文那篇文章可能沒有太多相似性。
 一個(gè)基本的網(wǎng)絡(luò)模塊，無非就是管理N個(gè)連接，快速處理每個(gè)連接的收發(fā)數(shù)據(jù)、消息等，所謂好的網(wǎng)路模塊，無非就是穩(wěn)定、高效、靈活，下面分幾部分來寫：
 一、 連接管理
 之所以首先寫連接管理，是因?yàn)檫B接管理是核心，也是最難的地方，我寫第一個(gè)網(wǎng)絡(luò)庫之前，搜索過很多當(dāng)時(shí)可以找到的例子工程，當(dāng)時(shí)幾乎找不到可穩(wěn)定運(yùn)行的工程，當(dāng)然更找不到好的，于是摸索前進(jìn)，期間對連接管理使用了各種方法，從最早一個(gè)cs（臨界區(qū)CriticalSection，我簡稱cs），recv send都用這個(gè)cs，到后來send用一個(gè)cs，recv用一個(gè)cs，用多個(gè)的時(shí)候還出過錯(cuò)，最后使用一個(gè)cs+一個(gè)原子值ref管理一個(gè)連接，每個(gè)連接send的時(shí)候用cs，recv的時(shí)候用ref，如果該連接的消息要跨線程異步執(zhí)行，也使用ref，如此較簡單的解決了連接管理的問題。
 同樣使用生存期管理方法，也有人用智能指針，雖然原理和我直接操縱生存期一樣，但實(shí)現(xiàn)方法畢竟不同，不過我為了讓實(shí)現(xiàn)依賴少一些沒有引入智能指針。
 當(dāng)然我后來也發(fā)現(xiàn)很多人不是用這種方法，如有些人就id來管理連接，每個(gè)連接分個(gè)id，其他操作全部用id，每次對連接的調(diào)用先翻譯一下，如果id找得到映射目標(biāo)就調(diào)用，否則就說明該連接不存在了，這種方法簡單只是不直接，多了個(gè)查找過程，另外查找的時(shí)候可能還需要全局鎖（這依賴于連接數(shù)據(jù)組織）。
 也有人使用一個(gè)線程管理連接，其他所有與該連接有關(guān)的生存期問題全部到該線程處理，這樣也是可行的，只是需要做一個(gè)較好的包裝，如果包裝好上層調(diào)用方便，如果包裝不好，可能上層調(diào)用就有一些約束。
 雖然各種方法都有人使用，但我一直選擇直接的生存期管理方法，其實(shí)內(nèi)部實(shí)現(xiàn)的時(shí)候還是有很多優(yōu)化措施的，減少了大量addref、release的調(diào)用，進(jìn)一步提高了效率。
 二、 線程組
 我最初做網(wǎng)絡(luò)庫的時(shí)候還不是很清楚上層如何使用這個(gè)庫，后來在上面做了幾個(gè)應(yīng)用之后慢慢有了更多想法，最近的網(wǎng)絡(luò)庫是設(shè)計(jì)了這么幾組線程：io線程組、同步線程組、異步線程組、時(shí)鐘線程組、log線程組，每組線程都可開可關(guān)，就算io線程組也是可關(guān)的，這只是為了整個(gè)庫更靈活適用性更廣泛，如只用同步線程組或異步線程組僅將這個(gè)線程組當(dāng)一個(gè)消息隊(duì)列使用。
 Io線程組就是處理io收發(fā)的，listen recv send 以及解密解壓縮都是在這組線程，一般這組線程會(huì)開2個(gè)或2*cpu個(gè)。
 同步線程組，一般這組線程開1個(gè)，用來處理logic。
 異步線程組，這組線程根據(jù)需要開0個(gè)或n個(gè)，簡單應(yīng)用無db等慢速操作的應(yīng)用不開，有很多db等慢速操作的可以開很多個(gè)。
 時(shí)鐘線程組，一般不開或開1個(gè)。
 Log線程組，一般開1個(gè)，主要為了避免其他線程調(diào)用WriteLog的時(shí)候被磁盤io阻塞，所以弄了一個(gè)log線程。
 其實(shí)還有一個(gè)主線程，我的每組線程（包括主線程）都支持事件和定時(shí)器，io線程、同步線程、異步線程組、時(shí)鐘線程組、甚至log線程組都支持事件和定時(shí)器，到去年我還只是讓每組線程都支持事件，今年為了更好的使用時(shí)鐘我給每組線程設(shè)計(jì)了定時(shí)器，現(xiàn)在定時(shí)器線程組有點(diǎn)雞肋的味道，一般是用不上專門的定時(shí)器線程組，不過我還沒有將它刪掉，主要在我的設(shè)計(jì)里面，它和同步異步線程組一樣，都只是一組線程，如果必要的時(shí)候可以將它用作同步線程或者異步線程組，所以繼續(xù)保留了它的存在。
 這幾組線程之間都是可互發(fā)消息的，所以一個(gè)邏輯要異步到別的線程執(zhí)行是非常方便的，只要調(diào)用一下PostXXEvent(TlsInfo *ptls, DWORD dwEvent, WPARAM wParam, LPARAM lParam);我憑借這個(gè)設(shè)計(jì)使得這套網(wǎng)絡(luò)庫幾乎可以適用上層各種應(yīng)用，不管是非常簡單的網(wǎng)絡(luò)應(yīng)用還是復(fù)雜的，一框打盡。對最簡單的，一個(gè)io線程搞定，其他線程全關(guān)，對于復(fù)雜的io線程+同步+異步+log全開。
 三、 內(nèi)存池
 內(nèi)存池其實(shí)沒有想象中的那么神秘，當(dāng)然如果要讓一個(gè)網(wǎng)絡(luò)程序持續(xù)7*24小時(shí)穩(wěn)定高效運(yùn)行，內(nèi)存池幾乎必不可少的，內(nèi)存池的作用首先是減少內(nèi)存碎片，其次是為了提高速度，我想這兩點(diǎn)很容易想明白的，關(guān)于內(nèi)存池我之前寫了系列文章，可參考我的博客：
 
《內(nèi)存池之引言》 http://blog.csdn.net/oldworm/archive/2010/02/04/5288985.aspx
 《單線程內(nèi)存池》 http://blog.csdn.net/oldworm/archive/2010/02/04/5289003.aspx
 《多線程內(nèi)存池》 http://blog.csdn.net/oldworm/archive/2010/02/04/5289006.aspx
 《dlmalloc、nedmalloc》 http://blog.csdn.net/oldworm/archive/2010/02/04/5289010.aspx
 《線程關(guān)聯(lián)內(nèi)存池》 http://blog.csdn.net/oldworm/archive/2010/02/04/5289015.aspx
 《線程關(guān)聯(lián)內(nèi)存池再提速》 http://blog.csdn.net/oldworm/archive/2010/02/04/5289018.aspx
 
四、 定時(shí)器
 關(guān)于定時(shí)器，上面講線程組的時(shí)候已經(jīng)講過，我現(xiàn)在的設(shè)計(jì)是每個(gè)線程（包括主線程）都支持定時(shí)器，調(diào)用方法都是一樣的，回調(diào)函數(shù)形式也是一樣的，由于定時(shí)器放到各組線程里面，所以減少了線程之間的切換，提高了效率。
 關(guān)于定時(shí)器，可參考《定時(shí)器模塊改造》 http://blog.csdn.net/oldworm/archive/2010/09/11/5877425.aspx
 
五、 包格式
 關(guān)于包格式可參考《常用cs程序自定義數(shù)據(jù)包描述》 http://blog.csdn.net/oldworm/archive/2010/03/24/5413013.aspx
 
六、 Buffer
 之前的文章其實(shí)我一直沒有提過我的buffer，其實(shí)我的buffer設(shè)計(jì)是很靈活的，現(xiàn)在它和pool也是有些關(guān)聯(lián)的，我的poolset其實(shí)底下就是按照各種不同大小的buffer預(yù)設(shè)的尺寸。Buffer我設(shè)計(jì)為循環(huán)式，不允許回繞，包含
 Char *pbase 塊基址
 Char *pread 當(dāng)前讀指針
 Char *pwrite 當(dāng)前寫指針
 DWORD tag;
 Buffer *next;
 Capacity 總分配尺寸，上面分配的時(shí)候可能只是指定了19，但實(shí)際可能分配的是32個(gè)字節(jié)，所以內(nèi)部用的時(shí)候要根據(jù)capacity來最大限度的利用緩沖區(qū)。
 Buffer分配還利用了一個(gè)技巧，事實(shí)上分配的時(shí)候是一次分配一個(gè)需要的大緩沖，前面為Buffer自身的數(shù)據(jù)，后面為數(shù)據(jù)部分，pbase指向數(shù)據(jù)部分，這樣處理減少了一次分配，我估計(jì)很多人都在用這個(gè)技巧。
 Pwrite總是不會(huì)小于pread的，但pread可能和pbase不一樣，僅當(dāng)后面空余空間不夠用的時(shí)候才可能會(huì)移動(dòng)數(shù)據(jù)，否則數(shù)據(jù)不會(huì)移動(dòng)。
 WSARecv的時(shí)候我是這么處理的，如果首次獲取了一個(gè)包的一部分，但buffer中還有足夠的空間放下包的剩余部分，我不會(huì)再分配一個(gè)buffer去recv，而是直接用原buffer指定一個(gè)合適的偏移和size去WSARecv，這樣可以最大限度的減少復(fù)制。
 剛才還有朋友問到我recv的層次組織，我的網(wǎng)絡(luò)庫里面是這樣組織的，OnRecv是個(gè)虛函數(shù)，最基礎(chǔ)的IocpClient的OnRecv只處理數(shù)據(jù)而不解析格式，IocpClientMsg就會(huì)認(rèn)識默認(rèn)的一種包格式，這個(gè)類的OnRecv會(huì)將m_recvbuf中的數(shù)據(jù)組織為msg，并盡可能的一次返回更多個(gè)msg，回調(diào)OnMsg函數(shù)，由上層決定該消息在哪個(gè)線程處理，這樣我認(rèn)為是最靈活的，如果是個(gè)很小的server，可能直接就在io線程里面處理了，也可postevent到同步線程處理，亦可PostEvent到異步線程處理。
 
七、 TLSINFO
 TlsInfo顧名思義就是每個(gè)線程關(guān)聯(lián)的一組數(shù)據(jù)，暫時(shí)我還沒有看到別人這么設(shè)計(jì)，也許我設(shè)計(jì)得有些復(fù)雜了，在這個(gè)數(shù)據(jù)里面有一些常用的和該線程相關(guān)的數(shù)據(jù)，如該線程的分配基、步長，用這兩個(gè)參數(shù)可讓每個(gè)線程制造出唯一序列，還有常用pool的地址，如tm_pool *p1k; tm_pool *p2k;… 這樣設(shè)計(jì)使得要分配的時(shí)候直接取tm_pool，最大限度的發(fā)揮了分配速度，還有一些常規(guī)參量long c; long d; DWORD a; DWORD b;… 這幾個(gè)值可理解為棧內(nèi)值，其實(shí)為了減少上層調(diào)用復(fù)雜度的，如我將一個(gè)連接的包從io線程PostEvent到同步線程處理，PostEvent首參數(shù)就是tlsinfo，PostEvent會(huì)根據(jù)tlsinfo里面的一個(gè)內(nèi)部值決定是不是要調(diào)用addref，因?yàn)槲矣袀€(gè)地方預(yù)增了2，所以大多數(shù)情況下在io發(fā)到其他線程的時(shí)候是無需調(diào)用addref的，提高了效率，tlsinfo里的其他一些值上層應(yīng)用可使用，用在邏輯處理等情況下。
 
八、 性能分析
 *nix下有很多知名的網(wǎng)絡(luò)庫，但在win下特別是使用iocp的庫里面，一直就沒有一個(gè)能作為基準(zhǔn)的庫，即使asio也因?yàn)槌鰜硖聿粸榇蠖鄶?shù)人熟悉而不能成為基準(zhǔn)庫，libevent接iocp由于采用0 buffer模擬所以也沒有發(fā)揮出足夠的性能，對比spserver我比它快70%左右，我總在想要是微軟能將他那個(gè)iocp的例子寫得更好一點(diǎn)就好了，至少學(xué)的人有一個(gè)更高一點(diǎn)的基礎(chǔ)，而不至于讓http://www.codeproject.com/KB/IP/iocp_server_client.aspx這樣的垃圾代碼都能成為很多人的樣板。
 
九、 雜談
 為了寫好一個(gè)win下穩(wěn)定高效的網(wǎng)絡(luò)庫，我07年的時(shí)候幾乎搜遍了那個(gè)時(shí)間段之前所有能找到的iocp例子，還包括通過朋友等途徑看到的如snda等網(wǎng)絡(luò)庫，可惜真沒找到好的，大多數(shù)例子是只要多線程發(fā)起幾千個(gè)連接不斷發(fā)送數(shù)據(jù)馬上就死了，偶爾幾個(gè)不死的（包括snda的）只要隨機(jī)連接并斷開就會(huì)產(chǎn)生句柄泄漏，關(guān)閉所有連接之后句柄并不關(guān)閉等，也就是說這些例子連基本的生存期管理都沒搞定，能通過生存期管理并且不死的只有有限的幾個(gè)，可惜性能又太差，杯具啊。
 早年寫網(wǎng)絡(luò)庫的時(shí)候也加入了sodme在google上建的那個(gè)群，當(dāng)時(shí)群還是很熱鬧的，可惜大多數(shù)人都是摸索，所以很多問題只是討論卻從無定論，沒有誰能說服別人，也沒有人可輕易被說服，要是現(xiàn)在或許有一些很有經(jīng)驗(yàn)的人，可惜那個(gè)群由于GFW現(xiàn)在雖能訪問也不大活躍了。
 最近看到有些寫網(wǎng)絡(luò)程序7年甚至更久的人還在用libevent、ace等感想很復(fù)雜，可悲的是那些人還沒意識到用一個(gè)庫和寫一個(gè)庫有多大的區(qū)別，可能那些人一輩子也認(rèn)識不到寫一個(gè)庫比用一個(gè)庫難多少，那些人以為這些庫基本會(huì)用了，讓他自己去寫也基本是照這個(gè)模式，不會(huì)有什么突破，就無需自己動(dòng)手了，悲哀啊。當(dāng)然，要寫一個(gè)穩(wěn)定的網(wǎng)絡(luò)庫需要耗費(fèi)很多時(shí)間，特別是要寫一個(gè)能和知名庫性能接近或更好的庫，更是要費(fèi)神費(fèi)力，沒點(diǎn)耐心和持久力是不可能做好的。在中文領(lǐng)域隨便查什么稍有些名氣的代碼，總是能找到很多剖析類文章，可原創(chuàng)的東西總是很少，也不知道那些大俠怎么搞的，什么都能剖析可怎么總寫不出什么像樣的東西呢。
 其實(shí)本來沒有打算寫這篇文章，可能是看了陳碩的muduo才使得我有了寫出來的沖動(dòng)，大概是受到他的開源鼓勵(lì)吧。
 謹(jǐn)以此文記錄本人最近3年對網(wǎng)絡(luò)模塊的修改并簡短總結(jié)。

實(shí)用云計(jì)算環(huán)境簡述

如今it領(lǐng)域沒聽說過云計(jì)算的絕對是out了，雖然大家都知道云計(jì)算，雖然很多高校很多專業(yè)都開設(shè)了云計(jì)算專業(yè)，雖然很多人都在討論云計(jì)算，雖然也有少數(shù)人走在了應(yīng)用云計(jì)算的前列，然而，可悲的是，大多數(shù)人對云計(jì)算的認(rèn)識僅限于amazon、google、microsoft、ibm有能力架設(shè)云計(jì)算環(huán)境，其他公司都靠邊，甚至唯他們的云計(jì)算才叫云計(jì)算，別的企業(yè)根本不可能做云計(jì)算，各級政府部門最搞笑了，動(dòng)不動(dòng)花多少錢引進(jìn)某某云計(jì)算環(huán)境，填補(bǔ)某某空白，多少cpu多少機(jī)器每秒多少萬億次計(jì)算，最終是不是一堆浪費(fèi)電力的擺設(shè)也沒有人知道，也沒人去過問。

略感欣慰的是，很多企業(yè)都在務(wù)實(shí)地部署自己的云計(jì)算環(huán)境，大如騰訊、淘寶、百度、小如我們這樣剛成立的小公司，其實(shí)要部署一個(gè)私有云計(jì)算環(huán)境并沒有那么難，以我個(gè)人的經(jīng)驗(yàn)來看，如果有一個(gè)精干的小團(tuán)隊(duì)，幾個(gè)人一個(gè)月部署一個(gè)私有云計(jì)算環(huán)境是完全可能可行的。在我看來，所謂云計(jì)算就是分布式存儲(chǔ)+分布式計(jì)算，不局限于底下os是win還是*nix，也不局限于是局域網(wǎng)環(huán)境還是廣域網(wǎng)環(huán)境，也不管上面跑的是c++的程序還是javascript的程序，下面簡單介紹下我設(shè)計(jì)的一個(gè)即時(shí)查詢價(jià)格的云計(jì)算體系：

我一直在win下開發(fā)，win用得非常熟練，所以我把云計(jì)算環(huán)境部署在windows之上，當(dāng)然也考慮到windows的機(jī)器眾多，tasknode可輕易找到非常多的目標(biāo)機(jī)器，我部署的云計(jì)算環(huán)境主要分兩類節(jié)點(diǎn)，jobserver和tasknode，jobserver主管任務(wù)切割、任務(wù)調(diào)度，tasknode是計(jì)算節(jié)點(diǎn)。另外還有一些節(jié)點(diǎn)，jobowner可連接jobserver并提交任務(wù)，并可查詢該任務(wù)的執(zhí)行情況，admin可連接jobserver查詢jobserver的狀態(tài)。

其實(shí)這些上篇博客已經(jīng)寫過，我再講的詳細(xì)一點(diǎn)，看具體的執(zhí)行情況，首先jobowner給jobserver提交package，這個(gè)package是一個(gè)zip文件，包含一組文件，jobowner提交package之后jobserver會(huì)根據(jù)約定的規(guī)則管理package，并在jobserver展開該package，如下：

Jobowner連到jobserver之后，發(fā)出如下的命令到jobserver

0x49 0x0 0x0 0x0 0x2 0x0 0xb 0x0 127.0.0.1 0x0 ppsget.dll 0x0

{type:[0,1,2,3,4],rmax:5,wb:"pc",text:"諾基亞 e63"} 0x0

上面是用我設(shè)計(jì)的一種混合顯示格式顯示的包數(shù)據(jù)，可以看到里面帶上了ppsget.dll，這就是指定包內(nèi)部名，其實(shí)還可以這樣ppsget.dll:getpage，如此一個(gè)dll就可支持多個(gè)IJobTask輸出，getpage只是獲得其中一個(gè)IJobTask接口（關(guān)于IJobTask接口參考上一篇云計(jì)算實(shí)踐2的文章）。具體命令是json格式，主要是為了方便信息傳輸和解析。Jobserver接收到該命令之后，調(diào)用ppsget.dll的IJobTask接口中的split函數(shù)，將該任務(wù)分解，之后調(diào)度Tasknode執(zhí)行，tasknode收到jobserver發(fā)過來的任務(wù)之后，檢查包名稱，如果缺少就會(huì)主動(dòng)向jobserver要求發(fā)送相應(yīng)的包，并進(jìn)行部署，待部署完成之后從包獲取指定的IJobTask接口，執(zhí)行該接口的map函數(shù)，將結(jié)果按照約定的格式發(fā)給jobserver，最后由jobserver調(diào)用IJobTask中的reduce函數(shù)進(jìn)行打包，最后將結(jié)果發(fā)給jobowner并記錄相關(guān)Log。

上圖中還可看到一個(gè)HashCrackCloud.dll，這是另一個(gè)云計(jì)算環(huán)境下破解md5密碼的dll，這個(gè)上篇文章也寫了一下，這里就不詳述了。

為使得tasknode可適應(yīng)各種機(jī)器環(huán)境，我把tasknode設(shè)計(jì)為一個(gè)dll，該dll內(nèi)部自己管理消息及任務(wù)執(zhí)行，該dll可被加載到各種容器進(jìn)程（如gui進(jìn)程、console進(jìn)程、service進(jìn)程）等執(zhí)行，看下我的tasknode和它的容器進(jìn)程：

這也算是我的得意設(shè)計(jì)吧，這樣設(shè)計(jì)的tasknode在windows系統(tǒng)下的確具有很高的靈活性。

這樣的tasknode甚至可直接加載在jobserver進(jìn)程，也可被任意win系列機(jī)器的任意進(jìn)程加載參與運(yùn)算，用主動(dòng)加載或被動(dòng)加載都很方便，極大的方便了云計(jì)算環(huán)境的部署，反正具體執(zhí)行的任務(wù)都由package完成，tasknode只要按照約定的規(guī)則部署 package即可，所以這種云計(jì)算環(huán)境是非常輕量級又非常靈活的，開發(fā)一個(gè)新的任務(wù)只要做一個(gè)新的IJobTask即可，目前我這套體系除了沒有考慮太多安全性之外，這個(gè)云計(jì)算環(huán)境的實(shí)施還是非常容易的，實(shí)際上我們這個(gè)價(jià)格查詢的后臺云計(jì)算環(huán)境只用了不到2周的時(shí)間就開發(fā)完成。

再看下jobserver記錄的每個(gè)job的log：

從log中可很容易的分析出一個(gè)job每個(gè)task的執(zhí)行情況，并可根據(jù)這些數(shù)據(jù)進(jìn)行相應(yīng)的優(yōu)化處理。

之所以把jobserver和tasknode以及package都寫出來，主要是為了表達(dá)一個(gè)看法，要實(shí)現(xiàn)一個(gè)簡單的云計(jì)算環(huán)境其實(shí)并不難，有經(jīng)驗(yàn)的團(tuán)隊(duì)很容易就能做出來，參考下google的map/reduce論文，按照自己的需要簡化實(shí)現(xiàn)，真理在實(shí)踐中，如果只是仰望google、amazon，那就真的是在云中霧里，另一個(gè)想要表達(dá)的就是云的形式是多種多樣的，并不一定amazone、google的云計(jì)算環(huán)境才是標(biāo)準(zhǔn)的，對實(shí)用派來說，形式都是次要的，實(shí)用才是關(guān)鍵的。