Posted on 2011-01-19 14:41
點(diǎn)點(diǎn)滴滴 閱讀(1426)
評(píng)論(0) 編輯 收藏 引用 所屬分類:
10 服務(wù)器
如果我們就此打住，可能馬上就會(huì)有人要嗤之以鼻了，就這點(diǎn)古董級(jí)的技術(shù)也敢出來現(xiàn)。好吧，我們還是把之前留下的問題拿出來解決掉吧。
一般來說，當(dāng)某一部分能力達(dá)不到我們的要求時(shí)，最簡單的解決方法就是在此多投入一點(diǎn)資源。既然想要更多的連接數(shù)，那就再加一臺(tái)網(wǎng)關(guān)服務(wù)器吧。新增加了網(wǎng)關(guān)服后需要在大區(qū)服上做相應(yīng)的支持，或者再簡單點(diǎn)，有一臺(tái)主要的網(wǎng)關(guān)服，當(dāng)其負(fù)載較高時(shí)，主動(dòng)將新到達(dá)的連接重定向到其他網(wǎng)關(guān)服上。
而對(duì)于游戲服來說，有一臺(tái)還是多臺(tái)網(wǎng)關(guān)服是沒有什么區(qū)別的。每個(gè)代表客戶端玩家的對(duì)象內(nèi)部都保留一個(gè)代表其連接的對(duì)象，消息廣播時(shí)要求每個(gè)玩家對(duì)象使用自己的連接對(duì)象發(fā)送數(shù)據(jù)即可，至于連接是在什么地方，那是完全透明的。當(dāng)然，這只是一種簡單的實(shí)現(xiàn)，也是普通使用的一種方案，如果后期想對(duì)消息廣播做一些優(yōu)化的話，那可能才需要多考慮一下。
既然說到了優(yōu)化，我們也稍稍考慮一下現(xiàn)在結(jié)構(gòu)下可能采用的優(yōu)化方案。
首先是當(dāng)前的Zone Server要做的事情太多了，以至于他都處理不了多少連接。這其中最消耗系統(tǒng)資源的當(dāng)屬生物的AI處理了，尤其是那些復(fù)雜的尋路算法，所以我們可以考慮把這部分AI邏輯獨(dú)立出來，由一臺(tái)單獨(dú)的AI服務(wù)器來承擔(dān)。
然后，我們可以試著把一些與地圖數(shù)據(jù)無關(guān)的公共邏輯放到Master Server上去實(shí)現(xiàn)，這樣Zone Server上只保留了與地圖數(shù)據(jù)緊密相關(guān)的邏輯，如生物管理，玩家移動(dòng)和狀態(tài)更新等。
還有聊天處理邏輯，這部分與游戲邏輯沒有任何關(guān)聯(lián)，我們也完全可以將其獨(dú)立出來，放到一臺(tái)單獨(dú)的聊天服務(wù)器上去實(shí)現(xiàn)。
最后是數(shù)據(jù)庫了，為了減輕數(shù)據(jù)庫的壓力，提高數(shù)據(jù)請(qǐng)求的響應(yīng)速度，我們可以在數(shù)據(jù)庫之前建立一個(gè)數(shù)據(jù)庫緩存服務(wù)器，將一些常用數(shù)據(jù)緩存在此，服務(wù)器與數(shù)據(jù)庫的通信都要通過這臺(tái)服務(wù)器進(jìn)行代理。緩存的數(shù)據(jù)會(huì)定時(shí)的寫入到后臺(tái)數(shù)據(jù)庫中。
好了，做完這些優(yōu)化我們的服務(wù)器結(jié)構(gòu)大體也就定的差不多了，暫且也不再繼續(xù)深入，更細(xì)化的內(nèi)容等到各個(gè)部分實(shí)現(xiàn)的時(shí)候再探討。
好比我們?nèi)タ匆粓?chǎng)晚會(huì)，舞臺(tái)上演員們按著預(yù)定的節(jié)目單有序地上演著，但這就是整場(chǎng)晚會(huì)的全部嗎？顯然不止，在幕后還有太多太多的人在忙碌著，甚至在晚會(huì)前和晚會(huì)后都有。我們的游戲服務(wù)器也如此。
在之前描述的部分就如同舞臺(tái)上的演員，是我們能直接看到的，幕后的工作人員我們也來認(rèn)識(shí)一下。
現(xiàn)實(shí)中有警察來維護(hù)秩序，游戲中也如此，這就是我們常說的GM。GM可以采用跟普通玩家一樣的拉入方式來進(jìn)入游戲，當(dāng)然權(quán)限會(huì)比普通玩家高一些，也可以提供一臺(tái)GM服務(wù)器專門用來處理GM命令，這樣可以有更高的安全性，GM服一般接在中心服務(wù)器上。
在以時(shí)間收費(fèi)的游戲中，我們還需要一臺(tái)計(jì)費(fèi)的服務(wù)器，這臺(tái)服務(wù)器一般接在網(wǎng)關(guān)服務(wù)器上，注冊(cè)玩家登錄和退出事件以記錄玩家的游戲時(shí)間。
任何為用戶提供服務(wù)的地方都會(huì)有日志記錄，游戲服務(wù)器當(dāng)然也不例外。從記錄玩家登錄的時(shí)間，地址，機(jī)器信息到游戲過程中的每一項(xiàng)操作都可以作為日志記錄下來，以備查錯(cuò)及數(shù)據(jù)挖掘用。至于搜集玩家機(jī)器資料所涉及到的法律問題不是我們?cè)摽紤]的。
差不多就這么多了吧，接下來我們會(huì)按照這個(gè)大致的結(jié)構(gòu)來詳細(xì)討論各部分的實(shí)現(xiàn)。
再強(qiáng)調(diào)一下，服務(wù)器結(jié)構(gòu)本無所謂好壞，只有是否適合自己。我們?cè)谇懊嫣接懥艘恍┰诂F(xiàn)在的游戲中見到過的結(jié)構(gòu)，并盡我所知地分析了各自存在的一些問題和可以做的一些改進(jìn)，希望其中沒有謬誤，如果能給大家也帶來些啟發(fā)那自然更好。
突然發(fā)現(xiàn)自己一旦羅嗦起來還真是沒完沒了。接下來先說說我在開發(fā)中遇到過的一些困惑和一基礎(chǔ)問題探討吧，這些問題可能有人與我一樣，也曾遇到過，或者正在被困擾中，而所要探討的這些基礎(chǔ)問題向來也是爭論比較多的，我們也不評(píng)價(jià)其中的好與壞，只做簡單的描述。
首先是服務(wù)器操作系統(tǒng)，linux與windows之爭隨處可見，其實(shí)在大多數(shù)情況下這不是我們所能決定的，似乎各大公司也基本都有了自己的傳統(tǒng)，如網(wǎng)易的freebsd，騰訊的linux等。如果真有權(quán)利去選擇的話，選自己最熟悉的吧。
決定了OS也就基本上確定了網(wǎng)絡(luò)IO模型，windows上的IOCP和linux下的epool，或者直接使用現(xiàn)有的網(wǎng)絡(luò)框架，如ACE和asio等，其他還有些商業(yè)的網(wǎng)絡(luò)庫在國內(nèi)的使用好像沒有見到，不符合中國國情嘛。:)
然后是網(wǎng)絡(luò)協(xié)議的選擇，以前的選擇大多傾向于UDP，為了可靠傳輸一般自己都會(huì)在上面實(shí)現(xiàn)一層封裝，而現(xiàn)在更普通的是直接采用本身就很可靠的TCP，或者TCP與UDP的混用。早期選擇UDP的主要原因還是帶寬限制，現(xiàn)在寬帶普通的情況下TCP比UDP多出來的一點(diǎn)點(diǎn)開銷與開發(fā)的便利性相比已經(jīng)不算什么了。當(dāng)然，如果已有了成熟的可靠UDP庫，那也可以繼續(xù)使用著。
還有消息包格式的定義，這個(gè)曾在云風(fēng)的blog上展開過激烈的爭論。消息包格式定義包括三段，包長、消息碼和包體，爭論的焦點(diǎn)在于應(yīng)該是消息碼在前還是包長在前，我們也把這個(gè)當(dāng)作是信仰問題吧，有興趣的去云風(fēng)的blog上看看，論論。
另外早期有些游戲的包格式定義是以特殊字符作分隔的，這樣一個(gè)好處是其中某個(gè)包出現(xiàn)錯(cuò)誤后我們的游戲還能繼續(xù)。但實(shí)際上，我覺得這是完全沒有必要的，真要出現(xiàn)這樣的錯(cuò)誤，直接斷開這個(gè)客戶端的連接可能更安全。而且，以特殊字符做分隔的消息包定義還加大了一點(diǎn)點(diǎn)網(wǎng)絡(luò)數(shù)據(jù)量。
最后是一個(gè)純技術(shù)問題，有關(guān)socket連接數(shù)的最大限制。開始學(xué)習(xí)網(wǎng)絡(luò)編程的時(shí)候我犯過這樣的錯(cuò)誤，以為port的定義為unsigned short，所以想當(dāng)然的認(rèn)為服務(wù)器的最大連接數(shù)為65535，這會(huì)是一個(gè)硬性的限制。而實(shí)際上，一個(gè)socket描述符在windows上的定義是unsigned int，因此要有限制那也是四十多億，放心好了。
在服務(wù)器上port是監(jiān)聽用的，想象這樣一種情況，web server在80端口上監(jiān)聽，當(dāng)一個(gè)連接到來時(shí)，系統(tǒng)會(huì)為這個(gè)連接分配一個(gè)socket句柄，同時(shí)與其在80端口上進(jìn)行通訊；當(dāng)另一個(gè)連接到來時(shí)，服務(wù)器仍然在80端口與之通信，只是分配的socket句柄不一樣。這個(gè)socket句柄才是描述每個(gè)連接的唯一標(biāo)識(shí)。按windows網(wǎng)絡(luò)編程第二版上的說法，這個(gè)上限值配置影響。