遊戲的架構設計非常重要，好的架構**清晰，責任明確，擴充套件性強，易於除錯。這些會為我們的開發省下不少時間，對於遊戲伺服器的架構設計，我們首先要了解遊戲的伺服器架構都有什麼組成？一款遊戲到上線，需要具備哪些功能？遊戲架構本身代表是乙個體系，它包括：
1.系統初始化
系統初始化是在沒有客戶端鏈結的時候，伺服器啟動時所需要做的工作。基本上就是配置檔案的讀取，初始化系統引數。
但是需要注意一些問題：
系統初始化需要的引數配置在哪兒，是配置在本地伺服器還是配置在資料庫。
伺服器啟動的時候去資料庫取；
配置的修改需不需要重啟伺服器等；
2.遊戲邏輯
**必須分層，不然後期要修改需求，比較麻煩，netty是目前比較流行的nio框架。
協議層，也叫後台互動層，它主要負責前台互動協議的解析和返回資料。在這一層基本上沒有什麼業務邏輯實現。與前台互動的資料都在這一層開始，也在這一層終止。比如用netty框架，那麼netty的ctx只能出現在這一層，他不能出現到遊戲業務邏輯**的實現中，接收到客戶端的請求，在這一層把需要的引數解析出來，再把引數傳到業務邏輯方法中，業務邏輯方法處理完後，把要返回給客戶端的資料再返回到這一層，在這一層組織資料，返回給客戶端，這樣就可以把業務邏輯和網路層分離，業務邏輯只關心業務實現，而且也方便對業務邏輯進行單元測試。
業務邏輯層，這裡處理真正的遊戲邏輯，該計算**計算**，該通關的通關，該計時的計時。該儲存資料的儲存資料。但是這一層不直接操作快取或者資料庫，只是處理遊戲邏輯計算。因為業務邏輯層是整個遊戲時間的處理核心，所以他的處理是否正確直接決定遊戲的正確性。所以這一層的**要盡量使用物件導向的方法去實現。不要出現重複**或相似的功能進行複製貼上。
這樣修改起來十分不便，可能是修改了某一處，而忘記修改另外同樣的**。還要考慮每個方法都是可測試的，乙個方法的行數最好不要超過一百行。另外可以多愛看設計模式的書，它可以幫助我們設計出靈活，整潔的**。
3.資料庫系統
資料庫是儲存資料的核心，但是遊戲資料在儲存到資料庫的時候會經過網路和磁碟的io，它·的訪問速度相對於記憶體來說是很慢的。一般來說每次訪問資料庫都要和資料庫建立鏈結，訪問完成之後，為了節省資料庫的鏈結資源，再把鏈結斷開。
但是這種鏈結無形中又為伺服器增加額開銷，在大量的資料訪問時，可能會更慢，而遊戲又是要求低時延的，這時該怎麼辦？
有乙個資料庫連線池，即把訪問資料庫的鏈結放到乙個地方管理，用完不斷開，用的時候去拿，用完再放回去。這樣不用每次都建立新的鏈結了。
但是如果要我們自己去實現一套連線池管理組建的話，需要時間不說，對技術的把控又是乙個考驗，還要經過測試等等，幸好網際網路開源的今天，有一些先成的可以使用，這裡推薦mybatis，即實現了**與sql的分離，又有足夠的sql編寫的靈活性，是乙個不錯的選擇。
4.快取系統
遊戲中，客戶端與伺服器的互動就是要求低時延的，延遲越低，使用者體驗越好。像之前說過的一樣，低時延就是要求伺服器處理業務盡量的快，客戶端乙個請求過來，要在最短的時間內相應結果，最低不得超過500ms,因為加上來回的網路傳輸消耗，基本上就是600ms-700ms，再長就會覺得卡。
如果直接從資料庫中取資料，處理完之後再·存回資料庫的話，這個效能是跟不上的。在伺服器，資料在記憶體中處理是最快的，所以我們要把一部分常用的資料提前載入到記憶體中。比如說遊戲資料配置表，經常登入的玩家資料等。這樣在處理業務時，就不用走資料庫了，直接從記憶體中取就可以了，速度更快。
遊戲中常見的快取：
1.直接把資料儲存在jvm或伺服器記憶體中
2.使用第三方快取工具，推薦redis.
5.遊戲日誌
日誌一定要記錄詳細。它是玩家在整個遊戲中的行為記錄，有了這個記錄，我們就可以分析玩家的行為，查詢遊戲的不足，在處理玩家在遊戲中的問題時·，日誌也是乙個良好的憑證和快速處理方式。
在遊戲中，日誌分為：
2.玩家行為日誌，比如玩家傳送了什麼請求，得到了什麼物品，消費了多少貨幣等等。
3.統計日誌，這種日誌是對遊戲中所有玩家某種行為的一種統計，根據這個統計來分析大部分玩家的行為，得出一些共性或不同之處，以方法運營做不同的活動吸引使用者消費。
在架構設計中，日誌記錄一定要作為一種強制行為，因為如果不強制的話，可能由於某種原因某個功能忘記加日誌了，那麼當這個功能出問題了，或者運營跟我們要這個功能的一些資料庫，就gg了，又得加需求，改**了。日誌一定要設計一種良好的格式。日誌記錄的資料要容易讀取，分解。日誌行為可以用列舉描述，在功能最後的處理方法裡面加上這個列舉作為引數，這樣不管誰在呼叫這個方法時，都要去加引數描述。
6.遊戲管理工具
俗話說，工欲善其事，必先利其器。遊戲管理工具是對遊戲執行種的一系列問題處理的一種工具。它不僅是給開發人員用，大多是給運營是喲個。遊戲上線後，我們需要針對線上的問題進行不同的處理。不可能把所有問題都讓程式設計師去處理，於是程式設計師們想到了乙個辦法，做個工具，愛誰誰。
這個管理工具是乙個不斷增漲的系統，因為它很多時候是伴隨著遊戲種遇到的問題而實現的。
但是根據經驗，有些是必須有的，比如：
伺服器管理，主要負責伺服器的開啟，關閉，伺服器配置資訊，玩家資訊查詢；
玩家管理，比如踢人，封號；
統計查詢，玩家行為日誌查詢，統計查詢，次留率查詢，郵件服務，修改玩家資料等。
根據遊戲的不同需求，凡是可以通過工具實現的，都做到遊戲管理工具裡面。它是針對所有伺服器的管理。
乙個好的，全的遊戲管理工具，可以提高遊戲運營中遇到問題處理的效率，為玩家提供更好的服務。
7.公共服務元件
公共服務元件是為遊戲執行中提供公共的服務。例如：
充值伺服器，我們沒必要乙個服用乙個充值，而且也不能對外提供多個充值伺服器位址，和第三方公司對接，他們絕對不幹。
還有運營搞活動時的禮包碼；
還有註冊使用者的管理，玩家乙個註冊賬號可以進不同的區等。
這些都是對所有區服提供的服務，所以要單獨做，與遊戲邏輯分開，這樣方便管理，部署和負載均衡。
還有sdk登入驗證，現在手遊比較多，與渠道對接裡要進行驗證，這往往是很多http請求，速度慢，所以這個也要拿出來單獨做，不要在遊戲邏輯中去驗證，因為網路io的訪問時間是不可控制的，http是阻塞的請求。
所以，綜上來看，乙個遊戲伺服器起碼有幾個大的功能模組：
遊戲邏輯工程；
日誌處理工程；
充值工程；
遊戲管理工具工程；
使用者登入工程；
公共活動工程；
根據遊戲的不同需要，可能還有其他的。所在架構的設計中，一定要考慮到系統的分布式部署，，盡量把公共的功能拆出來做，這樣可以增強系統的可擴充套件性。
遊戲伺服器架構
登陸伺服器判斷賬戶合法性，如果合法的話，把session資訊寫入memcache,閘道器伺服器收到玩家連線請求後，在memcache裡查詢是否合法玩家，防止非法連線。閘道器伺服器要管理玩家連線，需要高併發，可以開多個 scene mgr純粹的 訊息功能 資料庫伺服器純粹的查詢修改資料功能，如果成為瓶...
遊戲伺服器架構
只是負責驗證使用者名稱和密碼，驗證之後返回token，token是有有效時間的，在有效時間內，並沒有保持連線的必要，所以，這裡的requestresponse可以做成短連線 http請求響應模式 提公升併發。如果超過了有效時間還沒有進入遊戲，令牌失效，在登入驗證時將被踢回重新獲取令牌。登入伺服器和閘...
遊戲伺服器架構概要
對伺服器軟體 硬體 執行的一體化規劃 問題 跨世界共享的功能？問題 公共服的單點故障 問題 邏輯處理和持久化資料在乙個物理機上 方案 資料庫獨立部署 熱備，log服分離 現狀 所有的雞蛋都在乙個籃子裡 方案 切分xysvr，讓多個scene分別服務於一些使用者，world負責拉取資料。並協調控制多s...