【正文】 有！所以在我們今后所要討論的內(nèi)容中，盡量會避免出現(xiàn)直接的代碼，在有些地方確實需要代碼來表述時，也將會選擇使用偽碼。服務(wù)器公共組件實現(xiàn)mangos的游戲主循環(huán)當閱讀一項工程的源碼時，我們大概會選擇從main函數(shù)開始，而當開始一項新的工程時，第一個寫下的函數(shù)大多也是main。確實是太簡單了，不過簡單的結(jié)構(gòu)正好更適合我們來看一看游戲服務(wù)器內(nèi)部的模塊結(jié)構(gòu)，以及一些服務(wù)器共有組件的實現(xiàn)方法。登錄服將從大區(qū)服上獲取到的游戲世界列表發(fā)給已驗證通過的客戶端即可。這個列表的狀態(tài)要定時刷新，可能有新的游戲世界開放了，也可能有些游戲世界非常不幸地停止運轉(zhuǎn)了，這些狀態(tài)的變化都要盡可能及時地讓玩家知道。不過其代碼實現(xiàn)步驟倒是并不復雜，mangos中的代碼也還算清晰，我們也不再贅述。wow使用的是第6版，也就是SRP6算法。很幸運的是，偉大的數(shù)學字們早就為我們準備好了很多優(yōu)秀的這類算法，而且經(jīng)理論和實踐都證明他們也確實是足夠安全的。嗯，這個問題好解決，我們不要用固定的算法進行散列就是了。噢，不要管那個王小云的什么論文，如果我真有那么好的運氣，早中500w了，還用在這考慮該死的服務(wù)器設(shè)計嗎？似乎是一個很完美的方案，外掛制作者再也偷不到我們的密碼了。用戶在登錄時發(fā)送給服務(wù)器的是明文的帳號和經(jīng)散列后的不可逆密碼串，服務(wù)器取出密碼后也用同樣的算法進行散列后再進行比較。既然是一個可逆的過程，那外掛制作者總有辦法知道我們的加密過程，所以，這個方法仍不夠安全。這個方法存在的安全隱患實在太大，明文的密碼傳輸太容易被截獲了。為了便于描述，我們暫不引入那些討論過的優(yōu)化手段，先以最簡單的方式實現(xiàn)，另外也將基本以mangos的代碼作為參考來進行描述。好了，廢話說完了，下一篇，我們開始進入登錄服的設(shè)計吧。這個socket句柄才是描述每個連接的唯一標識。而實際上，一個socket描述符在windows上的定義是unsigned int，因此要有限制那也是四十多億，放心好了。最后是一個純技術(shù)問題，有關(guān)socket連接數(shù)的最大限制。但實際上，我覺得這是完全沒有必要的，真要出現(xiàn)這樣的錯誤，直接斷開這個客戶端的連接可能更安全。消息包格式定義包括三段，包長、消息碼和包體，爭論的焦點在于應(yīng)該是消息碼在前還是包長在前，我們也把這個當作是信仰問題吧，有興趣的去云風的blog上看看，論論。當然，如果已有了成熟的可靠UDP庫，那也可以繼續(xù)使用著。:)然后是網(wǎng)絡(luò)協(xié)議的選擇，以前的選擇大多傾向于UDP，為了可靠傳輸一般自己都會在上面實現(xiàn)一層封裝，而現(xiàn)在更普通的是直接采用本身就很可靠的TCP，或者TCP與UDP的混用。如果真有權(quán)利去選擇的話，選自己最熟悉的吧。接下來先說說我在開發(fā)中遇到過的一些困惑和一基礎(chǔ)問題探討吧，這些問題可能有人與我一樣，也曾遇到過，或者正在被困擾中，而所要探討的這些基礎(chǔ)問題向來也是爭論比較多的，我們也不評價其中的好與壞，只做簡單的描述。我們在前面探討了一些在現(xiàn)在的游戲中見到過的結(jié)構(gòu)，并盡我所知地分析了各自存在的一些問題和可以做的一些改進，希望其中沒有謬誤，如果能給大家也帶來些啟發(fā)那自然更好。差不多就這么多了吧，接下來我們會按照這個大致的結(jié)構(gòu)來詳細討論各部分的實現(xiàn)。從記錄玩家登錄的時間，地址，機器信息到游戲過程中的每一項操作都可以作為日志記錄下來，以備查錯及數(shù)據(jù)挖掘用。在以時間收費的游戲中，我們還需要一臺計費的服務(wù)器，這臺服務(wù)器一般接在網(wǎng)關(guān)服務(wù)器上，注冊玩家登錄和退出事件以記錄玩家的游戲時間?，F(xiàn)實中有警察來維護秩序，游戲中也如此，這就是我們常說的GM。我們的游戲服務(wù)器也如此。好了，做完這些優(yōu)化我們的服務(wù)器結(jié)構(gòu)大體也就定的差不多了，暫且也不再繼續(xù)深入，更細化的內(nèi)容等到各個部分實現(xiàn)的時候再探討。最后是數(shù)據(jù)庫了，為了減輕數(shù)據(jù)庫的壓力，提高數(shù)據(jù)請求的響應(yīng)速度，我們可以在數(shù)據(jù)庫之前建立一個數(shù)據(jù)庫緩存服務(wù)器，將一些常用數(shù)據(jù)緩存在此，服務(wù)器與數(shù)據(jù)庫的通信都要通過這臺服務(wù)器進行代理。然后，我們可以試著把一些與地圖數(shù)據(jù)無關(guān)的公共邏輯放到Master Server上去實現(xiàn)，這樣Zone Server上只保留了與地圖數(shù)據(jù)緊密相關(guān)的邏輯，如生物管理，玩家移動和狀態(tài)更新等。首先是當前的Zone Server要做的事情太多了，以至于他都處理不了多少連接。當然，這只是一種簡單的實現(xiàn)，也是普通使用的一種方案，如果后期想對消息廣播做一些優(yōu)化的話，那可能才需要多考慮一下。而對于游戲服來說，有一臺還是多臺網(wǎng)關(guān)服是沒有什么區(qū)別的。既然想要更多的連接數(shù)，那就再加一臺網(wǎng)關(guān)服務(wù)器吧。好吧，我們還是把之前留下的問題拿出來解決掉吧。我們可以試著對地圖進行一些劃分，由一個Master Server來管理一些更小的Zone Server，玩家通過網(wǎng)關(guān)連接到Master Server上，而實際與地圖有關(guān)的邏輯是分派給更小的Zone Server去處理。我們也不在這個名字上糾纏了，就按大家通用的叫法，還是稱他為網(wǎng)關(guān)服務(wù)器吧。繼續(xù)我們的結(jié)構(gòu)討論。什么？你說夢幻、魔獸還有史先生的那個什么征途遠不止這么點人了！噢，我說的是大多數(shù)，是大多數(shù)，不包括那些明星。至少在現(xiàn)在來說，一個游戲世界內(nèi)，也就是一組服務(wù)器內(nèi)同時有五六千個在線的玩家還是件讓人很興奮的事。仔細看一看這個需求，我們想要的僅僅只是一臺管理連接的服務(wù)器，并不打算讓他承擔太多的游戲邏輯。但我們所遇到的事實是，服務(wù)器收到一個移動包后，要向周圍所有人廣播，而不是echo服務(wù)器那樣簡單的回應(yīng)；服務(wù)器在收到一個連接斷開通知時要向很多人通知玩家退出事件，并將該玩家的資料寫入數(shù)據(jù)庫，而不是echo服務(wù)器那樣什么都不需要做；服務(wù)器在收到一個物品使用請求包后要做一系列的邏輯判斷以檢查玩家有沒有作弊；服務(wù)器上還啟動著很多定時器用來更新游戲世界的各種狀態(tài)......其實這么一比較，我們也看出資源消耗的所在了：服務(wù)器上大量的復雜的邏輯處理。問題恰恰在于你是隨便寫的，而MMORPG的服務(wù)器是復雜設(shè)計的。這里有必要再解釋下這個數(shù)字。2000人，似乎我們的策劃朋友們不大愿意接受這個數(shù)字。很完美的解決方案，不是嗎？這種結(jié)構(gòu)在實際的部署中也遇到了一些挑戰(zhàn)。服務(wù)器結(jié)構(gòu)探討繼續(xù)世界服都已經(jīng)看出來了，這種每切換一次地圖就要重新連接服務(wù)器的方式實在是不夠優(yōu)雅，而且在實際游戲運營中也發(fā)現(xiàn)，地圖切換導致的卡號，復制裝備等問題非常多，這里完全就是一個事故多發(fā)地段，如何避免這種頻繁的連接操作呢？最直接的方法就是把那個圖倒轉(zhuǎn)過來就行了。但是簡單并不表示功能上會有什么損失，簡單也更不能表示游戲不能賺錢。在整個游戲過程中，客戶端始終只會與一臺地圖服務(wù)器保持連接，當要切換地圖的時候，在獲取到新地圖的地址后，會先與當前地圖斷開連接，再進入新的地圖，這樣保證玩家數(shù)據(jù)在服務(wù)器上只有一份。中心服務(wù)器主要維護一張地圖ID到地圖服務(wù)器地址的映射表。一般來說，我們的游戲世界不可能會只有一塊或者兩塊小地圖，那順理成章的，也就需要一個地圖管理者。當人數(shù)繼續(xù)增加，情況就變得不那么簡單了，我們得需要一個管理者來對我們的工作進行分工、協(xié)調(diào)。當人數(shù)增加到三個時，我們對等的合作關(guān)系可能會有些復雜，因為我們每個人都同時要與另兩個人合作協(xié)商。既然如此，我們就把每塊地圖都當作是一臺獨立的服務(wù)器，他提供了在這塊地圖上游戲時的所有邏輯功能，至于內(nèi)部結(jié)構(gòu)如何劃分我們暫不理會，先把他當作一個黑盒子吧。世界中有些地圖間雖然在地理上是直接相連的，但我們發(fā)現(xiàn)其游戲內(nèi)部的邏輯卻是完全隔離的。決定了地圖的管理方式也就決定了我們的服務(wù)器結(jié)構(gòu)，我們?nèi)匀幌葟淖詈唵蔚膶崿F(xiàn)方式開始說起。如縱隊、好友、公會、戰(zhàn)場和副本等，這些都是通過基本邏輯功能組合或擴展而成。服務(wù)器結(jié)構(gòu)探討簡單的世界服實現(xiàn)討論了這么久我們一直都還沒有進入游戲世界服務(wù)器內(nèi)部，現(xiàn)在就讓我們來窺探一下里面的結(jié)構(gòu)吧。而當我們要到一區(qū)去創(chuàng)建角色開始游戲的時候，在一區(qū)的帳號數(shù)據(jù)庫中并沒有我們的帳號數(shù)據(jù)，所以，我們必須先到官網(wǎng)上做一次激活操作。wow中一共有八個大區(qū)，我們想要進入某個大區(qū)游戲之前，必須到官網(wǎng)上激活這個區(qū)，這是為什么呢？一般來說，在各個大區(qū)帳號數(shù)據(jù)庫之上還有一個總的帳號數(shù)據(jù)庫，我們可以稱它為中心數(shù)據(jù)庫。而每個游戲世界都有自己的游戲數(shù)據(jù)庫服務(wù)器，只允許本游戲世界內(nèi)的服務(wù)器連接。但是對于不同的游戲世界來說，其角色及游戲內(nèi)數(shù)據(jù)都是互相獨立的，所以一般情況下也就為每個游戲世界單獨配備一臺數(shù)據(jù)庫服務(wù)器，以減輕數(shù)據(jù)庫的壓力。而對于數(shù)據(jù)庫的應(yīng)用，在這種結(jié)構(gòu)下，登錄服及游戲世界服都會需要連接數(shù)據(jù)庫。當然，如果找不到這樣的解決方案，自己從頭打造一個也并不難。一般最常用，也最簡單部署的應(yīng)該是基于DNS的負載均衡系統(tǒng)了，其通過在DNS中為一個域名配置多個IP地址來實現(xiàn)。好了，需求已經(jīng)提出來了，現(xiàn)在來考慮如何將其實現(xiàn)。一般來說，使用現(xiàn)有的商業(yè)數(shù)據(jù)庫系統(tǒng)比自己手工技術(shù)先進要明智得多。另外，當我們在增加或移除登錄服的時候不應(yīng)該需要對游戲世界服有所改動，也不會要求重啟世界服，當然也不應(yīng)該要求客戶端有什么更新或者修改，一切都是在背后自動完成。當然，在這里也不會存在要求添加太多登錄服的情況。而當在開新區(qū)的時候，或許要配備40臺登錄服才能應(yīng)付那如潮水般涌入的玩家登錄請求。我們可以試著從實際需求的角度來考慮一下這個問題。服務(wù)器結(jié)構(gòu)探討登錄服的負載均衡回想一下我們在玩wow時的操作流程：，首先就會要求我們輸入用戶名和密碼進行驗證，驗證成功后才會出來游戲世界列表，之后是排隊進入游戲世界，開始游戲...可以看到跟前面的描述有個很明顯的不同，那就是要先驗證帳號再選擇游戲世界。另外在實際的游戲運營中，有些游戲世界很火爆，而有些游戲世界卻非常冷清，甚至沒有多少人玩的情況也是很常見的。因為登錄服處理的邏輯相對來說比較簡單，就是將玩家提交的帳號和密碼送到數(shù)據(jù)庫進行驗證，和生成會話密鑰發(fā)送給游戲服和客戶端，操作完成后連接就會立即斷開，而且玩家在以后的游戲過程中不會再與登錄服打任何交道。早期的游戲大都采用的是這種結(jié)構(gòu)，有些游戲在實現(xiàn)時采用了一些技術(shù)手段使得在切換游戲服時不需要再次驗證帳號，但整體結(jié)構(gòu)還是未做改變。最后的結(jié)構(gòu)圖應(yīng)該像這樣：loginServergameServer|/|/client該結(jié)構(gòu)下的玩家操作流程為，先選擇大區(qū)，再選擇大區(qū)下的某臺服務(wù)器，即某個游戲世界，點擊進入后開始帳號驗證過程，驗證成功則進入了該游戲世界。簡單點來實現(xiàn)，我們完全可以拋棄這個大區(qū)的概念，認為一個大區(qū)也就是放在同一個機房的多臺服務(wù)器組，各服務(wù)器組間沒有什么關(guān)系。我們把觀察點先集中在一個大區(qū)內(nèi)。關(guān)于為什么要提供用戶名和密碼才能進入的問題我們這里不打算做過多討論，云風曾對此也提出過類似的疑問，并給出了只用一個標識串就能進入的設(shè)想，有興趣的可以去看看他們的討論。如果我們把這兩項功能集成到一個服務(wù)進程中，則最終的結(jié)構(gòu)很簡單：clientserver嗯，太簡單了點，這樣也敢叫服務(wù)器結(jié)構(gòu)？好吧，現(xiàn)在我們來往里面稍稍加點東西，讓它看起來更像是服務(wù)器結(jié)構(gòu)一些。在這里，我們不打算對現(xiàn)有游戲結(jié)構(gòu)做評價，而是試著從頭開始搭建一個我們需要的MMOG結(jié)構(gòu)。所以，結(jié)構(gòu)本無所謂正確與錯誤；當然，優(yōu)秀的結(jié)構(gòu)更有助于系統(tǒng)的搭建，對系統(tǒng)的可擴展性及可維護性也有更大的幫助。好了，廢話說完了，下一篇，我們開始進入登錄服的設(shè)計吧。這個socket句柄才是描述每個連接的唯一標識。而實際上，一個socket描述符在windows上的定義是 unsigned int，因此要有限制那也是四十多億，放心好了。最后是一個純技術(shù)問題，有關(guān)socket連接數(shù)的最大限制。但實際上，我覺得這是完全沒有必要的，真要出現(xiàn)這樣的錯誤，直接斷開這個客戶端的連接可能更安全。消息包格式定義包括三段，包長、消息碼和包體，爭論的焦點在于應(yīng)該是消息碼在前還是包長在前，我們也把這個當作是信仰問題吧，有興趣的去云風的blog上看看，論論。當然，如果已有了成熟的可靠UDP庫，那也可以繼續(xù)使用著。)然后是網(wǎng)絡(luò)協(xié)議的選擇，以前的選擇大多傾向于UDP，為了可靠傳輸一般自己都會在上面實現(xiàn)一層封裝，而現(xiàn)在更普通的是直接采用本身就很可靠的TCP，或者TCP與UDP的混用。如果真有權(quán)利去選擇的話，選自己最熟悉的吧。接下來先說說我在開發(fā)中遇到過的一些困惑和一基礎(chǔ)問題探討吧，這些問題可能有人與我一樣，也曾遇到過，或者正在被困擾中，而所要探討的這些基礎(chǔ)問題向來也是爭論比較多的，我們也不評價其中的好與壞，只做簡單的描述。我們在前面探討了一些在現(xiàn)在的游戲中見到過的結(jié)構(gòu)，并盡我所知地分析了各自存在的一些問題和可以做的一些改進，希望其中沒有謬誤，如果能給大家也帶來些啟發(fā)那自然更好。差不多就這么多了吧，接下來我們會按照這個大致的結(jié)構(gòu)來詳細討論各部分的實現(xiàn)。從記錄玩家登錄的時間，地址，機器信息到游戲過程中的每一項操作都可以作為日志記錄下來，以備查錯及數(shù)據(jù)挖掘用。在以時間收費的游戲中，我們還需要一臺計費的服務(wù)器，這臺服務(wù)器一般接在網(wǎng)關(guān)服務(wù)器上，注冊玩家登錄和退出事件以記錄玩家的游戲時間?，F(xiàn)實中有警察來維護秩序，游戲中也如此，這就是我們常說的GM。我們的游戲服務(wù)器也如此。好了，做完這些優(yōu)化我們的服務(wù)器結(jié)構(gòu)大體也就定的差不多了，暫且也不再繼續(xù)深入，更細化的內(nèi)容等到各個部分實現(xiàn)的時候再探討。最后是數(shù)據(jù)庫了，為了減輕數(shù)據(jù)庫的壓力，提高數(shù)據(jù)請求的響應(yīng)速度，我們可以在數(shù)據(jù)庫之前建立一個數(shù)據(jù)庫緩存服務(wù)器，將一些常用數(shù)據(jù)緩存在此，服務(wù)器與數(shù)據(jù)庫的通信都要通過這臺服務(wù)器進行代理。然后，我們可以試著把一些與地圖數(shù)據(jù)無關(guān)的公共邏輯放到Master Server上去實現(xiàn)，這樣Zone Server上只保留了與地圖數(shù)據(jù)緊密相關(guān)的邏輯，如生物管理，玩家移動和狀態(tài)更新等。首先是當前的Zone Server要做的事情太多了，以至于他都處理不了多少連接。當然，這只是一種簡單的實現(xiàn)，也是普通使用的一種方案，如果后期想對消息廣播做一些優(yōu)化的話，那可能才需要多考慮一下。而對于游戲服來說，有一臺還是多臺網(wǎng)關(guān)服是沒有什么區(qū)別的。既然想要更多的連接數(shù)，那就再加一臺網(wǎng)關(guān)服務(wù)器吧。好吧，我們還是把之前留下的問題拿出來解決掉吧。我們可以試著對地圖進行一些劃分，由一個 Master Server來管理一些更小的Zone Server，玩家通過網(wǎng)關(guān)連