近期在寫基於go的遊戲伺服器框架, 在全面脫離C/C++前, 需要對老架構進行一個總結

基於C/C++遊戲伺服器框架總體設計的還是不錯的, 兄弟們總體使用效果都是好評. 因為在技術上喜歡"偷懶", 所以在很多設計上, 都是力求簡單, 高效(開發效率).

基於任務的非同步DB查詢系統, 帶多重非同步的同步

程式碼示例:

   1:   

   2:  void BatchQueryPlayerInfo( uint32 ClientID, const std::string& AccountName, int64 CharID )

   3:  {

   4:      GDBExecutor->Commit

   5:          (    

   6:          dynamic_cast<DBDataTask*>( (new DBQueryCharInfo(  ClientID, CharID ) ) 

   7:          ->LinkAtomTask( new DBQueryQuest( ClientID, CharID ) )

   8:          ->LinkAtomTask( new DBQuerySkill( ClientID, CharID ) )

   9:          ->LinkAtomTask( new DBQueryHero( ClientID, CharID ) )

  10:          ->LinkAtomTask( new DBQueryAccountInfo( ClientID, AccountName ) )

  11:          ->LinkAtomTask( new DBQueryEquip( ClientID, CharID ) )

  12:          ->LinkAtomTask( new DBQueryObject( ClientID ,CharID ) )

  13:          ->LinkAtomTask( new DBQueryLevel(ClientID, CharID))

  14:  
 
        ->LinkAtomTask( new DBQueryChapter(ClientID, CharID))

  15:          ->LinkAtomTask( new DBQueryActivity( ClientID, CharID ))

  16:          )

  17:          );

  18:   

  19:  }

這段主要處理玩家在登陸時, 需要從DB查詢大量的不同分類的資料. 為了保證效率, 我讓每個Task並行執行, 然後通過一個機制, 讓所有任務完成後, 回撥第一個任務的一個函式. 這樣就無需手動實現很多粘合程式碼, 避免了反覆除錯和錯誤

基於protobuf反射機制的語句自動合成

   1:  DBUpdateCharInfo::DBUpdateCharInfo( int64 CharID, const std::string& Buffer )

   2:  {

   3:      char buffer[256];

   4:   

   5:      sprintf( buffer, "update tb_char set $FIELD$ where charid = %lld;", CharID );

   6:          

   7:      ExecuteCommand( buffer, Buffer, dbopr::FET_Equation );

   8:  }

這段就是一個典型的DB任務, 建構函式提供了CharID和一個由結構體序列化好的buffer, $FIELD$欄位, 是通過反射根據Buffer內容, 自動填充欄位

這段例子中, $FIELD$可以填充為 hp=100, mp=100之類的. 自動填充避免了因為新增欄位的到處新增程式碼, 還需要除錯, 容易搞錯

配置系統概念

基於同一個配置系統, 分層實現不同的需求. 更簡單的說, 解決的1個實際問題是:

自己改了配置檔案中的ip, 上傳svn後, 覆蓋了別人的配置, 很多人的解決方法都是, 本地配置不提交. 但同時問題又來了:

當配置中有別人新加的系統配置, 怎麼保證每個人都能更新到?

上線後, 伺服器交付運維, 他們會對配置有一定程度的修改, 這個時候怎麼合併程式配置和運維配置?

其實對於衝突的需求, 只要對系統進行分層就可以解決問題,我的處理方式:

配置分為:

全域性配置: 所有服務的總體配置

單服務配置: 本服務的配置, 涉及網路及邏輯

本地配置: 這個配置每個人一份, 不上傳SVN

命令列配置: 格式和前面的一致, 這塊就可以通過運維進行配置

總體結構其實就是OO的派生概念, 下層可以覆蓋, 修改上層的配置

伺服器互聯及識別框架

基本功能: 基於一些簡單的配置就可以將多臺伺服器, 同種類的不同伺服器互相連線起來, 斷線自動重連.

伺服器連線後, 所有伺服器可知曉並可自動按需連線

邏輯端也很方便的進行廣播或者單獨傳送等

也就是說, 每個伺服器的連線和接受端都是帶識別名稱或id的.

後面覺得這套東西實在是做的複雜, 多整出一臺中心伺服器來做. 但好歹框架穩定下來了, 也就好了.

基於lua的伺服器web後臺框架

思想是很不錯的,  C++ 配合lua本身絕對是個失敗

問題出在web處理,本身都是一個同步阻塞過程, 而這個後臺框架是非同步方式來做, 所以特別彆扭

不過比起以前的本地GM系統, 這塊的設計是偉大的進步

現在正在設計基於golang的伺服器框架, 基本框架已經完工, 等待編寫邏輯後的實戰測試

以上的很多思想在golang的伺服器框架都有改進, 特別是golang本身做web也是優秀的, 外加martini這種牛X框架, 更是水到渠成

如果你對伺服器框架設計有特別的認識, 或者想碰撞思想, 可以加部落格群 309800774或者我的qq: 20998333討論