近年來，我身邊的朋友有很多都從web轉(zhuǎn)向了游戲開發(fā)。他們以前都沒有做過游戲服務(wù)器開發(fā)，更談不上什么經(jīng)驗，而從網(wǎng)上找的例子或游戲方面的知識，又是那么的少，那么的零散。當(dāng)他們進入游戲公司時，顯得一臉茫然。如果是大公司還好點，起碼有人帶帶，能學(xué)點經(jīng)驗，但是有些人是直接進入了小公司，甚至這些小公司只有他一個后臺。他們一肩扛起了公司的游戲后端的研發(fā)，也扛起了公司的成敗。他們也非常盡力，他們也想把游戲的后端做好�？墒蔷褪且驗闆]什么經(jīng)驗，剛開始時以為做游戲服務(wù)器和做web差不多，但是經(jīng)過一段時間之后，才發(fā)現(xiàn)代碼太多，太亂了，一看代碼都想重構(gòu)，都是踩著坑往前走。

這里我把一些游戲開發(fā)方面的東西整理一下，希望能對那些想做游戲服務(wù)器開發(fā)的朋友有所幫助。

首先，要明確一點，做游戲服務(wù)器開發(fā)和做傳統(tǒng)的web開發(fā)有著本質(zhì)的區(qū)別。游戲服務(wù)器開發(fā)，如果沒有經(jīng)驗，一開始根本沒有一個明確清析的目標(biāo)，不像web那樣，有些明確的MVC架構(gòu)，往往就是為了盡快滿足策劃的需求，盡快的實現(xiàn)功能，盡快能讓游戲跑起來。但是隨著功能越來越多，在老代碼上面修改的越來越頻繁，游戲測試時暴露出來的一堆bug，更讓人覺得束手無策，這個時候我們想到了重構(gòu)，想到了架構(gòu)的設(shè)計。

游戲的構(gòu)架設(shè)計非常重要，好的構(gòu)架代碼清析，責(zé)任明確，擴展性強，易調(diào)試。這些會為我們的開發(fā)省去不少時間。那要怎么樣設(shè)計游戲的構(gòu)架呢？可能每個游戲都不一樣，但是本質(zhì)上還是差不多的。

對于游戲服務(wù)器的構(gòu)架設(shè)計，我們首先要了解游戲的服務(wù)器構(gòu)架都有什么組成的？一款游戲到上線，需要具備哪些功能？有些人可能會說，只要讓游戲跑起來，訪問服務(wù)器不出問題不就行了嗎？答案是不行的，游戲構(gòu)架本身代表的是一個體系，它包括：

1. 系統(tǒng)初始化 
2. 游戲邏輯
3. 數(shù)據(jù)庫系統(tǒng)
4. 緩存系統(tǒng)
5. 游戲日志
6. 游戲管理工具
7. 公共服務(wù)組件

這一系統(tǒng)的東西都是不可少的，它們共同服務(wù)于游戲的整個運營過程。我們一點點來介紹各個系統(tǒng)的功能。

一，系統(tǒng)初始化

系統(tǒng)初始化是在沒有客戶端連接的時候，服務(wù)器啟動時所需要做的工作。基本上就是配置文件的讀取，初始化系統(tǒng)參數(shù)。

但是我們必須要考慮的是：

系統(tǒng)初始化需要的參數(shù)配置在哪兒，是配置在本地服務(wù)器，還是配置在數(shù)據(jù)庫；

服務(wù)器啟動的時候去數(shù)據(jù)庫��；

配置的修改需不需要重啟服務(wù)器等。

二，游戲邏輯

游戲邏輯是游戲的核心功能實現(xiàn)，也是整個游戲的服務(wù)中心，它被開發(fā)的好壞，直接決定了游戲服務(wù)器在運行中的性能。那在游戲邏輯的開發(fā)中我們要注意些什么呢？

游戲是一種網(wǎng)絡(luò)交互比較強的業(yè)務(wù)，好的底層通信，可以最大化游戲的性能，增加單臺服務(wù)器處理的同時在線人數(shù)，給游戲帶來更好的體驗，至少不容易出現(xiàn)因為網(wǎng)絡(luò)層導(dǎo)致的數(shù)據(jù)交互卡頓的現(xiàn)象。在這里我推薦使用Netty，它是目前最流行的NIO框架，它的用法可以在我之前的文章中查看，這里不再多說了。

有人疑問，代碼也需要分層次？這個是當(dāng)然了，不同的代碼，代表了不同的功能實現(xiàn)�，F(xiàn)在的開發(fā)語言都是面向?qū)ο蟮�，如果我們不加思考，不加整理的把功能代碼亂堆一起，起始看起來是快速實現(xiàn)了功能，但是到后期，如果要修改需求，或在原來的代碼上增加新的需求，那真是被自己打敗了。所以代碼一定要分層，主要有以下幾層：

1. 協(xié)議層，也叫前后臺交互層，它主要負(fù)責(zé)與前臺交互協(xié)議的解析和返回數(shù)據(jù)。在這一層基本上沒有什么業(yè)務(wù)邏輯實現(xiàn)。與前臺交互的數(shù)據(jù)都在這一層開始，也在這一層終止。比如你使用了Netty框架，那么Netty的ChannelHandlerContext即Ctx只能出現(xiàn)在這一層，他不能出現(xiàn)到游戲業(yè)務(wù)邏輯代碼的實現(xiàn)中，接收到客戶端的請求，在這一層把需要的參數(shù)解析出來，再把參數(shù)傳到業(yè)務(wù)邏輯方法中，業(yè)務(wù)邏輯方法處理完后，把要返回給客戶端的數(shù)據(jù)再返回到這一層，在這一層組織數(shù)據(jù)，返回給客戶端，這樣就可以把業(yè)務(wù)邏輯和網(wǎng)絡(luò)層分離，業(yè)務(wù)邏輯只關(guān)心業(yè)務(wù)實現(xiàn)，而且也方便對業(yè)務(wù)邏輯進行單元測試。
2. 業(yè)務(wù)邏輯層，這里處理真正的游戲邏輯，該計算價格計算價格，該通關(guān)的通關(guān)，該計時的計時。該保存數(shù)據(jù)的保存數(shù)據(jù)。但是這一層不直接操作緩存或數(shù)據(jù)庫，只是處理游戲邏輯計算。因為業(yè)務(wù)邏輯層是整個游戲事件的處理核心，所以他的處理是否正確直接決定游戲的正確性。所以這一層的代碼要盡量使用面向?qū)ο蟮姆椒ㄈ�實現(xiàn)。不要出現(xiàn)重復(fù)代碼或相似的功能進行復(fù)制粘貼，這樣修改起來非常不方便，可能是修改了某一處，而忘記了修改另外同樣的代碼。還要考慮每個方法都是可測試的，一個方法的行數(shù)最好不要超過一百行。另外，可以多看看設(shè)計模式的書，它可以幫助我們設(shè)計出靈活，整潔的代碼。

三，數(shù)據(jù)庫系統(tǒng)

數(shù)據(jù)庫是存儲數(shù)據(jù)庫的核心，但是游戲數(shù)據(jù)在存儲到數(shù)據(jù)庫的時候會經(jīng)過網(wǎng)絡(luò)和磁盤的IO,它的訪問速度相對于內(nèi)存來說是很慢的。一般來說，每次訪問數(shù)據(jù)庫都要和數(shù)據(jù)庫建立連接，訪問完成之后，為了節(jié)省數(shù)據(jù)庫的連接資源，要再把連接斷開。

這樣無形中又為服務(wù)器增加了開銷，在大量的數(shù)據(jù)訪問時，可能會更慢，而游戲又是要求低延時的，這時該怎么辦呢？我們想到了數(shù)據(jù)庫連接池，即把訪問數(shù)據(jù)庫的連接放到一個地方管理，用完我不斷開，用的時候去那拿，用完再放回去。這樣不用每次都建立新的連接了。

但是如果要我們自己去實現(xiàn)一套連接池管理組件的話，需要時間不說，對技術(shù)的把控也是一個考驗，還要再經(jīng)過測試等等，幸好互聯(lián)網(wǎng)開源的今天，有一些現(xiàn)成的可以使用，這里推薦Mybatis，即實現(xiàn)了代碼與SQL的分離，又有足夠的SQL編寫的靈活性，是一個不錯的選擇。

四，緩存系統(tǒng)

游戲中，客戶端與服務(wù)器的交互是要求低延遲的，延遲越低，用戶體驗越好。像之前說過的一樣，低延遲就是要求服務(wù)器處理業(yè)務(wù)盡量的快，客戶端一個請求過來，要在最短的時間內(nèi)響應(yīng)結(jié)果，最低不得超過500ms，因為加上來回的網(wǎng)絡(luò)傳輸耗時，基本上就是600ms-到700ms了，再長玩家就會覺得游戲卡了。

如果直接從數(shù)據(jù)庫中取數(shù)據(jù)，處理完之后再存回數(shù)據(jù)庫的話，這個性能是跟不上的。在服務(wù)器，數(shù)據(jù)在內(nèi)存中處理是最快的，所以我們要把一部分常用的數(shù)據(jù)提前加載到內(nèi)存中，比如說游戲數(shù)據(jù)配置表，經(jīng)常登陸的玩家數(shù)據(jù)等。這樣在處理業(yè)務(wù)時，就不用走數(shù)據(jù)庫了，直接從內(nèi)存中取就可以了，速度更快。

游戲中常見的緩存有兩種：

1. 直接把數(shù)據(jù)存儲在jvm或服務(wù)器內(nèi)存中
2. 使用第三方的緩存工具，這里推薦Redis，詳細(xì)的用法可以自己去查詢。

五，游戲日志

日志是個好東西呀，一個游戲中更不能少了日志，而且日志一定要記錄的詳細(xì)。它是玩家在整個游戲中的行為記錄，有了這個記錄，我們就可以分析玩家的行為，查找游戲的不足，在處理玩家在游戲中的問題時，日志也是一個良好的憑證和快速處理方式。

在游戲中，日志分為：

1. 系統(tǒng)日志，主要記錄游戲服務(wù)器的系統(tǒng)情況。比如：數(shù)據(jù)庫能否正常連接，服務(wù)器是否正常啟動，數(shù)據(jù)是否正常加載；
2. 玩家行為日志，比如玩家發(fā)送了什么請求，得到了什么物品，消費了多少貨幣等等；
3. 統(tǒng)計日志，這種日志是對游戲中所有玩家某種行為的一種統(tǒng)計，根據(jù)這個統(tǒng)計來分析大部分玩家的行為，得出一些共性或不同之處，以方法運營做不同的活動吸引用戶消費。

在構(gòu)架設(shè)計中，日志記錄一定要做為一種強制行為，因為不強制的話，可能由于某種原因某個功能忘記加日志了，那么當(dāng)這個功能出問題了，或者運營跟我們要這個功能的一些數(shù)據(jù)庫，就傻眼了。又得加需求，改代碼了。日志一定要設(shè)計一種良好的格式，日志記錄的數(shù)據(jù)要容易讀取，分解。日志行為可以用枚舉描述，在功能最后的處理方法里面加上這個枚舉做為參數(shù)，這樣不管誰在調(diào)用這個方法時，都要去加參數(shù)描述。

俗話說，工欲善其事，必先利其器。游戲管理工具是對游戲運行中的一系列問題處理的一種工具。它不僅是給開發(fā)人員用，大多數(shù)是給運營使用。游戲上線后，我們需要針對線上的問題進行不同的處理。不可能把所有問題都讓程序員去處理吧，于是程序員們想到了一個辦法，給你們做一個工具，你們愛誰處理誰處理去吧。

六， 游戲管理工具

游戲管理工具是一個不斷增漲的系統(tǒng)，因為它很多時候是伴隨著游戲中遇到的問題而實現(xiàn)的。

但是根據(jù)經(jīng)驗，有一些功能是必須有的，比如：

• 服務(wù)器管理，主要負(fù)責(zé)服務(wù)器的開啟，關(guān)閉，服務(wù)器配置信息，玩家信息查詢；
• 玩家管理，比如踢人，封號；
• 統(tǒng)計查詢，玩家行為日志查詢，統(tǒng)計查詢，次留率查詢，郵件服務(wù)，修改玩家數(shù)據(jù)等。

根據(jù)游戲的不同要求，凡是可以能過工具實現(xiàn)的，都做到游戲管理工具里面。它是針對所有服務(wù)器的管理。

一個好的，全的游戲管理工具，可以提高游戲運營中遇到問題處理的效率，為玩家提供更好的服務(wù)。

七，公共組件

公共組件是為游戲運行中提供公共的服務(wù)。例如：

• 充值服務(wù)器，我們沒必須一個服用一個充值，而且你也不能對外提供多個充值服務(wù)器地址，和第三方公司對接，他們絕對不干，這是要瘋呀；
• 還有運營搞活動時的禮包碼；
• 還有注冊用戶的管理，玩家一個注冊賬號可以進不同的區(qū)等。

這些都是針對所有區(qū)服提供的服務(wù)，所以要單獨做，與游戲邏輯分開，這樣方便管理，部署和負(fù)載均衡。

還有SDK的登陸驗證，現(xiàn)在手游比較多，與渠道對接里要進行驗證，這往往是很多http請求，速度慢，所以這個也要拿出來單獨做，不要在游戲邏輯中去驗證，因為網(wǎng)絡(luò)IO的訪問時間是不可控制的，http是阻塞的請求。

所以，綜上來看，一個游戲服務(wù)器起碼有幾個大的功能模塊組成：

• 游戲邏輯工程；
• 日志處理工程；
• 充值工程；
• 游戲管理工具工程；
• 用戶登陸工程；
• 公共活動工程等。

根據(jù)游戲的不同需要，可能還有其它的。所在構(gòu)架的設(shè)計中，一定要考慮到系統(tǒng)的分布式部署，盡量把公共的功能拆出來做，這樣可以增強系統(tǒng)的可擴展性。

服務(wù)器端開發(fā)的一些建議

本文作為游戲服務(wù)器端開發(fā)的基本大綱，是游戲?qū)嵺`開發(fā)中的總結(jié)。

第一部分 —— 專業(yè)基礎(chǔ)，用于指導(dǎo)招聘和實習(xí)考核；

第二部分 —— 游戲入門，講述游戲服務(wù)器端開發(fā)的基本要點；

第三部分 —— 服務(wù)端架構(gòu)，介紹架構(gòu)設(shè)計中的一些基本原則。

希望能幫到大家！

一、專業(yè)基礎(chǔ)

1.1網(wǎng)絡(luò)

1.1.1理解TCP/IP協(xié)議

網(wǎng)絡(luò)傳輸模型

滑動窗口技術(shù)

建立連接的三次握手與斷開連接的四次握手

連接建立與斷開過程中的各種狀態(tài)

TCP/IP協(xié)議的傳輸效率

思考：

請解釋DOS攻擊與DRDOS攻擊的基本原理

一個100Byte數(shù)據(jù)包，精簡到50Byte, 其傳輸效率提高了50%

TIMEWAIT狀態(tài)怎么解釋？

1.1.2掌握常用的網(wǎng)絡(luò)通信模型

Select

Epoll，邊緣觸發(fā)與平臺出發(fā)點區(qū)別與應(yīng)用

Select與Epoll的區(qū)別及應(yīng)用

1.2存儲

• 計算機系統(tǒng)存儲體系
• 程序運行時的內(nèi)存結(jié)構(gòu)
• 計算機文件系統(tǒng)，頁表結(jié)構(gòu)
• 內(nèi)存池與對象池的實現(xiàn)原理，應(yīng)用場景與區(qū)別
• 關(guān)系數(shù)據(jù)庫MySQL的使用
• 共享內(nèi)存

1.3程序

1. 對C/C++語言有較深的理解
2. 深刻理解接口，封裝與多態(tài)，并且有實踐經(jīng)驗
3. 深刻理解常用的數(shù)據(jù)結(jié)構(gòu)：數(shù)組，鏈表，二叉樹，哈希表
4. 熟悉常用的算法及相關(guān)復(fù)雜度：冒泡排序，快速排序

二、游戲開發(fā)入門

2.1防御式編程

不要相信客戶端數(shù)據(jù)，一定要檢驗。作為服務(wù)器端你無法確定你的客戶端是誰，你也不能假定它是善意的，請做好自我保護。(這是判斷一個服務(wù)器端程序員是否入門的基本標(biāo)準(zhǔn))

務(wù)必對于函數(shù)的傳人參數(shù)和返回值進行合法性判斷，內(nèi)部子系統(tǒng)，功能模塊之間不要太過信任，要求低耦合，高內(nèi)聚。

插件式的模塊設(shè)計，模塊功能的健壯性應(yīng)該是內(nèi)建的，盡量減少模塊間耦合。

2.2設(shè)計模式

道法自然。不要迷信，迷戀設(shè)計模式，更不要生搬硬套

簡化，簡化，再簡化，用最簡單的辦法解決問題

借大寶一句話：設(shè)計本天成，妙手偶得之

2.3網(wǎng)絡(luò)模型

自造輪子: Select, Epoll， Epoll一定比Select高效嗎？

開源框架: Libevent, libev, ACE。

2.4數(shù)據(jù)持久化

• 自定義文件存儲，如《夢幻西游》
• 關(guān)系數(shù)據(jù)庫: MySQL
• NO-SQL數(shù)據(jù)庫: MongoDB
• 選擇存儲系統(tǒng)要考慮到因素：穩(wěn)定性，性能，可擴展性

2.5內(nèi)存管理

• 使用內(nèi)存池和對象池，禁止運行期間動態(tài)分配內(nèi)存
• 對于輸入輸出的指針參數(shù)，嚴(yán)格檢查，寧濫勿缺
• 寫內(nèi)存保護，使用帶內(nèi)存保護的函數(shù)(strncpy, memcpy, snprintf, vsnprintf等)
• 嚴(yán)防數(shù)組下標(biāo)越界
• 防止讀內(nèi)存溢出，確保字符串以\  0 結(jié)束

2.6日志系統(tǒng)

• 簡單高效，大量日志操作不應(yīng)該影響程序性能
• 穩(wěn)定，做到服務(wù)器崩潰是日志不丟失
• 完備，玩家關(guān)鍵操作一定要記日志，理想的情況是通過日志能重建任何時刻的玩家數(shù)據(jù)
• 開關(guān)，開發(fā)日志的要加級別開關(guān)控制

2.7通信協(xié)議

• 采用PDL(Protocol Design Language)， 如Protobuf，可以同時生成前后端代碼，減少前后端協(xié)議聯(lián)調(diào)成本， 擴展性好
• JSON，文本協(xié)議，簡單，自解釋，無聯(lián)調(diào)成本，擴展性好，也很方便進行包過濾以及寫日志
• 自定義二進制協(xié)議，精簡，有高效的傳輸性能，完全可控，幾乎無擴展性

2.8全局唯一Key（GUID）

• 為合服做準(zhǔn)備
• 方便追蹤道具，裝備流向
• 每個角色，裝備，道具都應(yīng)對應(yīng)有全局唯一Key

2.9多線程與同步

• 消息隊列進行同步化處理

2.10狀態(tài)機

• 強化角色的狀態(tài)
• 前置狀態(tài)的檢查校驗

2.11數(shù)據(jù)包操作

• 合并, 同一幀內(nèi)的數(shù)據(jù)包進行合并，減少IO操作次數(shù)
• 單副本, 用一個包盡量只保存一份，減少內(nèi)存復(fù)制次數(shù)
• AOI同步中減少中間過程無用數(shù)據(jù)包

2.12狀態(tài)監(jiān)控

• 隨時監(jiān)控服務(wù)器內(nèi)部狀態(tài)
• 內(nèi)存池，對象池使用情況
• 幀處理時間
• 網(wǎng)絡(luò)IO
• 包處理性能
• 各種業(yè)務(wù)邏輯的處理次數(shù)

2.13包頻率控制

• 基于每個玩家每條協(xié)議的包頻率控制，癱瘓變速齒輪

2.14開關(guān)控制

• 每個模塊都有開關(guān)，可以緊急關(guān)閉任何出問題的功能模塊

2.15反外掛反作弊

• 包頻率控制可以消滅變速齒輪
• 包id自增校驗，可以消滅WPE
• 包校驗碼可以消滅或者攔截篡改的包
• 圖形識別碼，可以踢掉99%非人的操作
• 魔高一尺，道高一丈

2.16熱更新

• 核心配置邏輯的熱更新，如防沉迷系統(tǒng)，包頻率控制，開關(guān)控制等
• 代碼基本熱更新，如Erlang，Lua等

2.17防刷

• 關(guān)鍵系統(tǒng)資源（如元寶，精力值，道具，裝備等）的產(chǎn)出記日志
• 資源的產(chǎn)出和消耗盡量依賴兩個或以上的獨立條件的檢測
• 嚴(yán)格檢查各項操作的前置條件
• 校驗參數(shù)合法性

2.18防崩潰

• 系統(tǒng)底層與具體業(yè)務(wù)邏輯無關(guān)，可以用大量的機器人壓力測試暴露各種bug，確保穩(wěn)定
• 業(yè)務(wù)邏輯建議使用腳本
• 系統(tǒng)性的保證游戲不會崩潰

2.19性能優(yōu)化

• IO操作異步化
• IO操作合并緩寫 （事務(wù)性的提交db操作，包合并，文件日志緩寫）
• Cache機制
• 減少競態(tài)條件 (避免頻繁進出切換，盡量減少鎖定使用，多線程不一定由于單線程) 多線程不一定比單線程快
• 減少內(nèi)存復(fù)制
• 自己測試，用數(shù)據(jù)說話，別猜

2.20運營支持

• 接口支持：實時查詢，控制指令，數(shù)據(jù)監(jiān)控，客服處理等
• 實現(xiàn)考慮提供http接口

2.21容災(zāi)與故障預(yù)案

略

三、服務(wù)器端架構(gòu)

3.1什么是好的架構(gòu)？

• 滿足業(yè)務(wù)要求
• 能迅速的實現(xiàn)策劃需求，響應(yīng)需求變更
• 系統(tǒng)級的穩(wěn)定性保障
• 簡化開發(fā)。將復(fù)雜性控制在架構(gòu)底層，降低對開發(fā)人員的技術(shù)要求，邏輯開發(fā)不依賴于開發(fā)人員本身強大的技術(shù)實力，提高開發(fā)效率
• 完善的運營支撐體系

3.2架構(gòu)實踐的思考

• 簡單，滿足需求的架構(gòu)就是好架構(gòu)
• 設(shè)計性能，抓住重要的20%， 沒必要從程序代碼里面去摳性能
• 熱更新是必須的
• 人難免會犯錯，盡可能的用一套機制去保障邏輯的健壯性

游戲服務(wù)器的設(shè)計是一項頗有挑戰(zhàn)性的工作，游戲服務(wù)器的發(fā)展也由以前的單服結(jié)構(gòu)轉(zhuǎn)變?yōu)槎喾�機構(gòu)，甚至出現(xiàn)了bigworld引擎的分布式解決方案，最近了解到Unreal的服務(wù)器解決方案atlas也是基于集群的方式。

負(fù)載均衡是一個很復(fù)雜的課題，這里暫不談bigworld和atlas的這類服務(wù)器的設(shè)計，更多的是基于功能和場景劃分服務(wù)器結(jié)構(gòu)。

首先說一下思路，服務(wù)器劃分基于以下原則：

1. 分離游戲中占用系統(tǒng)資源（cpu，內(nèi)存，IO等）較多的功能，獨立成服務(wù)器。
2. 在同一服務(wù)器架構(gòu)下的不同游戲，應(yīng)盡可能的復(fù)用某些服務(wù)器（進程級別的復(fù)用）。
3. 以多線程并發(fā)的編程方式適應(yīng)多核處理器。
4. 寧可在服務(wù)器之間多復(fù)制數(shù)據(jù)，也要保持清晰的數(shù)據(jù)流向。
5. 主要按照場景劃分進程，若需按功能劃分，必須保持整個邏輯足夠的簡單，并滿足以上1，2點。

服務(wù)器結(jié)構(gòu)圖：

各個服務(wù)器的簡要說明：

1. Gateway 是應(yīng)用網(wǎng)關(guān)，主要用于保持和client的連接，該服務(wù)器需要2種IO：
2. 對client采用高并發(fā)連接，低吞吐量的網(wǎng)絡(luò)模型，如IOCP等

對服務(wù)器采用高吞吐量連接，如阻塞或異步IO。

網(wǎng)關(guān)主要有以下用途：

• 分擔(dān)了網(wǎng)絡(luò)IO資源，同時，也分擔(dān)了網(wǎng)絡(luò)消息包的加解密，壓縮解壓等cpu密集的操作。
• 隔離了client和內(nèi)部服務(wù)器組，對client來說，它只需要知道網(wǎng)關(guān)的相關(guān)信息即可（ip和port）。client由于一直和網(wǎng)關(guān)保持常連接，所以切換場景服務(wù)器等操作對client來說是透明的。
• 維護玩家登錄狀態(tài)。

World Server 是一個控制中心，它負(fù)責(zé)把各種計算資源分布到各個服務(wù)器，它具有以下職責(zé)：

• 管理和維護多個Scene Server。
• 管理和維護多個功能服務(wù)器，主要是同步數(shù)據(jù)到功能服務(wù)器。
• 復(fù)雜轉(zhuǎn)發(fā)其他服務(wù)器和Gateway之間的數(shù)據(jù)。
• 實現(xiàn)其他需要跨場景的功能，如組隊，聊天，幫派等。

Phys Server 主要用于玩家移動，碰撞等檢測。

所有玩家的移動類操作都在該服務(wù)器上做檢查，所以該服務(wù)器本身具備所有地圖的地形等相關(guān)信息。具體檢查過程是這樣的：首先，Worldserver收到一個移動信息，WorldServer收到后向Phys Server請求檢查，Phys Server檢查成功后再返回給world Server，然后world server傳遞給相應(yīng)的Scene Server。

Scene Server場景服務(wù)器，按場景劃分，每個服務(wù)器負(fù)責(zé)的場景應(yīng)該是可以配置的。理想情況下是可以動態(tài)調(diào)節(jié)的。

ItemMgr Server 物品管理服務(wù)器，負(fù)責(zé)所有物品的生產(chǎn)過程。在該服務(wù)器上存儲一個物品掉落數(shù)據(jù)庫，服務(wù)器初始化的時候載入到內(nèi)存。任何需要產(chǎn)生物品的服務(wù)器均與該服務(wù)器直接通信。

AIServer 又一個功能服務(wù)器，負(fù)責(zé)管理所有NPC的AI。AI服務(wù)器通常有2個輸入：

• 一個是Scene Server發(fā)送過來的玩家相關(guān)操作信息
• 另一個時鐘Timer驅(qū)動

在這個設(shè)計中，對其他服務(wù)器來說，AIServer就是一個擁有很多個NPC的客戶端。AIserver需要同步所有與AI相關(guān)的數(shù)據(jù)，包括很多玩家數(shù)據(jù)。由于AIServer的Timer驅(qū)動特性，可在很大程度上使用TBB程序庫來發(fā)揮多核的性能。

把網(wǎng)絡(luò)游戲服務(wù)器分拆成多個進程，分開部署。

• 這種設(shè)計的好處是模塊自然分離，可以單獨設(shè)計。分擔(dān)負(fù)荷，可以提高整個系統(tǒng)的承載能力。
• 缺點在于，網(wǎng)絡(luò)環(huán)境并不那么可靠。跨進程通訊有一定的不可預(yù)知性。服務(wù)器間通訊往往難以架設(shè)調(diào)試環(huán)境，并很容易把事情攪成一團糨糊。而且正確高效的管理多連接，對程序員來說也是一項挑戰(zhàn)。

前些年，我也曾寫過好幾篇與之相關(guān)的設(shè)計。這幾天在思考一個問題：如果我們要做一個底層通用模塊，讓后續(xù)開發(fā)更為方便。到底要解決怎樣的需求？這個需求應(yīng)該是單一且基礎(chǔ)的，每個應(yīng)用都需要的。

正如 TCP 協(xié)議解決了互聯(lián)網(wǎng)上穩(wěn)定可靠的點對點數(shù)據(jù)流通訊一樣。游戲世界實際需要的是一個穩(wěn)定可靠的在游戲系統(tǒng)內(nèi)的點對點通訊需要。

我們可以在一條 TCP 連接之上做到這一點。一旦實現(xiàn)，可以給游戲服務(wù)的開發(fā)帶來極大的方便。

可以把游戲系統(tǒng)內(nèi)的各項服務(wù)，包括并不限于登陸，拍賣，戰(zhàn)斗場景，數(shù)據(jù)服務(wù)，等等獨立服務(wù)看成網(wǎng)絡(luò)上的若干終端。每個玩家也可以是一個獨立終端。它們一起構(gòu)成一個網(wǎng)絡(luò)。在這個網(wǎng)絡(luò)之上，終端之間可以進行可靠的連接和通訊。

實現(xiàn)可以是這樣的：

• 每個虛擬終端都在游戲虛擬網(wǎng)絡(luò)(Game Network)上有一個唯一地址 (Game Network Address , GNA) 。這個地址可以預(yù)先設(shè)定，也可以動態(tài)分配。每個終端都可以通過游戲網(wǎng)絡(luò)的若干接入點 ( GNAP ) 通過唯一一條 TCP 連接接入網(wǎng)絡(luò)。
• 接入過程需要通過鑒權(quán)。
• 鑒權(quán)過程依賴內(nèi)部的安全機制，可以包括密碼證書，或是特別的接入點區(qū)分。（例如，玩家接入網(wǎng)絡(luò)就需要特定的接入點，這個接入點接入的終端都一定是玩家）
• 鑒權(quán)通過后，網(wǎng)絡(luò)為終端分配一個固定的游戲域名。例如，玩家進入會分配到 player.12345 這樣的域名，數(shù)據(jù)庫接入可能分配到 database 。
• 游戲網(wǎng)絡(luò)默認(rèn)提供一個域名查詢服務(wù)（這個服務(wù)可以通過鑒權(quán)的過程注冊到網(wǎng)絡(luò)中），讓每個終端都能通過域名查詢到對應(yīng)的地址。
• 然后，游戲網(wǎng)絡(luò)里所有合法接入的終端都可以通過其地址相互發(fā)起連接并通訊了。
• 整個協(xié)議建立在 TCP 協(xié)議之上，工作于唯一的這個 TCP 連接上。和直接使用 TCP 連接不同。游戲網(wǎng)絡(luò)中每個終端之間相互發(fā)起連接都是可靠的。不僅玩家可以向某個服務(wù)發(fā)起連接，反過來也是可以的。玩家之間的直接連接也是可行的（是否允許這樣，取決于具體設(shè)計）。
• 由于每個虛擬連接都是建立在單一的 TCP 連接之上。所以減少了互連網(wǎng)上發(fā)起 TCP 連接的各種不可靠性。鑒權(quán)過程也是一次性唯一的。
• 并且我們提供域名反查服務(wù)，我們的游戲服務(wù)可以清楚且安全的知道連接過來的是誰。
• 系統(tǒng)可以設(shè)計為，游戲網(wǎng)絡(luò)上每個終端離網(wǎng)，域名服務(wù)將廣播這條消息，通知所有人。這種廣播服務(wù)在互聯(lián)網(wǎng)上難以做到，但無論是廣播還是組播，在這個虛擬游戲網(wǎng)絡(luò)中都是可行的。
• 在這種設(shè)計上。在邏輯層面，我們可以讓玩家直接把聊天信息從玩家客互端發(fā)送到聊天服務(wù)器，而不需要建立多余的 TCP 連接，也不需要對轉(zhuǎn)發(fā)處理聊天消息做多余的處理。聊天服務(wù)器可以獨立的存在于游戲網(wǎng)絡(luò)。也可以讓廣播服務(wù)主動向玩家推送消息，由服務(wù)器向玩家發(fā)起連接，而不是所有連接請求都是由玩家客互端發(fā)起。
• 虛擬游戲網(wǎng)絡(luò)的構(gòu)成是一個獨立的層次，完全可以撇開具體游戲邏輯來實現(xiàn)，并能夠單獨去按承載量考慮具體設(shè)計方案。非常利于剝離出具體游戲項目來開發(fā)并優(yōu)化。
• 最終，我們或許需要的一套 C 庫，用于游戲網(wǎng)絡(luò)內(nèi)的通訊。api 可以和 socket api 類似。額外多兩條接入與離開游戲網(wǎng)絡(luò)即可。

天下數(shù)據(jù)IDC提供香港服務(wù)器、美國服務(wù)器等全球海外服務(wù)器租用托管，是區(qū)域鏈、直銷、流媒體、外貿(mào)、游戲等服務(wù)器解決方案首選品牌。天下數(shù)據(jù)已為多家企業(yè)提供區(qū)塊鏈服務(wù)器租用托管解決方案，為他們的區(qū)塊鏈安全提供支持！具體詳詢在線客服！

本文鏈接：http://m.51huadong.com/servernews/11002120.html