cocos2d-x開發：服務端基礎庫封裝

元旦前面幾天都在忙着面試,隨後的幾天也就一直在作服務端基礎庫開發方面的工做.對於服務端開發,是好久以前的事情了.那時候我還在大學讀書,一直都是在倒騰服務端開發方面的東西,畢業後參加公司工做就是一直從事客戶端開發工做,再也沒有碰過服務端開發的事情.剛開始我很猶豫,不過一切並無想象的那麼糟糕,很快我就找回了之前的狀態,整體來講,這幾天的工做成果和效率我還算是滿意的.最主要的是狀態回來了,因此也就不擔憂其餘的了.

先說一下爲何我要選擇本身去開發服務端的基礎庫.整體來講,本身去開發服務端,從零開始,在stl和posix thread上面去開發本身的基礎庫是頗有難度的,會遇到不少的問題.我之因此這樣子選擇,是由於對於優秀源碼庫閱讀量比較多,本身比較自信,即便遇到一些設計實現上面的問題,我也能夠很快找到優秀的實現源碼,第一時間去參考別人的設計實現方法.另外,和我選擇開發的底層語言也是相關的,我此次並無選擇使用C,也沒有選擇使用C/C++混編,除了底層系統級別的C庫以外,我都是使用全C++方式開發的,基礎的思惟方式也是面向對象.我認可,本身系統學習C++理論知識的時間還很短,但是在實際的開發過程當中,我發現已經足夠支撐我前進了.惟一不足的就是,我須要作大量的傻瓜方式的測試才能保證本身寫的底層模塊在執行的流程上面不出現錯誤,固然這是在不涉及複雜業務邏輯的時候.對於須要處理複雜繁瑣邏輯的地方,我都是無條件的信賴stl.在這一層面,我並無選擇本身去作無畏的工做,主要仍是我相信我沒有能力涉及到那個層面.

之因此選用C++去開發,而沒有選擇java/erlang/golang之類的語言,不是由於我真的不會這些快餐式的語言.說白了,仍是心底的執拗與偏執在做祟,其餘的應該就不用多說了.其實我徹底是能夠選用java/golang的,java開發起來對我來講難度並不大,即便已經很久沒有碰過,也不知道如今最新版本的JDK更新到哪裏了,我想這些都不會影響個人.對於java方式的開發,我更願意認可那是各類第三方組件的混合物,問題說到最後就只是如何快速學習和正確使用這些第三方開發組件罷了.而golang做爲如今頗有競爭力的C系語言,我仍是很喜歡的,可是我怕本身還不能正確理解它的工做方式,那將直接影響我對它的使用理解.即便能作出來東西,在理解不正確的狀況下,相信也拿不出手.

固然,從前面的一些文章我就開始暴露出本身好久不碰服務端開發的問題了.可是也都一一解決了.讓我感到很惱火的是,我在Ubuntu Kylin上面開發,用CMake管理項目,用sublime去寫代碼,而sublime老是會莫名其妙的死掉,還好的是,給我形成的代碼丟失每次都並非不少,也多是我喜歡瘋狂保存(C-S).當make不過或者是執行test/sample發現邏輯有問題的時候就到qtcreator/kdevelop去調試.整體來講,這個流程我漸漸的熟悉並習慣,作起事情來也算是比較的順手,固然依靠unittest和sample,因爲其簡單業務邏輯的限制,我相信可能會有一些問題是發現不了的,不過這沒有關係.我能夠在開發後端應用的時候遇到問題,在開發中解決.

在開發以前我曾經仔細想過,並對本身作過一些簡單要求.不使用隱晦難懂的語法,不依賴繼承,接口設計儘可能多而簡單.這些是我對本身提的要求,也是爲了在設計底層接口的時候提醒本身.這幾天編碼下來,我都是儘可能遵循這些規則在實現方面下工夫.須要提的一點是,我受到golang的影響,在實現中不多使用繼承,而是更多使用簡單的組合功能.固然了,我也不是什麼完美主義者,並非徹底要求本身寫出徹底按照本身要求的那些代碼,我仍是會使用接口方面的功能.就像是純虛類之類的來做爲接口.就像是線程執行的任務,我就直接採用了之前我使用java的那種方式,設計了一個Runnable的接口,提供一個run方法由任務子類本身去實現.這樣作也是很方便的.其餘的還有不少,例如,本身實現的簡單的引用計數的智能指針,其中包括相似stl的std::autoptr以及boost::sharedptr這樣的指針,說到實現的話,裏面使用的引用計數我就是使用了gcc的原子操做作到的.細節就不說了,這方面的資料能夠自行去Gnu gcc查閱官方的一手資料.網上的二手資料也不少,能夠很容易找獲得的.

在這幾天的編碼中,主要是實現了基礎的一些功能,大部分的時間都花在實現鎖處理,線程,線程以及線程池上面了,另外還簡單的處理了一下時間,可是並無處理日期.這個延後作吧,至少我如今的需求對日期方面的處理尚未依賴.今天早上也是在着手處理網絡部分的模塊.因爲發現本身對ip地址的格式處理根本就沒有任何的經驗,因此不得不暫停了網絡庫部分的開發,轉而去了解這方面的知識,但願今天能夠補足ip格式處理方面的基礎功能.另外我也考慮過了,因爲我開發網絡庫部分是爲了遊戲服務端服務的,暫定的實現方式是使用reactor-aceptor的工做方式,在reactor採用epoll去管理socket io事件,對於長連接,則是提供直接建立service工做方式,基礎接口我會直接給出,由上層根據業務需求本身去實現.而這部分直接實現runnable,提供獨立的線程去處理r-a服務.也就是處理epoll io事件.長連接創建以後全部的任務都應該進到任務隊列去,由線程池的工做線程處理.工做線程以後能夠說,應該就到業務邏輯部分了.不過我不打算徹底用C++開發,因此確定會用腳本語言.至因而選用Lua仍是Python再看吧.

其實按照這種分析方式來講,從socket管理到任務隊列再到工做線程分發任務到具體服務仍是腳本,這些能夠認爲是與下層服務無關的,這部分既不會對通訊數據進行操做,也能夠從下層服務獨立出來.就是通訊調度部分.也能夠說是服務端調度的核心層.接下來要考慮的事情就是,將通訊部分獨立出來以後,到服務以後,服務之間的通訊問題.若是我將服務間的通訊都丟到任務隊列去,由工做線程處理的話,那麼須要作的就是本身獨立設計一套通訊方式用來區別本地通訊和客戶端到服務端請求(c2s-client to server).