輕時代來臨架構師分享手游五大設計要點

簡體傳統

第一節：輕網游時代已經來了

　　“世界頻現三消，上帝也愛消除”，騰訊廣告做得不多，但這次做了，而且還涵蓋央視。廣告充滿了創意，很好的契合了最新推出的微信手游----天天愛消除。這款游戲不到三天即迅速獲得了超越2000W的下載量，并在后續取得了巨大的成功！天天酷跑、全民飛機大戰等后來的微信游戲在證明了自身產品優秀設計的同時也印證了一個新的時代----輕網游已經來臨。

第二節：輕網游的特點

　　輕網游以最新的微信游戲為代表，他們共同的特點是產品設計輕量化，沒有傳統端游的巨大安裝包，可占用玩家碎片化的時間隨時隨地利用手機等設備來體驗游戲并隨時可以中斷游戲。輕網游用三個字可以概括“小、輕、精”，小是指安裝包小；輕是指隨時隨地體驗和終止；精則是指產品品質精良。

第三節：輕網游設計要點

　　輕網游在設計上有著自己的特殊性，需要架構設計師在如下幾方面有全面的考慮；為便于后面詳細說明，先看某游戲的架構設計如下圖：

輕時代來臨資深架構師分享手游五大設計要點 ...

　　接入層：這里解決的是玩家的接入問題。玩家如何進入游戲，如何保持鏈接，相關資源的下載訪問速度如何解決都在這里要有設計和解決方案。

　　接入層主要問題一：帳號體系

　　各大開放平臺都有一套帳號體系，互不相同，設計師需要考慮好接入哪種帳號體系并在各個帳號體系中采用何種兼容策略；幸運的是騰訊有很強的帳號體系ptlogin可直接接入，大大降低了用戶進入的門檻。有些外部團隊則沒那么幸運，如果這個團隊不打算接入其他現有的帳號體系而自己獨立建設，那么成本高的會大大超出你的想象，有時候這也是團隊項目成敗的關鍵因素之一。

　　接入現有的帳號體系都比較完善了，不贅述；新建帳號體系需要額外重點考慮其安全性、穩定性和容災。帳號體系是比較獨立的系統可分解出來單獨闡述，這里與網游相關性較低，不贅述。但其設計原理與本文類似，可參照執行。

　　接入層主要問題二：負載均衡

　　負載均衡主要的目的在于削峰填谷、就近接入、解決跨網等問題；

　　削峰填谷：把流量智能導到負載比較低的服務器，但又不能形成訪問毛刺；

　　就近接入：把鏈接導向距離玩家比較近的服務器，通常這個鏈接質量較好

　　跨網問題：國內網絡很奇葩，跨網非常普遍的存在，有時候距離玩家更近的服務器是跨網的，這時候鏈接質量會變差，需要優先在同網內選擇服務器。

　　騰訊平臺典型的解決方案就是GSLB、TGW、CDN，這里不贅述，可單獨查閱資料了解。

　　接入層主要問題三：保持在線

　　網游的輕帶來的問題是玩家可能處于移動當中，隨時更換網絡狀態；頻繁的登入和注銷絕不是好主意，這里需要設計玩家狀態保持機制，避免不必要的登錄認證，以提升用戶游戲體驗。

　　邏輯層：通常游戲邏輯可在一個或者多個進程Gameserver中處理，現在服務器都為多核處理器，為充分發揮處理器的計算能力，建議選擇多個進程協同工作的方式。輕網游一般游戲邏輯較為簡單，邏輯進程通常分無狀態服務和有狀態服務兩種模式；

　　無狀態服務模式適合玩家交互不復雜的場景，這種場景不需要頻繁的訪問和修改玩家數據或者邏輯相對簡單；無狀態服務模式便于動態擴容和調度，可以做到玩家完全無感知。部落守衛戰就是采用無狀態服務模式開發的。這種模式在處理復雜交互的時候成本很高，需要頻繁訪問cache和DB，對編程要求也相對較高。

　　有狀態服務模式適合玩家間有復雜交互的場景，通常一組服務中存儲了大部分玩家數據，訪問cache和DB回寫的需求低，編程難度低；有狀態服務模式通常依賴于熱備來容災，有時對數據會有回檔的需求。對于輕網游來說，通常一組服務甚至可以部署在同一臺物理主機上以提升通訊效率和降低熱備部署要求；

　　各邏輯進程中的通訊方式可以通過共享內存、網絡等完成。比如騰訊組件TBus。

　　邏輯層通常還有很多全局公用服務。比如關系鏈、支付、商城、郵件、經分、安全等模塊。有一些系統需要抽離出來變成全局公用服務，解決共性的單一問題。已經有相當多的模塊建成了獨立的子系統，系統內部已經獨立運營，可以支持業務的灰度和容災，對業務則提供了接入SDK，大大降低了接入難度。

　　數據層：游戲數據的臨時及持久化方案在這里解決，cache是一種臨時的高效數據存儲單元，持久化數據則需要使用各種DB或文件來落地。

　　數據層問題一：Cache

　　除了本機內存用作臨時的cache存儲數據外，還有很多公用的開源組件可供選擇，比如Memcached， CMEM等。選擇cache組件的時候要充分考慮系統對cache分布能力、災備能力、存儲能力等的需求；有狀態的服務多采用本地共享內存，無狀態服務多采用分布能力、容災能力較強的公用組件如Memcached。由于往往cache無法緩存所有數據，這時候需要設計cache的淘汰策略，按照熱度淘汰往往效果不錯；硬件越來越便宜，使用超大內存盡可能多的緩存數據甚至全部數據也是一種不錯的方案。如果簡單的增加內存就可解決問題，就不要太在乎硬件成本，那根本不值得設計者為其絞盡腦汁，因為增加內存太廉價高效了。

　　數據層問題二：DB

　　輕網游對存儲要求依賴于系統的規模，在設計之初要充分考慮，可通過各種數據模型估算出整個系統對數據的存儲規模，這非常關鍵，在這里太短視或者懶惰會導致后期的維護及修改成本非常高昂。

　　通常mySql是不錯的選擇，redis也不錯，他們適合小型游戲的存儲，在分布、災備方面做得還不夠，仍需要有更多設計和考慮；幸運的是公司這方面有很多可供使用的系統如CDB、GCS等等，可分別詳細了解并根據需求選擇。

　　數據庫的表設計通常需要避免同一張表中有太多的記錄，mysql中一張表的記錄在百萬級別就差不多了，不宜超過千萬，可通過分庫分表的方式減小表的記錄數。這會大大提高數據庫的查詢效率。

第四節：輕網游的灰度、擴容和容災

　　灰度

　　輕網游的研發周期一般都不長，研發人員沒有足夠的時間去充分測試和驗證各系統，團隊往往通過運營一個灰度版本的方式來試錯。通常體驗服、搶先服都是這類方法。即使是正式服，有時候也有必要跟據玩家屬性進行必要的游戲內容控制，這些在設計之初都必須充分考慮并合理設計。灰度做得好，產品就多了一個保證，可以讓運營上更加靈活，控制事故對項目的影響范圍。

　　擴容

　　游戲一旦在線上，很多需求都是用戶和運營驅動的，玩家爆炸式的來臨的時候，系統需要有足夠的靈活性以迅速響應。設計師需要了解運營策略，并根據數據模型對擴容提前做出設計。全區全服的游戲可隨著玩家的情況動態擴容，分區分服的游戲則需要不停的開新服、合老服；這些必須在設計之初進行充分設計。而有些系統并非項目組內可控制比如GSLB，需要對相關系統的容量及擴容策略有足夠的了解。有些系統需要項目組來申請才會擴容。

　　容災

　　系統一旦出現了問題，這時候災備策略就非常重要。設計者要悲觀思維，充分考慮每個節點的容災設計，做到萬無一失。沒有無故障的系統，只有無故障的設計。優秀的設計會是系統良好運營的保障。系統中不同模塊的容災策略也有區別，熱備、冷備要根據系統進行合理選擇。

第五節：更新及安全

　　更新

　　更新是輕網游的重要組成部分，同傳統的端游、頁游等PC平臺上的游戲不同，以手機為代表的輕網游對游戲安裝包非常敏感。設計師需要針對不同用戶場景設計系統的更新策略，需要保持版本兼容性的同時又要兼顧不同版本、不同終端的玩家的游戲體驗。這是一個很難權衡的工作，設計師必須做出一個合適的選擇。通常第一個安裝包要夠小，至少要做到不太大，這樣有利于產品用戶的新進；軟件更新則需要跟據用戶不同的網絡條件給出差異化的選擇，移動網絡狀態下盡量減少不必要的更新，待用戶在Wifi狀態下則可以進行較大的版本更新；設計不好的更新策略會導致玩家迅速流失，有時候只是一個更新時機的選擇問題，有時候就是一個友好的提示，就這么簡單。

　　安全：外掛和反作弊

　　外掛的多少有時也是判斷游戲是否成功和有影響力的標志，外掛泛濫也會導致一款良好的游戲夭折；設計師要設計好一整套立體的反作弊檢測及運營處理機制，從客戶端一直到后端，反作弊的檢測無刻不在。對內存的保護、協議的加密、異常數據檢測都非常基礎但也非常重要；還有對前端傳來的數據都必須懷疑檢測，不信任前端通常是正確的。完善的日志記錄和保存也是反作弊的重要手段，有時候這需要消耗大量的存儲空間，設計師必須做好準備。