一、前言
此游戏服务器架构是一个单服的形式，也就是说所有游戏逻辑在一个工程里，没有区分登陆服务器、战斗服务器、世界服务器等。此架构已成功应用在了多款页游服务器 。在此框架中没有实现相关业务逻辑，只有简单的测试用的注册登陆功能。
服务器工程---GameServer（https://github.com/yongzhidai/GameServer.git）
测试客户端---TestClient，模拟客户端与服务器通信，用于测试服务器功能（https://github.com/yongzhidai/TestClient.git）
项目工具 ---Tools，服务器搭建用到的jar包以及相关eclipse插件（https://github.com/yongzhidai/Tools.git）
二、服务器运行环境
此服务器是基于tomcat启动，所以GameServer是一个web工程，但此游戏服务器还是基于socket通信的，没有使用tomcat的http通信。游戏服务器的启动是通过在WEB-INF目录下的web.xml中添加一个监听器。这个监听器用来监听tomcat的启动和停止，当tomcat启动时则启动游戏服务器开始监听端口，当tomcat停止时则做相应的销毁操作。
可能很多人会疑惑为什么要基于tomcat呢？
基于tomcat运行有很多优势：
1、方便调试。在我们调试服务器程序时，可是利用tomcat的热加载功能，使修改的代码不用重启就可以生效
2、方便打包部署。部署一个web程序到tomcat是一个比较容易的事，对第三方jar包的依赖tomcat也会帮忙处理好
3、利用tomcat提供的数据源。这可能不算是优势，但起码还算便捷
4、方便开发GM。我们可以很容易的在次架构中加入一个机遇web的管理系统，直接管理当前游戏服务器的在线玩家
三、通信层
java开发socket服务器最常用的就是mina和netty这两个nio框架。网上有测试说netty性能稍好一些。但是由于mina在生产环境中没遇到什么问题，而且本人对mina源码比较熟悉，还是采用了mina作为通信层框架。（netty3跟mina代码结构差不多，但是netty4变化比较大，本人稍微未对源码理解透）
通信协议：flag(1 byte)+length(4 byte,消息号加消息内容的长度)+protocol code(4 byte)+content
flag：是一个预留标识
length：表示消息号和消息内容的长度
protocol code：自定义消息号，通过次消息号选择相应的消息处理器，自然消息号是不能重复的，一个int表示范围足够使用
content： 消息内容，一个有序的数据的数组。protocol code和content都要在开发功能时定义在‘消息协议’文档中的，例如GameServer项目中的“消息协议.xls”
此项目中没有对消息内容进行加密，若要加密也是很容易添加上。
消息处理：
服务器收到客户端发来的消息，MsgDispatcher会根据其消息号选择对应的MsgProcessor进行处理。MsgProcessor会读取content做相应的处理。
三、持久层
此架构的持久层使用了mybatis。但在生产环境中ibatis一直未出现什么问题，还是可以再用的。还有mybatis的使用必须每次open一个connection使用完必须close掉，多少感觉有点麻烦（如果使用spring aop到可以避免这种问题）。而在ibatis中，它提供了一个SqlMapClient类，这个类是线程安全的，我们只需要把数据库操作交到SqlMapClient，它内部会帮我们open、close数据库连接。
做游戏开发都知道，游戏对数据库的要求比较低，我们不需要什么复杂的数据库操作，所以在持久层我们使用ibator做代码生成工具（相应的插件在Tools项目中有），可以节省大量的开发工作。