1. 時代背景

隨著移動裝置以及網路的飛速發展，傳統的“人機大戰“已不能滿足各類玩家的口味，故而各大遊戲廠商皆將“魔爪”伸向了移動端，至此手機網路遊戲應運而生……。對於遊戲運維而言，從“頁遊摸爬滾打”多年，一朝轉至手遊時代，無疑面臨一種新的挑戰！

2. 淺析手遊架構

傳統的手遊架構基本是由頁遊的模式轉變而來的，即開服型架構。

此架構的特點：遊戲由眾小的世界組成，各世界的玩家基本上沒有互動，像是兩條永不相交的平行線，對於一些關係較為親密（基友）的玩家，受制於各種因素，要想一開始就在同個世界中“仗劍走天涯”，無疑是一種奢望。當然說到這裡可能會有讀者反駁，不是可以通過合服解決這個問題嗎？於此同時，我只能對付之一“蜜汁微笑”……

時下，遊戲行業躡景追風，為了滿足各類玩家的需求，衍生出了另一種架構型別的遊戲，大世界型架構。

從字面上不難看出，該型別遊戲好比我們現在的“地球村“的概念，不管你在何處，都可以匯聚到一塊進行遊戲，從此，”攜基仗劍天涯“不是夢……

以上是以玩家的視角來看開服型和大世界型遊戲各自的特點。

那麼在遊戲運維眼中“開服型”和“大世界型”遊戲的架構是怎樣的呢？（無圖講卵）

圖1 手遊開服型架構圖

圖1，我們可以看到開服型手遊幾個特點：

1） 每個區服都是一個獨立的點，各個區服之間不會相互影響；

2） 支援異地跨機房部署，單個機房故障，只會影響該機房的區服，不會影響全域性；

3） 每個區服都有自己對應的資料庫，各個區服資料庫獨立不會相互影響；

4） 現有區服不能承載時，新開區服，引導玩家，進行分流。

圖2 手遊大世界型遊戲

圖2，大世界型別遊戲的特點：

1） 後端沒有區服的概念，類似於開服型只有一個區服；

2） 後端對應功能稱為節點，節點與節點之間需要相互通訊；

3） 理論支援跨機房擴充套件部署，但是由於各個節點之間的網路通訊要求比較高，實際實施起來存在問題；

4） 整個世界遊戲庫只有一個，這也勢必會引發一些問題，例如，資料量大，造成資料庫過於龐大，當然這裡我們可以考慮分庫和分割槽；

5） 除公共節點，某個遊戲節點故障，只會影響該節點玩家，其餘節點不受影響，故爾關鍵的公共節點就顯得尤為重要。

3. “手遊”我們都對你做了什麼

3.1 “雞蛋同籃”的尷尬？

身處“天朝”的我們，都能清晰的感受到我天朝網路環境複雜之甚，無法比擬。作為遊戲運維的我們對玩家所處之“境遇“（網路環境），感同深受。為不因此，讓玩家對我們的遊戲失去青睞，我們深表應該做點什麼，改善部分玩家的遊戲體驗……

在此我們引入了“BGP轉發”服務，閱讀過本公眾號前幾期文章的讀者對此服務應該有一定的瞭解。那麼我們來看下如何利用該服務，並且藉助IDC機房專線直連，打通IDC機房間的內網方案，實現業務在網路上的異地雙活：

圖3 BGP轉發服務在大世界上的應用

該架構的特點：

1) 南北IDC機房通過專線直連，並且打通內網；

2) 業務主要部署在北方IDC機房；

3) 在南方機房部署BGP轉發服務；

4) 正常情況下，玩家是直接請求北方機房的業務，當南北骨幹網路異常時，南方玩家請求北方機房就存在異常，此時，我們可以讓南方玩家直接請求南方的BGP服務，並通過此服務將玩家請求通過南北專線，轉發至業務所在的北方機房，從而減小此類網路問題對我們業務的影響；

5) 當業務所在機房的網路出現異常，只要南北專線保持暢通，就可以將玩家的請求從南方的BGP轉發服務，通過專線轉發至業務所在機房，這也是我們在應對DDOS攻擊的一個策略。

另外，我們也可以將大世界的節點分別部署在不同的機房，並通過南北專線進行相連，這樣我們就可以將客戶端請求域名就近解析，玩家就可以就近進行訪問，從而提高玩家訪問效率。當一處機房出現故障，我們可以將業務切至另一處機房，從而實現業務在一定程度上的高可用。

圖4 BGP大世界型別遊戲異地雙活方案

當然，要實現業務真正意義上的異地雙活，我們需要考慮的因素會有許多，例如，異地機房的資料同步問題是諸多因素中的一個重要因素。

3.2 “蜜汁”監控——運維利劍組合

作為運維人員，要想做到於細微之處讓整個系統張弛有度，獲得上佳表現，當然離不開全面的監控系統，而單一的監控系統又很難滿足我們日常所需的“立體化”的監控效果，故而多種監控系統組合使用，成為我們日常運維工作中必不可少的環節。

下面就談一談我廠的組合式監控系統是怎樣為遊戲保駕護航的。

業界公認的zabbix系統：可以說運維人員所關注的伺服器幾項指標（CPU、記憶體、磁碟、資料庫、流量等）都可以做到很好的支援。同時，也可進行定製化服務的監控（程序、埠、連結數等）。還有就是針對單個專案應用的伺服器我們比較關注的監控項，做彙總展示，可以直觀的觀察到該專案的伺服器健康狀況。

圖5 某遊戲專案伺服器CPU空閒率彙總圖

全網監控系統：zabbix固然可以滿足我們大多數的監控需求，但是對於一個服務“四海八荒九州“的遊戲廠商，多個IDC機房之間的業務交織所面臨的監控需求，就顯得”捉襟見肘“了。全網監控系統（我廠自主研發）的誕生無疑是應對此問題的”利器“。

監控系統在全國預埋分散式監控節點做網路撥測監控，撥測資料統一排程上報到監控中心。監控中心基於大資料分析，以三不“不濫發、不誤發、不漏發”為何核心思想，快速準確識別網路故障，實時報警通知運維。

說到這裡大家可能會好奇，這個系統主要應對那些監控內容呢？

機房監控主要的故障型別：機櫃故障、網段故障、線路故障、機房故障等。

機房監控主要的故障型別：機房級故障、市級故障、區域級故障等。

當然，實時的顯示IDC機房到我天朝各個省會城市的網路狀況，即全國MAP，也是該系統的一大亮點。

圖6 機櫃故障

圖7 市級故障

以上是針對伺服器和IDC機房的監控，你以為這就足夠了嗎？當然不夠，對於一款獨立的遊戲專案，我們怎麼才能做到於細微處見“真章”呢？

APM應用效能監控系統：主要是客戶端與服務端的通訊互動透明化，方便我們以真實玩家的報障資料為分析物件，準確、有效地定位異常問題。

3.3 資料容災哪家強，無須山東找“藍翔”

眾所周知，資料庫備份是運維工作中最重要的一個環節，因為一旦丟失資料，造成的後果將是不可挽救的。在這裡簡單描述下我廠的資料庫備份策略，供大家探討。

下面是我廠的資料庫備份流程圖：

圖8 資料庫備份流程圖

有了定時有效的資料庫備份，才是我們遇到資料異常回檔的首要條件。

目前我廠遇到的資料恢復方案有：

定點恢復（回檔）：定點完整備份+binlog恢復至幾天內的任意時間點（取決於binlog保留的時間段）；

區域性資料恢復：採用binlog回滾原理，對區域性資料進行恢復（有一定侷限型）；

兩個方案均有其優缺點和應用場景，具體有關資料庫回檔的方案，詳見運維軍團公眾號（ywjtshare）的前期文章《只需一招，讓失控的研發哥愛上你》（特此宣告：這名字不是我起的，筆者是直男）。

3.4手遊客戶端自動化打包利器

筆者不知貴廠手遊客戶端打包流程是怎樣的，在此，就我廠手遊客戶端打包流程描述一二，僅供各位讀者參考：

我廠手遊客戶端打包大致分為三個階段：

第一個階段：純手工階段（費時，費力，費分工）；

第二個階段：手工階段+部分專案的打包後臺（紛繁蕪雜，不易管理）；

第三個階段：客戶端打包一體化後臺（統一化管理，多人協作，自動化）。

前兩個階段這裡不做贅述，主要介紹下第三個階段：客戶端打包一體化後臺，主要基於流程化管理，藉助工具的流程組合，將客戶端打包所涉及的步驟工具化，從而根據工具建立自己的打包流程，開始打包即可。打包過程無需人工干預，同時具備多人協作的功能。

圖9 手遊客戶端自動化打包流程

4. 結束語

以上是我廠針對手遊的部分運維服務方案，當然也有不足的地方需要不斷的進行摸索和完善。

“天下事常出於人意料之外，志同道合，便能引起類。” 我們是一個成長中的團隊，期待和各位同仁為遊戲運維行業多做一份貢獻。

這個行業需要科學（規範），需要藝術（直覺），需要革新（創造），也需要謙卑（敬畏）。相信，我們一直在路上不斷前行……

文章來自微信公眾號：運維軍團