淺談滾服遊戲如果實現一鍵合服

這是一個建立於 的文章，其中的資訊可能已經有所發展或是發生改變。

原文地址-黑鬍子Blog:http://www.bugclosed.com/post/12

背景

近幾年的遊戲行業中，出現了各種各樣的滾服遊戲，包括頁遊，手遊，H5遊戲等等。滾服遊戲和大服遊戲的區別在於同時遊戲人數，大服遊戲是有很多使用者在一起玩，甚至幾十上百萬玩家。而滾服遊戲則一般會設計遊戲線上上限，比如3000，達到上限則新開一組伺服器，並引導使用者進入新區。

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

合服

前面提到滾服和大服兩種模式，不管是哪種模式，合服的是時候，是需要將多個服的遊戲資料合併在一起。不論資料庫採用的是mysql，redis或者mongodb，資料庫表的合并都是需要做到多服資料合併後的相容問題，不發生衝突或者遺漏。比如mysql，需要保證各個表合并時主鍵不衝突，如果業務有暱稱不重複的設定，還需要保證暱稱不重複。有時候合并還需要刪除殭屍資料，此時需要注意刪除的資料之間的邏輯關係是否一併清除，不能導致資料不一致，比如清除了一個半年不上線的玩家帳號資料，但是在好友或者幫派中還殘留關係。

單服架構

業務模式在一定程度上會決定技術的選型，在滾服模式裡面，遊戲的線上人數要求都比較低，通常一個單進程架構就足以支援。所謂單服架構，並不一定整個後台只有一個伺服器處理序，可能會有其他輔助進程，但是主遊戲邏輯只會有一個進程，同時架構也不支援遊戲進程伸縮，達到該進程或者物理伺服器上限，即從運營上重新開服，引導新的玩家進入新區，單服架構可以簡單理解為如下架構模式：

可見，每組伺服器有自己獨立的遊戲進程和資料庫，不同伺服器之間的使用者是物理隔離的。該架構的優勢是簡單易開發，伺服器獨立隔離，某組伺服器需要停服調整或者宕機，不會影響其他服。缺點也來自單服獨立部署，每次開新服都要重新部署資料庫和遊戲服務整套環境。合服的時候需要進行資料庫的物理合并和遷移。

單服架構下的合服，需要進行物理資料庫表的硬合并，需要注意主鍵欄位是否衝突。可以通過兩種方法防止主鍵衝突：

• 合服的時候對所有主鍵進行修改，特別是uid，保證他們來自不同空間。
• 在設計之初即考慮合服的問題，從而資料在分配唯一uid的時候，即可為每個服進行分段處理，保證從一開始各個服的主鍵uid即不會衝突。

合服的步驟和操作一般都比較固定，成熟後可以針對自己特定的業務模式和表結構寫指令碼統一處理。

大服架構

大服架構區別於單服架構是可以承載更多線上玩家，同時還有一定的伸縮性，一定程度上可以通過不斷部署新伺服器來擴充線上容量。在滾服模式的遊戲中，也可以採用大服的設計思路和架構，從而在營運管理和合服方面得到極大便利，架構示意如下：

當然，該和端遊的分布式架構圖有相似之處，但是也有所區別，因為此處的業務情境是用在滾服遊戲中。該架構是一個原理說明示意，並非是線上運營架構，不同開發人員會有不同的具體思路和設計偏好，比如還有類似好友，工會等並未列出，此處僅進行原理說明分析。
可以看出，有多個不同的角色，說明如下：

• 資料庫，整個架構下只有唯一的DB，所有資料都集中儲存；
• DBServer，所有對資料庫的操作都是通過DBServer進行，確保商務邏輯對資料庫設計細節的分離;
• Account/Name，對使用者ID或者暱稱的唯一性做保證，這個服務是全大區唯一;
• GameServer，遊戲邏輯服務，此處每個GameServer即是一個邏輯服，通過不斷部署新的GameSever即實現了開服；
• Login，登入邏輯和選路分配，此處是一鍵合服的關鍵所在，在合服策略配置裡面儲存了哪個服分配的哪個GameServer遊戲進程地址，只需要通過調整這個策略配置即可控制使用者進入的GameServer進程；

大服架構使用者登入流程：

1. 使用者在用戶端能登陸介面選擇3服的入口，並點擊進入遊戲。
2. Login模組收到使用者進入s3的請求，從合服策略配置中查詢到s3的GameServer入口地址，返回。
3. 用戶端收到s3的GameServer地址，直接發起到s3的連結請求。
4. GameServer3 處理登入請求，並從DBServer擷取使用者資訊返回給使用者，沒有資訊則建立新角色。
5. 登入完成，進入了s3服。

和單服架構的合服區別

單服架構的合服，之所以要進行資料處理和遷移，主要是2個原因：

• 各個服資料庫處於分離狀態，需要物理合并到一起
• 主鍵唯一ID等資訊有衝突，需要資料庫修複處理

因為這2個原因，導致單服合服需要做大量的資料處理，匯出，拷貝，遷移等，加大了合服操作的流程複雜度和出錯的可能。從大服架構圖可以發現，單服架構的2個合服難處已經自然消除了。Account分配唯一ID，在DB裡面儲存自然不會衝突；而且資料本來就放在一個庫裡面的，不存在需要遷移的問題。

一鍵合服

通過以上分解可以發現，現在合服會極其方便；不用修改和遷移資料，甚至都不用停服，只需要通過一個工具在合服策略配置庫裡面對選路資訊進行修改，修改使用者的登入的遊戲伺服器。比如提供一個web修改頁面，選擇s1，s2，s3服合并，預設合并後由gameserver1提供服務，gameserver2和gameserver3即可停止下架，只需要一個http請求，將s2，s3的gameserver地址修改成gameserver1，即實現了合并。
合服後使用者登入流程：

1. 使用者還是選擇3服的入口登入遊戲。
2. Login模組得到使用者要進入s3服，查詢合服策略配置，得到s3服的服務地址，即gamesrver1，返回。
3. 使用者得到gameserver1的地址，發起連結請求，進行登入。