游戲開發(fā)經(jīng)驗談（一）：游戲架構(gòu)里隱藏的五個坑及其應(yīng)對方案

隨著移動終端硬件配置的飛速提升，手游行業(yè)開始從爆發(fā)期進入相對穩(wěn)定的發(fā)展期。殘酷市場競爭環(huán)境下，游戲公司紛紛尋求業(yè)務(wù)創(chuàng)新，手游重度化、VR/AR游戲、經(jīng)典IP回歸之外，游戲出海和全球服也成為新亮點。這也意味著云服務(wù)需要承載越來越多后端服務(wù)器的支撐工作，合理的平臺架構(gòu)將成為系統(tǒng)穩(wěn)定運行的基礎(chǔ)保障。

迄今為止，UCloud平臺支持的游戲已經(jīng)超過了1000余款，其中手游占據(jù)了70%以上。在這過程中我們也陪用戶踩過了很多“坑”，本文將結(jié)合以往的一些經(jīng)驗和成功案例，為大家闡釋游戲架構(gòu)設(shè)計上，可能會遇到的一些問題和解決方案。

場景A：All In One的MudOS架構(gòu)

MudOS是第一代游戲架構(gòu)，目前應(yīng)該是無人使用的歷史里程碑了，之所以會在這里提到，是因為在云平臺，仍然有不少用戶使用數(shù)據(jù)、計算、日志全部集中于同一臺服務(wù)器的All In One集中式部署架構(gòu)。

以當前的技術(shù)來說，公有云還沒能完全避免宕機對業(yè)務(wù)造成的影響，而宕機必然要導(dǎo)致業(yè)務(wù)一段時間內(nèi)的不可用。一旦出現(xiàn)云主機內(nèi)部系統(tǒng)崩潰，對于這種架構(gòu)的服務(wù)器更是災(zāi)難性的。因為時間和數(shù)據(jù)都很難保證，最終可能必須通過備份文件才能進行回檔。

此外，集中式部署架構(gòu)對于云主機的性能要求非常高，隨著業(yè)務(wù)的增長，開發(fā)者經(jīng)常要重新調(diào)整配置，甚至最后直接購買物理云主機。同時，為了達到過高的性能要求，需要對云產(chǎn)品的硬件靈活性和彈性伸縮能力進行取舍，即使在購買了物理云主機的情況下，云平臺的成本優(yōu)化效果也無法達到最大化。因此，希望大家在游戲設(shè)計中規(guī)避掉這種集中式部署架構(gòu)，盡量使用邏輯服或者微服務(wù)的模式。

場景B：瘋狂掉線

掉線對所有游戲玩家來說都是非常痛苦的事情，我們曾經(jīng)手過一個瘋狂掉線的案例，這個案例的獨特之處在于玩家在游戲過程中很少發(fā)生卡頓和瞬移問題，但是會經(jīng)常出現(xiàn)掉線現(xiàn)象，而且還是不定期的玩家集中掉線。掉線的時間點也非常巧合，基本上是在機房監(jiān)控到DDoS、或者地方級以上骨干容災(zāi)切換閃斷的時候。

我們初步分析可能是業(yè)務(wù)和網(wǎng)絡(luò)的特殊情況觸發(fā)的，在和用戶交流業(yè)務(wù)邏輯之后，了解到用戶的游戲設(shè)計采用的是TCP邏輯：業(yè)務(wù)1分鐘發(fā)出1個心跳包，如果30秒未收到ACK測試則認為客戶端掉線需要重連。很明顯，這種設(shè)計并沒有考慮到丟包或錯包等問題。

因為實際情況下，全球運營商的網(wǎng)絡(luò)設(shè)備都有一定的錯包率或丟包率，1分鐘1個心跳包模式下，一旦發(fā)生丟包，玩家在1分30秒內(nèi)無法收到測試信息，必然會被系統(tǒng)剔除，導(dǎo)致掉線。而在容災(zāi)切換或者DDoS情況下，丟包或者錯包的問題會更加嚴重，玩家會集中掉線也就可以解釋了。

定位問題后，我們幫助用戶對以上邏輯進行了修改，將玩家的掉線時間從1分30秒收斂成30秒，設(shè)置業(yè)務(wù)每10秒3個心跳包，超過3個周期未收到則視為掉線。每10秒3個心跳包的情況下，超過30秒就有9個心跳包，只有當這9個心跳包全部丟失，系統(tǒng)才會認為玩家離線。邏輯修改后會形式一個緩沖區(qū)，避免錯包或丟包情況下造成的系統(tǒng)判斷失誤。

場景C：單點DB的危機

下圖的業(yè)務(wù)架構(gòu)設(shè)計得已經(jīng)相對完整，整個系統(tǒng)采用的是DB的主從架構(gòu)，可能宕機造成的風(fēng)險都已經(jīng)規(guī)避，唯一的疏漏在于用戶將Cache和業(yè)務(wù)綁定，一旦業(yè)務(wù)重啟，整個Cache就會被清空，同時如果Cache達到上限也造成業(yè)務(wù)異常。

有一次用戶的DB磁盤異常需要較長時間恢復(fù)，雪上加霜的是Cache即將寫滿，因為更改數(shù)據(jù)庫指向必須重啟業(yè)務(wù)，為了保證游戲的正常運行，又不能把業(yè)務(wù)切到從庫。最后只好聯(lián)合當時的DBA、內(nèi)核以及系統(tǒng)專家，耗費大量時間來恢復(fù)主庫。

為了避免這種情況再次發(fā)生，后續(xù)用戶直接將Cache層拆分出來放到我們的高可用Redis上來保證系統(tǒng)的穩(wěn)定。

場景D：Redis崩潰

相信做游戲開發(fā)的人或多或少都經(jīng)歷過Redis崩潰問題。本案例中，用戶采用了比較前沿的框架，它拋棄了傳統(tǒng)數(shù)據(jù)庫，直接使用內(nèi)存存儲作為數(shù)據(jù)的唯一存儲器。全球服上使用的是微服務(wù)框架，不存在單點風(fēng)險，業(yè)務(wù)能力非常強。但因為在研發(fā)過程中第一次使用集群化，所以也踩過一些坑。

問題一：Redis AOF造成短暫查詢堆積。解決方案是進行分片操作，保證AOF時間不一樣，將整體業(yè)務(wù)查詢危機縮減下來。此外，針對游戲框架申請DPA，盡量減少刷數(shù)據(jù)的可能性。

問題二：QPS極限僅能達到數(shù)千，甚至出現(xiàn)了不定期慢查詢卡死的情況。查看代碼和數(shù)據(jù)時發(fā)現(xiàn)，用戶的業(yè)務(wù)語句中大量使用了KEYS命令且無任何限制，這就類似于在巨大的MySQL集群里select *， 解決方式是直接將所有KEYS風(fēng)險語句進行調(diào)整和范圍限制，保證業(yè)務(wù)的正常運作。

另外，集群Redis是基于proxy和Redis分片實現(xiàn)的，而非集群的原生Redis對短連接的處理性能極差，并且由于單線程的特性，非常容易因為短連接將CPU打滿。對于Redis來說，即使提供最強的44核CPU，最后程序運行的結(jié)果也是1核跑滿，其它43個核圍觀。

因此，在設(shè)計游戲的時候，使用Redis要特別注意兩點：1、集群Redis盡量少用Keys命令；2、主備Redis盡量不要使用短連接，因為短連接過多會造成整體業(yè)務(wù)性下降，尤其在Redis特別集中的環(huán)境下，影響會非常嚴重。

場景E：Register Server 單點

下圖為一個實時對戰(zhàn)場景的全球服架構(gòu)，架構(gòu)采用了自動注冊機制，注冊服務(wù)器類似路由表功能，會保存所有微服務(wù)集群的節(jié)點IP信息以供業(yè)務(wù)節(jié)點需要時查詢調(diào)用。架構(gòu)左側(cè)上層為高可用數(shù)據(jù)庫、高可用內(nèi)存存儲，下方是對戰(zhàn)服務(wù)器和平臺入口，右側(cè)為工會聊天室，框架里面接入了四個對戰(zhàn)服。這個框架的穩(wěn)定性和擴展性都非常強，主機狀態(tài)對整體業(yè)務(wù)的影響極小。

整個框架美中不足的是，最核心的注冊服務(wù)器采用的是單點，且該服務(wù)器串行在整個業(yè)務(wù)的邏輯中，一旦服務(wù)器異常，同樣會造成整體業(yè)務(wù)不可用。如果不做任何修改，在后續(xù)上線運維的過程中，不論是因為壓力、系統(tǒng)還是其它原因，Register服務(wù)器都將會是一個巨大的技術(shù)風(fēng)險。

針對上述問題，我們根據(jù)不同的場景推薦了兩種不同的解決方案：

管控分離，通過中心推送+本地緩存機制旁路Register。這種方案適用于調(diào)用邏輯較為簡單的情況；
影子備份，配置備用Register Server同步數(shù)據(jù)并切換。這種方案適用于注冊邏輯較為復(fù)雜的情況。

總結(jié)

本文主要簡單介紹了不同場景、不同游戲案例當中遇到的一些框架設(shè)計問題和解決方案。下篇文章，將會以對戰(zhàn)類全球服游戲為例，重點講講游戲架構(gòu)的設(shè)計思路與技術(shù)實現(xiàn)。

作者介紹

沈皓：UCloud PathX產(chǎn)品早期方案設(shè)計者之一，深耕全球服游戲領(lǐng)域，曾全面負責多個知名游戲的全球/跨國業(yè)務(wù)對接、部署及落地。對于MOBA、RTS、FPS等各類游戲的出海全球化的需求、難點、架構(gòu)實現(xiàn)等有獨到見解。