C/C++服务器架构机制设计总结

近期在写基于go的游戏服务器框架,在全面脱离C/C++前,需要对老架构进行一个总结。


基于C/C++游戏服务器框架总体设计的还是不错的,兄弟们总体使用效果都是好评。因为在技术上喜欢"偷懒",所以在很多设计上,都是力求简单,高效(开发效率)。


基于任务的异步DB查询系统,带多重异步的同步


代码示例:


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

{

GDBExecutor->Commit

   (    

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

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

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

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

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

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

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

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

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

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

      )

    );

}


这段主要处理玩家在登陆时,需要从DB查询大量的不同分类的数据。为了保证效率,我让每个Task并行执行,然后通过一个机制,让所有任务完成后,回调第一个任务的一个函数。这样就无需手动实现很多粘合代码,避免了反复调试和错误。


基于protobuf反射机制的语句自动合成


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

{

char buffer[256];

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

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

 }


这段就是一个典型的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框架,更是水到渠成。

作者: 徐波

原文链接: http://www.cppblog.com/sunicdavy/archive/2014/12/18/209225.html

本篇文章由 HTML5梦工场 小编从其他媒体精选前端相关文章转载,仅供网友学习和交流,如果小编的工作有侵犯到您的权益,请及时联系小编QQ:123464386,将会在第一时间进行处理!投稿与合作,请发至邮箱:tommy@html5dw.com