精通手游運維的架構體系

關于手游

概要

2015年第一季度，中國網絡游戲市場規模達到320.8億，環比增長8.0%，同比增長24.7%。其中移動游戲占比31.0%。相對于傳統的端游，手游的興起給運維工程師的技術能力和運維理念都帶來了巨大的挑戰。這是因為手游在技術架構、運維體系方面存在眾多特殊的要求。本文首先分析手游運維的特點，然后再從手游的架構、容量規劃兩大方面給出最佳實踐的推薦。

在手游運維領域，我們經常會聽到一些專用名詞，在這里我們首先對這些專用名詞進行簡單說明以期讀者能對手游運維有個概念的認識：

• 手游開發商：也叫CP，即Content Provider，內容提供商的英文首字母縮寫。顧名思義，就是指制作手游產品的研發公司或者團隊。例如研發《刀塔傳奇》的莉莉絲團隊等。

• 手游發行商（運營商）：即代理手游CP開發出來的手游產品，在部分渠道或者全渠道發行CP手游產品的公司。一般由手游發行商進行手游運維工作的實施。例如盛大游戲、龍圖游戲等。

• 手游渠道：擁有手機端手游和APP用戶，能夠進行手游和APP流量分發的公司，即可成為渠道。所有可以獲取手游用戶的平臺都可以稱為渠道。例如蘋果應用商店、Google應用商店、騰訊應用寶、百度手機助手等。

• 下載數：手游客戶端被下載的次數。

• 激活數：用戶下載安裝游戲后，打開游戲，但未進行注冊前，記錄的終端數。

• 注冊數：用戶激活后，進行了自動或者手動注冊有ID信息或者賬戶信息的賬戶數。

• 日活躍登陸數(每日登陸用戶數DAU)：用戶輸入完身份信息后，進入到游戲內的賬戶數。同一日多次登陸的同一個玩家計數為1。

• 日最高在線數：每日每個時刻，同時進行手游操作的玩家數量的最高值。

上述幾個指標中，下載數、激活數、注冊數是預估手游公測首日可能帶來的用戶導入量的最重要評估依據。

日活躍登陸數，特別是公測首日的活躍登陸數，是評估手游發行效果的重要數據。

日最高在線數的承載能力是進行容量規劃時需要滿足的服務能力。

手游和端游運維的異同點

在推薦手游架構之前，我們需要深入了解手游運維和端游運維的異同點，以此分析為基礎，再推導出合理的手游架構。

手游運維和端游運維的共同點和區別主要體現在下述四個方面：

1. 操作系統層面：手游運維和端游運維，都需要對底層操作系統有較深的理解。區別是手游運維中使用Linux等開源操作系統的較普遍；端游運維根據不同的開發商可能Microsoft Windows和Linux都占有一定的比例。

2. 聯網方式：在客戶端和服務器端通信方式上，端游要求客戶端強聯網，一般使用在TCP協議之上實現私有協議。這樣的好處是可以實現長連接和提高交互性；手游一般采用弱聯網方式，使用HTTP協議進行通訊。

3. 游戲周期：手游生命周期較短，玩家涌入的時間比較集中。因此在架構設計時，需要充分考慮橫向擴展的需求。

4. 游戲是否分區：手游開放公測時，一般不使用分區的方式，即所有玩家直接在一個大區里面進行游戲；而端游往往采用分區制，各個分區的玩家之間無數據交互。手游不分區的運營方式，使得服務器壓力集中，對于運維要求更高。例如，如何解決數據庫的集中壓力問題及游戲服務器的壓力分擔問題等，都是運維人員需要考慮的。

最佳實踐：推薦的手游架構

目前的大部分手游在設計客戶端和服務器端通信模型時，采用了HTTP協議。

使用HTTP協議的優點

使用HTTP協議的通信方式，有以下的優點：

1. HTTP協議是成熟的應用層協議，有豐富的客戶端和服務器庫函數加以復用，相對于完全自主開發基于TCP的通信協議，開發效率更高，可能遇到的bug更少。

2. 使用HTTP協議更容易利用到現有成熟的周邊基礎設施，例如通用的負載均衡軟件或者硬件等。

3. 易于實現壓縮。HTTP協議本身支持應用程序以外的由Web服務器提供的壓縮功能，減少客戶端和服務器端的數據傳輸量。

4. 利用HTTP的Session和Cookie機制，易于實現會話保持機制。

5. 易于實現加密。在HTTP層之上，直接使用SSL協議（HTTPS）即可實現關鍵信息的加密傳輸。

推薦的網絡架構

基于上述分析，并結合盛大游戲在運維大型手游過程中的實踐經驗，我們推薦實施這樣的網絡手游架構：

圖1 推薦的手游架構圖

在設計這樣的手游架構時，我們重點考慮的幾個方面如下：

• 負載均衡器 ：

  1. 使用商業硬件實現。采用商業硬件的負載均衡可以最大程度的保障業務穩定性。

  2. 使用雙機熱備（HA），規避單點故障。

  3. 使用NAT模式。在手游架構中，實際負責游戲邏輯的Web服務器組和玩家之間的數據流量，一般不大。根據我們的經驗，在5萬人同時在線的手游，帶寬使用800Mbs左右。使用NAT模式的負載均衡方案完全可以滿足需求；同時對于Web服務器來說，不需要配置外網IP，節省IP費用及提高安全性。

• 雙上聯的鏈接方式 ：

  1. 負載均衡器和核心交換機使用雙上聯，避免單一核心交換機故障導致的網絡中斷。

  2. 接入層交換機接入核心交換機時，采用雙上聯，并且做PortChannel，保障雙鏈路可用的情況下，同時提高吞吐量。

• Web服務器組

  配置高頻CPU。作為手游邏輯的主要處理單元，Web服務器往往執行大量的CPU運算，比如玩家攻擊能力計算、攻擊效果計算等。

• Memcached服務器組

  這個服務組的作用一般包括預加載配置項以及緩存數據庫查詢結果等。使用Memcached提供的高效內存緩存，可以提高響應速度。

• 數據庫服務器組

  為游戲數據提供持久存儲。

  在這樣的架構設計中，體現手游運維對于高可用性、安全性、高性能的要求。在運維人員設計相關規劃時，可以參考該架構進行實施。

最佳實踐：手游容量規劃

如上文所說，手游相對于端游的生命周期更短，因而留給運維人員的準備時間也就更少。這就要求我們在短時間內對手游運營需要的各種資源規劃到位，手游容量規劃是一個必不可少的環節。

容量規劃（Capacity Planning），是指在系統上線前或系統運營過程中，通過分析業務走向，對系統需要的各種網絡、計算、存儲資源進行提前規劃和準備。目的是在這種業務變化時，系統承載能力可以隨著要求變化進行靈活的應對。

多線機房的選擇

為了用戶在3G、4G、WIFI（中國電信接入、中國聯通接入、中國移動固網接入）等終端網絡切換時得到良好的游戲體驗，手游服務器需要部署在多線機房，由此可以很好的滿足用戶多種方式上網的需求。

如下圖所示是我們某個手游玩家按照ISP來源的分布情況：

圖2 手游玩家ISP分布

由上圖，也驗證了我們必須把服務器部署在多線機房，以滿足不同接入的手游玩家。

多線機房的實現原理和特點如下：

1. 多條光纜：數據中心為適應不同用戶對不同網絡訪問量的不同需求，采用多條高帶寬（例如40G）光纖鏈路連接到Internet。
2. 10G出口帶寬：連接到中國電信、中國聯通的出口帶寬均超過10G以上。
3. BGP4收取路由：各條鏈路均采用BGP4收取路由，并進行相應的策略設置，保證用戶訪問不同網絡的訪問速度。
4. 各條出口互為備份：在其中一條鏈路出現故障的時候，所有流量通過其他鏈路出入，不會出現單鏈路故障，提高了可靠性。
5. 突破限制：突破了ISP出口受中國電信和中國聯通互連帶寬瓶頸及訪問國際網站的限制。

高速Internet接入、冗余的網絡和帶寬管理系統保證接入帶寬可根據用戶流量的需求隨時擴充，充分滿足用戶日益增長的網絡應用需求。

在選擇和對比多個多線機房時，機房的冗余帶寬、對抗DDOS攻擊的能力，是評估的2個最重要方面。高冗余帶寬（10G以上）、高抗DDOS能力（20G以上），是我們傾向的選擇。

網絡帶寬容量規劃

網絡帶寬規劃的數據來源主要有兩個：一個是在小規模測試時收集到的玩家平均帶寬使用量，以kbps/每玩家計算；另一個是使用機器人（指能夠模擬玩家進行游戲內容測試的自動化程序）測試時收集到的類似數據。

在進行網絡帶寬規劃時，需要對以下三個方面的內容分別進行評估：

1. 正常流量規劃。評估方法是根據玩家在正常進行游戲時，每玩家帶寬使用量與預估的同時在線人數的乘積。

2. 手游客戶端更新容量規劃。評估方法是根據手游客戶端的更新內容大小乘以預估的公測當日導入的手游玩家數量。手游客戶端更新通過接入外部CDN可以適當分擔流量壓力。

3. 異常流量規劃。這個主要是指在手游運維中，受到大規模DDOS攻擊時的處理規劃。在進行這種容量規劃時，需要充分考慮到機房運營商接入的帶寬，采用分級規劃。在第一級小規模DDOS時（小于5G），啟用自有的流量清洗設備。在更大規模的DDOS時，啟用運營商級別的保護，以降級服務的方式，阻止來自某一方向的攻擊流量（該方向的正常訪問也會受到影響）。

Web服務器承載能力規劃

在規劃Web服務器承載能力前，需要分析目前的計算瓶頸。

以PHP FPM類型的Web應用程序為例，有以下的兩個參數務必需要設置：

1. slowlog /var/log/php-fpm-slow.log。用于指定PHP執行時慢日志的記錄位置。PHP慢日志，用于定位PHP程序執行慢的原因，是最重要的日志。

2. request_slowlog_timeout 1s。用于指定對于執行時間超過1s的PHP腳本，記錄程序執行調用情況（backtrace）到slowlog指定的位置。

在Java程序中，可以使用Log4j在關鍵調用處記錄相應的執行時間，如對外部API請求、對數據庫調用、對緩存服務器調用、排名計算等等。通過這些數據，我們能夠獲取到可能影響系統性能的關鍵信息，在有針對性的解決后，再進行相應的容量規劃。

Web服務器負責對手游業務邏輯的處理，對CPU要求較高。因有負載均衡設備調度，單臺服務器對可靠性要求不高。如果服務器宕機，由于調度系統的存在，系統會自動把請求切換到其他服務器上，給玩家造成的影響較小，這點就和端游不一樣（端游上玩家會掉線）。對單服務器要求較低，服務器選型上可有更多的選擇，比如說采用一些多節點服務器。在壓力測試時，我們首先在負載均衡器上設置流量只分配給一臺服務器，然后評估它的壓力情況。以此數據作為支撐，可以計算出總計需要的Web服務器數量為預計最大同時在線玩家數除以單臺承載能力。

Memcached承載能力規劃

Memcached服務器組為Web服務器組提供緩存服務，同時減輕了數據庫的查詢壓力。

Memcached是基于內存的key-value型緩存，無磁盤IO讀寫，效率非常高。在對Memcached進行容量規劃時，我們需要關注的是熱點緩存數據的分布情況。

熱點緩存數據，是指Web服務器程序請求次數最多、產生最大網絡流量的緩存數據。如果熱點數據比較分散，我們可以部署多臺Memcached同時使用客戶端對key哈希的方法（如一致性哈希算法）進行壓力分擔。盛大游戲遇到過一個極端情況是，熱點緩存數據集中在某個key上。此時，使用客戶端哈希是沒有效果的（因為一個key只能分布在一臺服務器上），達不到壓力分擔的效果。

如下圖所示，其中一臺在線Memcached的帶寬使用已達到瓶頸：

圖3 單臺Memached帶寬使用量

單一熱點數據產生大量帶寬需求的情況下，可以使用的方案是對緩存服務器進行網絡端口Bonding。關于使用Bonding方法提高帶寬吞吐量的方法，請參閱《Linux運維最佳實踐》一書“第3章 概述負載均衡和高可用技術”的內容。

對Memcached熱點數據的分析，推薦使用memkeys工具。memkeys是tumblr開源的類似top的工具，可用于實時查看memcached的key使用情況。

memkeys的安裝命令如下：

• wget http://ftp.gnu.org/gnu/autoconf/autoconf-latest.tar.gz #下載autoconf

• tar zxvf autoconf-latest.tar.gz

• cd autoconf-2.69/

• ./configure

• make

• make install

• yum -y install gcc-c++ pcre-devel libpcap-devel #安裝依賴庫

• git clone https://github.com/tumblr/memkeys.git #下載memkeys源代碼

• cd memkeys

• export CXX=g++44

• ./autogen.sh

• ./configure

• make

• make install

memkeys的使用方法如下：

• /usr/local/bin/memkeys -i eth0 -r 10 #-i指定網絡端口，-r指定輸出的刷新頻率

由此，我們可以按照單位時間內請求次數、帶寬使用率來排序分析出熱點數據。如下圖所示，memkeys的輸出格式為：

通過對當前Memcached的請求情況分析，可以有效的判斷是熱點數據的分別是否均衡。

另外一個需要注意的事項是Memcached的啟動參數，默認情況下，它支持的并發連接數是1024，如下所示：

• memcached -h

• -c <num>      max simultaneous connections (default: 1024)

在上線前，務必要提高該值。在我們的實踐中，曾經發生過因為前端服務器過于繁忙導致連接數用光的情況。Memcached當前的連接數情況，使用如下命令獲取：

• [root@master ~]# telnet 127.0.0.1 11211

• Trying 127.0.0.1...

• Connected to 127.0.0.1.

• Escape character is '^]'.

• stats

• STAT pid 23341

• STAT curr_connections 2000 #當前連接數

數據庫承載能力規劃

數據庫存儲了手游中的持久化數據，提高數據庫的響應效率對提高手游體驗起到關鍵作用。進行數據庫容量規劃時，需要嚴格按照以下的規則進行：

1、數據庫配置參數、表結構和SQL語句評估。

進行數據庫評估的目的是分析數據庫軟件配置參數與硬件能力是否匹配、分析表設計與SQL語句的效率關系。

以MySQL為例，在數據庫配置參數方面，主要考慮增加innodb_buffer_pool_size為系統可用內存的60%。分析數據庫表結構設計時，對主鍵、索引是否完整、有冗余、表引擎的一致性、字段類型的高效性進行分析。SQL語句評估時，考慮對多表聯合查詢、limit、復雜查詢語句進行優化。在無法直接進行SQL語句優化的條件下，可以考慮通過業務邏輯的調整來減小數據庫壓力（這一步可能涉及到游戲策劃、產品經理的溝通，一般比較難）。

2、 數據庫分庫分表設計。 對于訪問頻繁的數據量巨大的表，如用戶注冊表，必須采用拆分的方法，使其分布在不同的數據庫服務器上。對于log庫，由于其對于游戲來說，是非核心數據，也需要單獨拆分，以緩解核心數據庫的壓力。

3、 使用數據庫讀寫分離技術。 數據庫讀寫分離技術，在數據庫分庫分表的基礎上，又進行了一層壓力分解。在MySQL中，通過配置主從復制（Replication）可以獲得以下的好處：

• 在從庫上進行讀取操作，可以進一步減少主庫的讀壓力。

• 在專用的從庫上進行數據備份時，不影響在線業務。

• 在專用的從庫上進行數據分析和挖掘時，不影響在線業務。

4、 使用SSD提高隨機讀寫iops。 手游的大區制，使得數據庫的壓力被集中起來，同時不同等級的玩家所具有的不同的游戲行為也加劇了對數據庫的壓力。使用SSD可以最大限度的提高服務器的iops，以應對這種讀寫壓力。

5、 存儲容量規劃。 在數據庫中，一般會記錄較長時間的玩家游戲日志，這一部分數據隨著運營時間的增加，對存儲容量要求越來越多。評估方法是根據內測期間玩家數量和日志數據量計算出，每日每玩家大概產生的數據量。所需要的存儲容量為每日每玩家大概產生的數據量乘以保留天數再乘以每日預估玩家數量。

官網論壇訪問能力規劃

在手游運維時，除了考慮到手游系統之外，還應該考慮官網、論壇等的訪問能力。

在游戲維護期間，玩家往往會轉向到官網和論壇，此時會產生大量的并發請求。官網和論壇基本都是基于Web的服務，考慮容量規劃時，可以參照本文Web服務器承載能力規劃的內容。

人數曲線接入

人數曲線實時地反映了在線玩家的情況，也同時能夠反映游戲系統運行狀態。

在設計人數曲線接入時，我們使用了基于Web請求日志分析的方式。人數曲線的接入步驟如下：

1. 在Web服務器上記錄玩家客戶端的Cookie字符串。

2. 分析5分鐘內的Cookie，去除重復值后的數量作為當前在線人數。

3. 統計數據寫入人數數據庫。

4. 圖表展示。

小結

手游是近年來網絡游戲領域中異軍突起的一個重要分支，得到越來越多游戲公司的重視。掌握手游運維的關鍵技術，是提高運維人員自身價值的必要手段。本文從架構角度切入，給出了盛大游戲推薦的設計思路。希望能夠幫助讀者從宏觀上把握手游運維體系的特點。手游上線前的容量規劃，是保障手游系統不被過載、保障業務穩定性的關鍵環節。文章從機房、網絡到各種角色服務器組的容量規劃進行了深入探討，如果讀者在進行容量規劃時能夠遵循這些建議，那么我們可以對系統承載能力做到胸有成竹、從容不迫。

 

 

來自：http://www.infoq.com/cn/articles/architecture-of-mobile-games-operation-and-maintenance