隨著移動終端硬件配置的飛速提升，手游行業(yè)開始從爆發(fā)期進入相對穩(wěn)定的發(fā)展期。殘酷市場競爭環(huán)境下，游戲公司紛紛尋求業(yè)務創(chuàng)新，手游重度化、VR/AR游戲、經(jīng)典IP回歸之外，游戲出海和全球服也成為新亮點。這也意味著云服務需要承載越來越多后端服務器的支撐工作，合理的平臺架構(gòu)將成為系統(tǒng)穩(wěn)定運行的基礎(chǔ)保障。
迄今為止，UCloud平臺支持的游戲已經(jīng)超過了1000余款，其中手游占據(jù)了70%以上。在這過程中我們也陪用戶踩過了很多“坑”，本文將結(jié)合以往的一些經(jīng)驗和成功案例，為大家闡釋游戲架構(gòu)設計上，可能會遇到的一些問題和解決方案。
場景A：All In One的MudOS架構(gòu)
MudOS是第一代游戲架構(gòu)，目前應該是無人使用的歷史里程碑了，之所以會在這里提到，是因為在云平臺，仍然有不少用戶使用數(shù)據(jù)、計算、日志全部集中于同一臺服務器的All In One集中式部署架構(gòu)。
以當前的技術(shù)來說，公有云還沒能完全避免宕機對業(yè)務造成的影響，而宕機必然要導致業(yè)務一段時間內(nèi)的不可用。一旦出現(xiàn)云主機內(nèi)部系統(tǒng)崩潰，對于這種架構(gòu)的服務器更是災難性的。因為時間和數(shù)據(jù)都很難保證，最終可能必須通過備份文件才能進行回檔。
此外，集中式部署架構(gòu)對于云主機的性能要求非常高，隨著業(yè)務的增長，開發(fā)者經(jīng)常要重新調(diào)整配置，甚至最后直接購買物理云主機。同時，為了達到過高的性能要求，需要對云產(chǎn)品的硬件靈活性和彈性伸縮能力進行取舍，即使在購買了物理云主機的情況下，云平臺的成本優(yōu)化效果也無法達到大化。因此，希望大家在游戲設計中規(guī)避掉這種集中式部署架構(gòu)，盡量使用邏輯服或者微服務的模式。
場景B：瘋狂掉線
掉線對所有游戲玩家來說都是非常痛苦的事情，我們曾經(jīng)手過一個瘋狂掉線的案例，這個案例的獨特之處在于玩家在游戲過程中很少發(fā)生卡頓和瞬移問題，但是會經(jīng)常出現(xiàn)掉線現(xiàn)象，而且還是不定期的玩家集中掉線。掉線的時間點也非常巧合，基本上是在機房監(jiān)控到DDoS、或者地方級以上骨干容災切換閃斷的時候。
我們初步分析可能是業(yè)務和網(wǎng)絡的特殊情況觸發(fā)的，在和用戶交流業(yè)務邏輯之后，了解到用戶的游戲設計采用的是TCP邏輯：業(yè)務1分鐘發(fā)出1個心跳包，如果30秒未收到ACK測試則認為客戶端掉線需要重連。很明顯，這種設計并沒有考慮到丟包或錯包等問題。
因為實際情況下，全球運營商的網(wǎng)絡設備都有一定的錯包率或丟包率，1分鐘1個心跳包模式下，一旦發(fā)生丟包，玩家在1分30秒內(nèi)無法收到測試信息，必然會被系統(tǒng)剔除，導致掉線。而在容災切換或者DDoS情況下，丟包或者錯包的問題會更加嚴重，玩家會集中掉線也就可以解釋了。
定位問題后，我們幫助用戶對以上邏輯進行了修改，將玩家的掉線時間從1分30秒收斂成30秒，設置業(yè)務每10秒3個心跳包，超過3個周期未收到則視為掉線。每10秒3個心跳包的情況下，超過30秒就有9個心跳包，只有當這9個心跳包全部丟失，系統(tǒng)才會認為玩家離線。邏輯修改后會形式一個緩沖區(qū)，避免錯包或丟包情況下造成的系統(tǒng)判斷失誤。
場景C：單點DB的危機
下圖的業(yè)務架構(gòu)設計得已經(jīng)相對完整，整個系統(tǒng)采用的是DB的主從架構(gòu)，可能宕機造成的風險都已經(jīng)規(guī)避，唯一的疏漏在于用戶將Cache和業(yè)務綁定，一旦業(yè)務重啟，整個Cache就會被清空，同時如果Cache達到上限也造成業(yè)務異常。
有一次用戶的DB磁盤異常需要較長時間恢復，雪上加霜的是Cache即將寫滿，因為更改數(shù)據(jù)庫指向必須重啟業(yè)務，為了保證游戲的正常運行，又不能把業(yè)務切到從庫。最后只好聯(lián)合當時的DBA、內(nèi)核以及系統(tǒng)專家，耗費大量時間來恢復主庫。
為了避免這種情況再次發(fā)生，后續(xù)用戶直接將Cache層拆分出來放到我們的高可用Redis上來保證系統(tǒng)的穩(wěn)定。
場景D：Redis崩潰
相信做游戲開發(fā)的人或多或少都經(jīng)歷過Redis崩潰問題。本案例中，用戶采用了比較前沿的框架，它拋棄了傳統(tǒng)數(shù)據(jù)庫，直接使用內(nèi)存存儲作為數(shù)據(jù)的唯一存儲器。全球服上使用的是微服務框架，不存在單點風險，業(yè)務能力非常強。但因為在研發(fā)過程中第一次使用集群化，所以也踩過一些坑。
問題一：Redis AOF造成短暫查詢堆積。解決方案是進行分片操作，保證AOF時間不一樣，將整體業(yè)務查詢危機縮減下來。此外，針對游戲框架申請DPA，盡量減少刷數(shù)據(jù)的可能性。
問題二：QPS極限僅能達到數(shù)千，甚至出現(xiàn)了不定期慢查詢卡死的情況。查看代碼和數(shù)據(jù)時發(fā)現(xiàn)，用戶的業(yè)務語句中大量使用了KEYS命令且無任何限制，這就類似于在巨大的MySQL集群里select *， 解決方式是直接將所有KEYS風險語句進行調(diào)整和范圍限制，保證業(yè)務的正常運作。
另外，集群Redis是基于proxy和Redis分片實現(xiàn)的，而非集群的原生Redis對短連接的處理性能極差，并且由于單線程的特性，非常容易因為短連接將CPU打滿。對于Redis來說，即使提供最強的44核CPU，最后程序運行的結(jié)果也是1核跑滿，其它43個核圍觀。
因此，在設計游戲的時候，使用Redis要特別注意兩點：1、集群Redis盡量少用Keys命令；2、主備Redis盡量不要使用短連接，因為短連接過多會造成整體業(yè)務性下降，尤其在Redis特別集中的環(huán)境下，影響會非常嚴重。
場景E：Register Server 單點
下圖為一個實時對戰(zhàn)場景的全球服架構(gòu)，架構(gòu)采用了自動注冊機制，注冊服務器類似路由表功能，會保存所有微服務集群的節(jié)點IP信息以供業(yè)務節(jié)點需要時查詢調(diào)用。架構(gòu)左側(cè)上層為高可用數(shù)據(jù)庫、高可用內(nèi)存存儲，下方是對戰(zhàn)服務器和平臺入口，右側(cè)為工會聊天室，框架里面接入了四個對戰(zhàn)服。這個框架的穩(wěn)定性和擴展性都非常強，主機狀態(tài)對整體業(yè)務的影響極小。
整個框架美中不足的是，最核心的注冊服務器采用的是單點，且該服務器串行在整個業(yè)務的邏輯中，一旦服務器異常，同樣會造成整體業(yè)務不可用。如果不做任何修改，在后續(xù)上線運維的過程中，不論是因為壓力、系統(tǒng)還是其它原因，Register服務器都將會是一個巨大的技術(shù)風險。
針對上述問題，我們根據(jù)不同的場景推薦了兩種不同的解決方案：
管控分離，通過中心推送+本地緩存機制旁路Register。這種方案適用于調(diào)用邏輯較為簡單的情況；
影子備份，配置備用Register Server同步數(shù)據(jù)并切換。這種方案適用于注冊邏輯較為復雜的情況。
總結(jié)
本文主要簡單介紹了不同場景、不同游戲案例當中遇到的一些框架設計問題和解決方案。下篇文章，將會以對戰(zhàn)類全球服游戲為例，重點講講游戲架構(gòu)的設計思路與技術(shù)實現(xiàn)。
作者介紹
沈皓：UCloud PathX產(chǎn)品早期方案設計者之一，深耕全球服游戲領(lǐng)域，曾全面負責多個知名游戲的全球/跨國業(yè)務對接、部署及落地。對于MOBA、RTS、FPS等各類游戲的出海全球化的需求、難點、架構(gòu)實現(xiàn)等有獨到見解。
另外有需要云服務器可以了解下創(chuàng)新互聯(lián)cdcxhl.cn，海內(nèi)外云服務器15元起步，三天無理由+7*72小時售后在線，公司持有idc許可證，提供“云服務器、裸金屬服務器、高防服務器、香港服務器、美國服務器、虛擬主機、免備案服務器”等云主機租用服務以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務可用性高、性價比高”等特點與優(yōu)勢，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應用場景需求。
重慶分公司
重慶分公司
