一、前言
此遊戲伺服器架構是一個單服的形式，也就是說所有遊戲邏輯在一個工程裡，沒有區分登陸伺服器、戰鬥伺服器、世界伺服器等。此架構已成功應用在了多款頁遊伺服器 。在此架構中沒有實作相關業務邏輯，隻有簡單的測試用的注冊登陸功能。
伺服器工程---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項目中有），可以節省大量的開發工作。