隨着移動終端硬件配置的飛速提升，手遊行業開始從爆發期進入相對穩定的發展期。殘酷市場競爭環境下，遊戲公司紛紛尋求業務創新，手遊重度化、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等各類遊戲的出海全球化的需求、難點、架構實現等有獨到見解。