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