近期在写基于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讨论