遊戲服務器架構

一些拓撲：

https://blog.csdn.net/to_be_better/article/details/56954500

 

登陸服務器

---

 https://github.com/cloudwu/skynet/wiki/LoginServer

https://github.com/cloudwu/skynet/wiki/MsgServer

只是負責驗證用戶名和密碼，驗證以後返回token，token是有有效時間的，在有效時間內，並無保持鏈接的必要，因此，這裏的RequestResponse能夠作成短鏈接（http請求響應模式），提高併發。


若是超過了有效時間尚未進入遊戲，令牌失效，在登陸驗證時將被踢回從新獲取令牌。


登陸服務器和網關之間須要有一個固定的鏈接傳遞新生成的令牌。

 

中心服務器

---

 

管理各類服務器
--------------------------
登記各類服務器
廣播各類服務器上線、下線
反映各服務器狀態

記錄最大在線人數
--------------------------
記錄各個服務器的在線（人數\鏈接數）

 

鏈接服務器（gateway）

---

 

 處理多鏈接的服務器

 

網關服務器

---

負責全部客戶端的長鏈接的維護。每個鏈接都會對應一個session，只有經過登陸驗證的session才能將報文傳入遊戲服務器羣的消息隊列中。沒驗證登陸的session須要發送以前從登陸服務器得到的token來驗證登陸。

token會和帳號綁定，一旦驗證經過，網關將通知遊戲服務器新玩家進入，遊戲服務器從數據庫讀取玩家的角色列表數據，再經過網關發送給客戶端。

上述的操做多是遊戲中最耗時的一步。因此可能增長的策略是異步推送，多人排隊等。

也能作這些用途：

客戶端發客戶端
轉發給各服務器
消息鏈接用的

做用不只僅是轉發了，同時也起到隔絕網絡的做用（反射代理）。 

 

組播

---

 https://blog.codingnow.com/2007/03/multicast.html

 

Profile

---

https://github.com/cloudwu/skynet/wiki/Profile

 

處理 TCP 的分包

在開發網絡遊戲時，咱們每每須要按傳統，把 TCP 鏈接上的數據流分割爲一個個數據包。將數據流轉換爲數據包，比較常見的作法是給數據包加一個長度信息，組裝在數據流中。

 

遊戲服務器

玩家確實進入遊戲以後，每個玩家都會有一個對應的Agent來維護。包括玩家的即時遊戲數據，存檔遊戲數據。全部與遊戲內容相關的都稱爲遊戲服務器。這部分的工做量將是遊戲開發過程當中最大的。


主要就是從網關發送的消息隊列中不斷讀取消息，而後進行處理。對於遊戲來講，整個世界是在一個循環體中的，因此首先確定會有一個大的世界循環體，而後是每一個Agent的存在更新。鑑於如今的網遊都沒有存檔的設計，全是數據統一入庫的，因此，Agent還須要負責玩家數據的持久化。我只打算作按期持久化，若是像王者那樣即時持久化，須要的代碼量和代碼的耦合讓人不太舒服。




須要的類庫
服務器內部的通信，消息隊列，由於沒有什麼須要持久化穩定之類的需求，速度能夠提上來，ZeroMQ是極好的。
數據庫仍是繼續使用MySQL

 

 http://blog.51cto.com/rangercyh/1673922

https://zhuanlan.zhihu.com/p/26252412