近期在寫基于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討論