游戲開發經驗談（一）：游戲架構里隱藏的五個坑及其應對方案

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

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

場景A：All In One的MudOS架構

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

以當前的技術來說，公有云還沒能完全避免宕機對業務造成的影響，而宕機必然要導致業務一段時間內的不可用。一旦出現云主機內部系統崩潰，對于這種架構的服務器更是災難性的。因為時間和數據都很難保證，最終可能必須通過備份文件才能進行回檔。

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

場景B：瘋狂掉線

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

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

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

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

場景C：單點DB的危機

下圖的業務架構設計得已經相對完整，整個系統采用的是DB的主從架構，可能宕機造成的風險都已經規避，唯一的疏漏在于用戶將Cache和業務綁定，一旦業務重啟，整個Cache就會被清空，同時如果Cache達到上限也造成業務異常。

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

為了避免這種情況再次發生，后續用戶直接將Cache層拆分出來放到我們的高可用Redis上來保證系統的穩定。

場景D：Redis崩潰

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

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

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

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

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

場景E：Register Server 單點

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

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

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

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

總結

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

作者介紹

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