一、前言

　　此遊戲服務器架構是一個單服的形式，也就是說所有遊戲邏輯在一個工程裏，沒有區分登陸服務器、戰鬥服務器、世界服務器等。此架構已成功應用在了多款頁遊服務器 。在此框架中沒有實現相關業務邏輯，只有簡單的測試用的註冊登陸功能。

　　服務器工程---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項目中有），可以節省大量的開發工作。

Java遊戲服務器搭建