摘要：而滾服游戲則一般會設(shè)計(jì)游戲在線上限，比如，達(dá)到上限則新開一組服務(wù)器，并引導(dǎo)用戶進(jìn)入新區(qū)。這就導(dǎo)致了新服一開，玩家即蜂擁而至，爭先恐后練級升裝備，以求最快速進(jìn)入排行榜前列，如果努力一番發(fā)現(xiàn)落后了，可能就只能坐等下一個新服。

原文地址-石匠的Blog:http://www.bugclosed.com/post/12

近幾年的游戲行業(yè)中，出現(xiàn)了各種各樣的滾服游戲，包括頁游，手游，H5游戲等等。滾服游戲和大服游戲的區(qū)別在于同時游戲人數(shù)，大服游戲是有很多用戶在一起玩，甚至幾十上百萬玩家。而滾服游戲則一般會設(shè)計(jì)游戲在線上限，比如3000，達(dá)到上限則新開一組服務(wù)器，并引導(dǎo)用戶進(jìn)入新區(qū)。

滾服模式是游戲類型，技術(shù)架構(gòu)和急功近利的坑錢策略等因素共同決定的，大服游戲包括絕大部分端游，以及類COC這樣類型的游戲。另外，雖然像英雄聯(lián)盟，王者榮耀這樣的游戲也分服架構(gòu)，但是這個并不是我理解中的“滾服游戲“，首先他們雖然分服，但是每個服的人數(shù)上限也是可以高達(dá)幾十萬，他們并不會發(fā)生頻繁的合服情況。而滾服游戲更多是通過游戲策略設(shè)計(jì)，鼓勵玩家花錢走捷徑透支游戲生命周期，甚至幾天即可獨(dú)霸一個服務(wù)器。從而導(dǎo)致其他玩家望塵莫及，即使是花錢追也性價比極低，還不如進(jìn)入一個新服重新開始。這就導(dǎo)致了新服一開，玩家即蜂擁而至，爭先恐后練級升裝備，以求最快速進(jìn)入排行榜前列，如果努力一番發(fā)現(xiàn)落后了，可能就只能坐等下一個新服。這也導(dǎo)致了新服人數(shù)火爆，老服慢慢變成人煙凋零的村服，甚至沒人的死服。 為了能夠節(jié)約服務(wù)器帶寬資源，同時讓少數(shù)剩余的玩家能夠玩得起來，就必須要要進(jìn)行頻繁的合服，把若干個互不相干的服務(wù)器玩家，合并到一個服里面；這樣又開啟一波玩家競爭和收割。

前面提到滾服和大服兩種模式，不管是哪種模式，合服的是時候，是需要將多個服的游戲數(shù)據(jù)合并在一起。不論數(shù)據(jù)庫采用的是mysql，redis或者mongodb，數(shù)據(jù)庫表的合并都是需要做到多服數(shù)據(jù)合并后的相容問題，不發(fā)生沖突或者遺漏。比如mysql，需要保證各個表合并時主鍵不沖突，如果業(yè)務(wù)有昵稱不重復(fù)的設(shè)定，還需要保證昵稱不重復(fù)。有時候合并還需要刪除僵尸數(shù)據(jù)，此時需要注意刪除的數(shù)據(jù)之間的邏輯關(guān)系是否一并清除，不能導(dǎo)致數(shù)據(jù)不一致，比如清除了一個半年不上線的玩家賬號數(shù)據(jù)，但是在好友或者幫派中還殘留關(guān)系。

業(yè)務(wù)模式在一定程度上會決定技術(shù)的選型，在滾服模式里面，游戲的在線人數(shù)要求都比較低，通常一個單進(jìn)程架構(gòu)就足以支持。所謂單服架構(gòu)，并不一定整個后臺只有一個服務(wù)器進(jìn)程，可能會有其他輔助進(jìn)程，但是主游戲邏輯只會有一個進(jìn)程，同時架構(gòu)也不支持游戲進(jìn)程伸縮，達(dá)到該進(jìn)程或者物理服務(wù)器上限，即從運(yùn)營上重新開服，引導(dǎo)新的玩家進(jìn)入新區(qū)，單服架構(gòu)可以簡單理解為如下架構(gòu)模式：

從圖中可見，每組服務(wù)器有自己獨(dú)立的游戲進(jìn)程和數(shù)據(jù)庫，不同服務(wù)器之間的用戶是物理隔離的。該架構(gòu)的優(yōu)勢是簡單易開發(fā)，服務(wù)器獨(dú)立隔離，某組服務(wù)器需要停服調(diào)整或者宕機(jī)，不會影響其他服。缺點(diǎn)也來自單服獨(dú)立部署，每次開新服都要重新部署數(shù)據(jù)庫和游戲服務(wù)整套環(huán)境。合服的時候需要進(jìn)行數(shù)據(jù)庫的物理合并和遷移。

單服架構(gòu)下的合服，需要進(jìn)行物理數(shù)據(jù)庫表的硬合并，需要注意主鍵字段是否沖突。可以通過兩種方法防止主鍵沖突：

合服的時候?qū)λ兄麈I進(jìn)行修改，特別是uid，保證他們來自不同空間。

在設(shè)計(jì)之初即考慮合服的問題，從而數(shù)據(jù)在分配唯一uid的時候，即可為每個服進(jìn)行分段處理，保證從一開始各個服的主鍵uid即不會沖突。

合服的步驟和操作一般都比較固定，成熟后可以針對自己特定的業(yè)務(wù)模式和表結(jié)構(gòu)寫腳本統(tǒng)一處理。

大服架構(gòu)區(qū)別于單服架構(gòu)是可以承載更多在線玩家，同時還有一定的伸縮性，一定程度上可以通過不斷部署新服務(wù)器來擴(kuò)充在線容量。在滾服模式的游戲中，也可以采用大服的設(shè)計(jì)思路和架構(gòu)，從而在運(yùn)維管理和合服方面得到極大便利，架構(gòu)示意如下：

當(dāng)然，該示意圖和端游的分布式架構(gòu)圖有相似之處，但是也有所區(qū)別，因?yàn)榇颂幍臉I(yè)務(wù)場景是用在滾服游戲中。該架構(gòu)是一個原理說明示意，并非是線上運(yùn)營架構(gòu)，不同開發(fā)者會有不同的具體思路和設(shè)計(jì)偏好，比如還有類似好友，工會等并未列出，此處僅進(jìn)行原理說明分析。
從圖中可以看出，有多個不同的角色，說明如下：

數(shù)據(jù)庫，整個架構(gòu)下只有唯一的DB，所有數(shù)據(jù)都集中保存；

DBServer，所有對數(shù)據(jù)庫的操作都是通過DBServer進(jìn)行，確保業(yè)務(wù)邏輯對數(shù)據(jù)庫設(shè)計(jì)細(xì)節(jié)的分離;

Account/Name，對用戶ID或者昵稱的唯一性做保證，這個服務(wù)是全大區(qū)唯一;

GameServer，游戲邏輯服務(wù)，此處每個GameServer即是一個邏輯服，通過不斷部署新的GameSever即實(shí)現(xiàn)了開服；

Login，登錄邏輯和選路分配，此處是一鍵合服的關(guān)鍵所在，在合服策略配置里面保存了哪個服分配的哪個GameServer游戲進(jìn)程地址，只需要通過調(diào)整這個策略配置即可控制用戶進(jìn)入的GameServer進(jìn)程；

大服架構(gòu)用戶登錄流程：

用戶在客戶端能登陸界面選擇3服的入口，并點(diǎn)擊進(jìn)入游戲。

Login模塊收到用戶進(jìn)入s3的請求，從合服策略配置中查詢到s3的GameServer入口地址，返回。

客戶端收到s3的GameServer地址，直接發(fā)起到s3的鏈接請求。

GameServer3 處理登錄請求，并從DBServer獲取用戶信息返回給用戶，沒有信息則創(chuàng)建新角色。

登錄完成，進(jìn)入了s3服。

單服架構(gòu)的合服，之所以要進(jìn)行數(shù)據(jù)處理和遷移，主要是2個原因：

各個服數(shù)據(jù)庫處于分離狀態(tài)，需要物理合并到一起

主鍵唯一ID等信息有沖突，需要數(shù)據(jù)庫修復(fù)處理

因?yàn)檫@2個原因，導(dǎo)致單服合服需要做大量的數(shù)據(jù)處理，導(dǎo)出，拷貝，遷移等，加大了合服操作的流程復(fù)雜度和出錯的可能。從大服架構(gòu)圖可以發(fā)現(xiàn)，單服架構(gòu)的2個合服難處已經(jīng)自然消除了。Account分配唯一ID，在DB里面存儲自然不會沖突；而且數(shù)據(jù)本來就放在一個庫里面的，不存在需要遷移的問題。

通過以上分解可以發(fā)現(xiàn)，現(xiàn)在合服會極其方便；不用修改和遷移數(shù)據(jù)，甚至都不用停服，只需要通過一個工具在合服策略配置庫里面對選路信息進(jìn)行修改，修改用戶的登錄的游戲服務(wù)器。比如提供一個web修改頁面，選擇s1，s2，s3服合并，默認(rèn)合并后由gameserver1提供服務(wù)，gameserver2和gameserver3即可停止下架，只需要一個http請求，將s2，s3的gameserver地址修改成gameserver1，即實(shí)現(xiàn)了合并。
合服后用戶登錄流程：

用戶還是選擇3服的入口登錄游戲。

Login模塊得到用戶要進(jìn)入s3服，查詢合服策略配置，得到s3服的服務(wù)地址，即gamesrver1，返回。

用戶得到gameserver1的地址，發(fā)起鏈接請求，進(jìn)行登錄。