偶然在網上看到游族網絡運維總監李志勇先生進行的一次分享，作為一個運維人，對其中的運維思想贊嘆不已，今天特別發出來給大家做個參考，同時也希望和大家就李先生的這次分享進行探討，歡迎各位在評論區留言。

本次分享主題為“如何運維千臺以上游戲云服務器”。重點是云時代的運維，包括游戲上云部署整體方案、游戲服務器批量運維管理，并對企業選擇RDS還是自建MySQL數據庫給出了自己建議。

游戲產品架構進化史

圖一：游戲產品架構進化史

經過近七年的高速發展，公司游戲服務器從100臺增長到10000+臺，游族整體游戲架構也經過了三個階段的演變：

• 公司早期廣泛使用的第一代架構，當時主流的產品都是以DB+計算+前端這樣的3個角色開發設計并部署，服務器以物理機為主，一個游戲區組需要2~4臺服務器，不同的機器承擔不同的角色。這種架構方案效率低，基本上不可能實現一天開100個區組（100個區組大概需要400臺服務器）；
• 隨著業務量的增長和虛擬化技術廣泛使用，游族整體游戲架構更新為第二代架構，全面采用虛擬化技術，把一臺高配的物理機器虛擬化成多臺符合游戲需求的虛擬機來使用，并實現了ALL IN ONE的系統架構。該架構方案運維效率高，適合規模開展游戲運營，但不具備業務高可用特性，一天開100個區組成為常態；
• 為了迎合大區大服、全球同服，游族融合了前兩代架構的特點，推出了第三代架構，按角色分拆并形成服務集群模式。集群架構結合了物理機與虛擬化的優勢，實現彈性擴容，游戲邏輯以服務進程或集群配置項的形式提供服務。該架構方案運維效率更高，可實現秒級開服同時具備業務高可用特性。

基于第二代架構，游族基于OpenStack自己的私有云，最初目標是為了提高服務器利用率、降低成本和實現分鐘級開服。運維團隊以OpenStack G版為藍本進行調優并修改；整個網絡采用的是VLAN模式，保證最大限度與現有網絡架構保持兼容；存儲方面使用本地磁盤作為存儲。

通過底層優化后，游族私有云基本上可以滿足業務的需求，目前90%游戲業務運行在上面，虛機規模持續保持在10000臺以上，游族私有云平臺沒有提供WEB管理界面，日常所有的操作都是通過命令行和腳本的形式進行操作，但對于虛擬機的增刪查改，重新封裝了一層簡潔的API接口實現與游族運維平臺的對接。經過評估測驗，在高峰時期，整個私有云資源利用率可達到83%。

?運維方式的轉變

與三代架構相互對應是游族運維的三個階段：

• 在第一代架構上，運維基本是手工運維，技術含量并不高，純粹是采用人與時間堆積進行，運維同學需要登錄每一臺服務器，順序執行相關的命令和腳本。獨立的版控服務器，通過主動推送的形式進行版本更新；
• 在第二代架構上，通過自動化工具進行批量運維，團隊推出了使用expect寫的auto批量腳本，所有操作只需登錄一臺集控服務器執行批量并發操作的腳本，獨立的版控服務器，通過并行的主動推送；
• 在第三代架構上，可以實現系統化運維，多個運維系統相互協調配合實現，例如：CMDB、業務樹、作業平臺等。游戲區組搭建的時間基本上可以忽略（可按需求實現按條件觸發或手動觸發搭建操作），所有的更新操作在WEB管理平臺就可完成。

?游族作業平臺UJOBS

圖二：UJOBS架構及其游戲更新流程

系統化運維過程中使用的作業平臺（UJOBS）是屬于C/S的架構，其核心部分由任務調度器和agent組成，通過調用API接口完成多種形式的指令下發。UJOBS簡單的來說是為服務器管理提供了執行命令的通道，將所有的執行命令和腳本在目標服務器橫向執行完，把輸出結果記錄日志里面，同時可通過WEB界面實時查看分析。任務調度器是用來全局策略控制，進行并發量控制。任務列表里面保存任務的完整信息。指令倉庫保存常用的命令個腳本和上下文關聯的命令組合。

在UJOBS平臺上，游戲版本更新流程如下：

1. 版本庫的版本變更自動觸發構建；
2. 從版本庫拉取變更后的版本文件；
3. ?通過構建操作后，推送目標程序到分布式的全局版控服務器集群；
4. 在作業平臺下發更新操作后，UJOBS的agent取得該次更新的版控服務器地址、變更清單以及版本信息；
5. 從版控服務器拉取更新文件到本地執行預定的更新腳本。

同時在UJOBS執行的過程中可實時查看輸出的日志。當游戲版本更新出現異常，有兩種回滾方式：第一種，游戲服務器上保留歷史版本，異常時回退到歷史版本；第二種，覆蓋回滾，將老版本再次發布進行回滾。

?數據庫備份與恢復

相對于游戲版本更新備份而言，數據庫備份更為重要。ALLINONE模式或者非集群模式的游戲業務場景下，會存在多達好幾千個MySQL實例，若是要按常規的MySQL備份方案來實施，管理難度和成本都要翻好倍。因此游族網絡采用Xtrabackup在主庫上直接備份數據文件方式，備份文件暫存本地；本地備份完成后在備份系統選舉一臺遠程服務器進行異地備份；備份策略每小時一次備份，半小時本地備份半小時遠程備份。該備份方法在單主庫業務場景下可能是最靠譜的數據備份方案，但備份過程對主庫會有影響、（限制IO操作），最壞情況下可能出現1小時的數據丟失（業務接受少量的數據丟失）。

在數據恢復方面，通過一鍵恢復工具，只需要提供恢復的IP、時間段和業務信息（如庫名）即可實現數據恢復；24小時內的數據通過本地的數據恢復（結合二進制日志），超過24小時的數據通過異地數據恢復。

?云上遷移歷程

現在游族已經將幾款老游戲遷移到阿里云上。在將ALLINONE架構平滑遷移到云上的過程中，首先要求就是遷移過程不能長時間停服，只能接受正常的版本更新的停服時間。整個遷移過程分為以下幾步：

• 第一步提前準備資源，在阿里云提前申請好資源，初始化環境并把VPC與自有機房的網絡打通，實現內網互通為數據同步做好準備；
• 第二步提前同步數據，使用Xtrabackup備份在線把MySQL配置成主從同步模式，將數據同步到阿里云ECS，在一段時間后完成數據遷移。
• 第三步正式遷移，正常的游戲停服維護時間（0.5~2小時）就可完成業務上阿里云的遷移。目前已經平滑完成3款游戲產品的遷移，每款產品準備時間3~5天，正式遷移用時1~2小時，在阿里云平臺使用的虛機超過1000臺。

圖三：新游戲上阿里云部署方案

上圖為ALLINONE架構遷移在阿里云后的游戲部署：游戲邏輯運行在ECS上，業務中使用VPC網絡，通過自建的ULB對外提供服務。游族網絡下一步計劃將集群模式部署在阿里云平臺上，游戲邏輯將在ECS集群運行，后端數據存儲在RDS集群中，前端通過SLB和負載均衡保證業務高可用，同時會接入LOG和大數據計算服務MaxComputer確保大數據業務。

在遷移到云的過程中，阿里云的技術支持起到了關鍵作用，線上線下及時溝通，以及特定技術的定制，保證了整個遷移過程的順利進行。

?如何去選擇合適的數據庫？

在游戲遷移過程中，遇到了很多困難，其中一點是選擇自建MySQL還是RDS。根據游戲遷移經驗，解決該問題，他認為應從以下三個因素進行考慮：

1. 實例數量：實例數量多且業務規模小（無需進行針對性的優化）適合自建MySQL服務；實例數量不多業務相對會比較集中，數據庫負載較高需要針對性的進行優化適合使用RDS服務；
2. 數據大小：數據量的大小會直接影響到數據庫性能和數據備份的機制，數據量越大越需要對數據庫進行精細化管理，數據的備份難度也越大，這種情況下建議使用RDS服務，反之可自建；
3. 成本核算：從實例規格來看RDS會比ECS自建MySQL要貴，但若是必須用到RDS的某些特性（如：數據安全和穩定性）時成本也就不會放在首要位置了。

與此同時，大數據量的自建MySQL可以采用延時同步的方法，此方法已在游族網絡的女神聯盟（手游）的集群架構方案中在使用。游族運維團隊獨創的數據備份系統、UJOBS、業務網關等獨具特色解決方案確保了其業務量在行業內處于領先地位。

————金三銀四課程特惠————

馬哥教育精英線下Linux班鄭州校區開班倒計時，優惠四重享，贈送高達4000元的學習大禮包：

第一重：4月30日前報名，立減400元，名額有限搶完為止；

第二重：4月30日前報名，贈送馬哥教育內部Linux知識精講教材一本（價值666元）；

第三重：4月30日前報名，贈送馬哥教育實體服務器使用資格（價值1666元）；

第四重：4月30日前報名，贈送馬哥教育云學堂學習權限1個（價值1999元）；