隨著暴雪大概率推出國內(nèi)市場，將會有很多外服MMO網(wǎng)游填補市場空缺，那么要建立完全滿足用戶流暢訪問的游戲，對在線游戲服務(wù)器有哪些要求，需要注意什么？下面就來簡單介紹一下

由于大型多人在線游戲服務(wù)器理論上需要支持無限多的玩家，所以對服務(wù)器端是一個非常大的考驗。服務(wù)器必須是安全的，可維護性高的，可伸縮性高的，可負(fù)載均衡的，支持高并發(fā)請求的。面對這些需求，我們在設(shè)計服務(wù)器的時候就需要慎重考慮，特別是架構(gòu)的設(shè)計，如果前期設(shè)計不好，最后面臨的很可能是重構(gòu)。

一款游戲服務(wù)器的架構(gòu)都是慢慢從小變大的，不可能一下子就上來一個完善的服務(wù)器構(gòu)架，目前流行的說法是游戲先上線，再擴展。所以說我們在做架構(gòu)的時候，一定要把底層的基礎(chǔ)組件做好，方便以后擴展，但是剛開始的時候留出一些接口，并不實現(xiàn)它，將來游戲業(yè)務(wù)的發(fā)展，再慢慢擴展。當(dāng)然，如果前期設(shè)計的不好，后期業(yè)務(wù)擴展了，但架構(gòu)沒辦法擴展，只能加班加點搞了。

面對龐大的數(shù)據(jù)量我們想到的唯一個解決方案就是分而治之，即采用分布式的方式去解決它。把緊湊獨立的功能單獨拿出來做。分擔(dān)到不同的物理服務(wù)器上面去運行。而且做到可以動態(tài)擴展。這就需要我們考慮好模塊的劃分，盡量要業(yè)務(wù)獨立，關(guān)聯(lián)性低。

前期，由于游戲需要盡快上線，開發(fā)周期短，我們需要把服務(wù)盡快的跑起來，這個時候的目標(biāo)應(yīng)該是盡快完成測試版本開發(fā)，單臺服務(wù)器支持的人數(shù)可以稍微低一些，但是當(dāng)人數(shù)暴漲時，我們可以能過多開幾組服務(wù)來支持新增漲的用戶量，即可以平衡擴展就可以了。到后期我們再把具體的模塊單獨拿出來支持，比如前期邏輯服務(wù)器上包括:活動，關(guān)卡，背包，技能，好友管理等。后期我們可以把好友，背包管理或其它的單獨做一個服務(wù)進(jìn)程，部署在不同的物理服務(wù)器上面。我們先按分區(qū)的服務(wù)進(jìn)行設(shè)計，后面在部署的時候可以部署為世界服務(wù)器，下面是一個前期的架構(gòu)圖，下面我們從每個服務(wù)器的功能說起：

1，登陸管理服務(wù)

負(fù)責(zé)用戶的登陸驗證，如果有注冊功能的話，也可以放在這里。一般手機游戲直接走sdk驗證。網(wǎng)頁游戲和客戶端游戲會有注冊功能，也可以叫用戶管理服務(wù)。

1.1 用戶登陸驗證?負(fù)責(zé)接收客戶端的用戶登陸請求，驗證賬號的合法性，是否在黑名單（被封號的用戶），是否在白名單（一般是測試賬號，服務(wù)未開啟時也可以進(jìn)入）。如果是sdk登陸，此服務(wù)向第三方服務(wù)發(fā)起回調(diào)請求。

1.2 登陸安全加密?使用加密的傳輸協(xié)議，見通信協(xié)議部分。

1.3 是否在白名單內(nèi)?白名單是給內(nèi)部測試人員使用的，在服務(wù)器未開啟的狀態(tài)下，白名單的用戶可以提前進(jìn)入游戲進(jìn)行游戲測試。

1.4 判斷是否在黑名單?黑名單的用戶是禁止登陸的，一般這是一些被封號的用戶，拒絕登陸。

1.5 登陸驗證?服務(wù)器使用私鑰解密密碼，進(jìn)行驗證，如果是sdk登陸，則直接向第三方服務(wù)發(fā)起回調(diào)。

1.6 登陸令牌（token）生成?當(dāng)用戶登陸驗證成功之后，服務(wù)器端需要生成一個登陸令牌token,這個token具有時效性，當(dāng)用戶客戶端拿到這個token之后，如果在一定時間內(nèi)沒有登陸游戲成功，那么這個token將失敗，用戶需要重新申請token,token存儲在登陸服務(wù)這，向外提供用戶是否已登陸的接口，其它服務(wù)器想驗證如果是否登陸，就拿那個服務(wù)收到的token來此驗證。

1.7 顯示用戶角色信息?當(dāng)用戶登陸成功之后，顯示最近登陸的角色信息。

2，顯示公告

用戶登陸成功之后，請求公告服務(wù)器，獲取最新的公告，公告服務(wù)先根據(jù)token和Userid驗證用戶是否已登陸，公告有可能根據(jù)渠道的不同，顯示不同的公告。所以 公告一定是要可以根據(jù)渠道編輯的。

3，選區(qū)服務(wù)

當(dāng)用戶登陸成功之后，請求服務(wù)器分區(qū)列表服務(wù)器，顯示當(dāng)前所有的大區(qū)列表。

3.1 驗證用戶是否已登陸?向登陸服務(wù)器請求驗證是否已登陸。

3.2 大區(qū)列表顯示?大區(qū)列表信息中只顯示大區(qū)id和大區(qū)名稱。這樣做是為了安全考慮，不一次性把大區(qū)對應(yīng)的網(wǎng)關(guān)ip和端口暴露出來，也可以減少網(wǎng)絡(luò)的傳輸量。

3.3?用戶點擊選擇某個大區(qū)，客戶端拿到大區(qū)id再向選區(qū)服務(wù)請求獲取此大區(qū)對應(yīng)的網(wǎng)關(guān)ip地址和端口。根據(jù)負(fù)載算法計算得出。

3.4 網(wǎng)關(guān)的選擇?選區(qū)服務(wù)會維護一份網(wǎng)關(guān)的配置列表。一個大區(qū)對應(yīng)一到多個網(wǎng)關(guān)，當(dāng)配置有多個網(wǎng)關(guān)時，需要定時檢測各個網(wǎng)關(guān)是否連接正常，如果發(fā)現(xiàn)有網(wǎng)關(guān)連接不上，需要把大區(qū)對應(yīng)的網(wǎng)關(guān)信息設(shè)置為無效，不再參與網(wǎng)關(guān)的分配，并發(fā)出報警。 一般對于網(wǎng)關(guān)的選擇，可以使用用戶id求余法加虛網(wǎng)關(guān)節(jié)點法。這樣在網(wǎng)關(guān)節(jié)點數(shù)量固定的情況下，一個用戶總是會被分配到同一個網(wǎng)關(guān)上面。但是如果只是使用求余法的話，可能會造成用戶分布不均衡，這里可以通過增加網(wǎng)關(guān)的虛擬節(jié)點（其它就是增加某個網(wǎng)關(guān)的權(quán)重，讓用戶多來一些到這個網(wǎng)關(guān)上面），這個可以參考哈稀一致性算法。包括后面說到的一個網(wǎng)關(guān)對應(yīng)多個邏輯服務(wù)器，也可以使用同樣的方法。這部分可以抽象出來一個模塊使用。

3.5?選區(qū)服務(wù)對內(nèi)要提供修改服務(wù)器狀態(tài)的接口，比如維護中…

4，登陸網(wǎng)關(guān)

4.1 建立連接?收到客戶端的建立連接請求之后，記錄此channel和對應(yīng)的連接建立時間。并設(shè)置如果在一定時間內(nèi)未收到登陸請求，則斷開連接。返回給客戶端登陸超時。