一、前言

　　此遊戲伺服器架構是一個單服的形式，也就是說所有遊戲邏輯在一個工程裡，沒有區分登陸伺服器、戰鬥伺服器、世界伺服器等。此架構已成功應用在了多款頁遊伺服器 。在此框架中沒有實現相關業務邏輯，只有簡單的測試用的註冊登陸功能。但在此框架中新增相應的業務邏輯也是比較輕鬆的，只需要新增相應的協議，編寫對應的訊息處理器即可。

　　下面是專案程式碼的地址：

　　　　，遊戲伺服器工程

　　　　，模擬客戶端與伺服器通訊，用於測試伺服器功能

　　　　專案工具 ---Tools，伺服器搭建用到的jar包以及相關eclipse外掛

二、伺服器執行環境

　　此伺服器是基於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做相應的處理。

　　此架構的持久層使用了ibatis，可能大家覺著ibatis已經過時，現在最多時用的是mybatis。但在生產環境中ibatis一直未出現什麼問題，還是可以再用的。還有mybatis的使用必須每次open一個connection使用完必須close掉，多少感覺有點麻煩（如果使用spring aop到可以避免這種問題）。而在ibatis中，它提供了一個SqlMapClient類，這個類是執行緒安全的，我們只需要把資料庫操作交到SqlMapClient，它內部會幫我們open、close資料庫連線。

　　做遊戲開發都知道，遊戲對資料庫的要求比較低，我們不需要什麼複雜的資料庫操作，所以在持久層我們使用ibator做程式碼生成工具（相應的外掛在Tools專案中有），可以節省大量的開發工作。

 　　以上是對這個java頁遊伺服器的簡單概述，具體程式碼細節請看專案原始碼，語言描述似乎有點困難^_^。篇幅可能有點小，希望管理員不要老給移除掉，