經(jīng)過近七年的高速發(fā)展，公司游戲服務器從100臺增長到10000+臺，游族整體游戲架構(gòu)也經(jīng)過了三個階段的演變：
　　公司早期廣泛使用的第一代架構(gòu)，當時主流的產(chǎn)品都是以DB+計算+前端這樣的3個角色開發(fā)設(shè)計并部署，服務器以物理機為主，一個游戲區(qū)組需要2~4臺服務器，不同的機器承擔不同的角色。這種架構(gòu)方案效率低，基本上不可能實現(xiàn)一天開100個區(qū)組（100個區(qū)組大概需要400臺服務器）； 隨著業(yè)務量的增長和虛擬化技術(shù)廣泛使用，游族整體游戲架構(gòu)更新為第二代架構(gòu)，全面采用虛擬化技術(shù)，把一臺高配的物理機器虛擬化成多臺符合游戲需求的虛擬機來使用，并實現(xiàn)了ALL IN ONE的系統(tǒng)架構(gòu)。該架構(gòu)方案運維效率高，適合規(guī)模開展游戲運營，但不具備業(yè)務高可用特性，一天開100個區(qū)組成為常態(tài)； 為了迎合大區(qū)大服、全球同服，游族融合了前兩代架構(gòu)的特點，推出了第三代架構(gòu)，按角色分拆并形成服務集群模式。集群架構(gòu)結(jié)合了物理機與虛擬化的優(yōu)勢，實現(xiàn)彈性擴容，游戲邏輯以服務進程或集群配置項的形式提供服務。該架構(gòu)方案運維效率更高，可實現(xiàn)秒級開服同時具備業(yè)務高可用特性。
　　基于第二代架構(gòu)，游族基于OpenStack自己的私有云，最初目標是為了提高服務器利用率、降低成本和實現(xiàn)分鐘級開服。運維團隊以O(shè)penStack G版為藍本進行調(diào)優(yōu)并修改；整個網(wǎng)絡(luò)采用的是VLAN模式，保證最大限度與現(xiàn)有網(wǎng)絡(luò)架構(gòu)保持兼容；存儲方面使用本地磁盤作為存儲。
　　通過底層優(yōu)化后，游族私有云基本上可以滿足業(yè)務的需求，目前90%游戲業(yè)務運行在上面，虛機規(guī)模持續(xù)保持在10000臺以上，游族私有云平臺沒有提供WEB管理界面，日常所有的操作都是通過命令行和腳本的形式進行操作，但對于虛擬機的增刪查改，重新封裝了一層簡潔的API接口實現(xiàn)與游族運維平臺的對接。經(jīng)過評估測驗，在高峰時期，整個私有云資源利用率可達到83%。
　　運維方式的轉(zhuǎn)變
　　與三代架構(gòu)相互對應是游族運維的三個階段：
　　在第一代架構(gòu)上，運維基本是手工運維，技術(shù)含量并不高，純粹是采用人與時間堆積進行，運維同學需要登錄每一臺服務器，順序執(zhí)行相關(guān)的命令和腳本。獨立的版控服務器，通過主動推送的形式進行版本更新；在第二代架構(gòu)上，通過自動化工具進行批量運維，團隊推出了使用expect寫的auto批量腳本，所有操作只需登錄一臺集控服務器執(zhí)行批量并發(fā)操作的腳本，獨立的版控服務器，通過并行的主動推送；在第三代架構(gòu)上，可以實現(xiàn)系統(tǒng)化運維，多個運維系統(tǒng)相互協(xié)調(diào)配合實現(xiàn)，例如：CMDB、業(yè)務樹、作業(yè)平臺等。游戲區(qū)組搭建的時間基本上可以忽略（可按需求實現(xiàn)按條件觸發(fā)或手動觸發(fā)搭建操作），所有的更新操作在WEB管理平臺就可完成。
　　游族作業(yè)平臺UJOBS
　　
　　圖二：UJOBS架構(gòu)及其游戲更新流程
　　系統(tǒng)化運維過程中使用的作業(yè)平臺（UJOBS）是屬于C/S的架構(gòu)，其核心部分由任務調(diào)度器和agent組成，通過調(diào)用API接口完成多種形式的指令下發(fā)。UJOBS簡單的來說是為服務器管理提供了執(zhí)行命令的通道，將所有的執(zhí)行命令和腳本在目標服務器橫向執(zhí)行完，把輸出結(jié)果記錄日志里面，同時可通過WEB界面實時查看分析。任務調(diào)度器是用來全局策略控制，進行并發(fā)量控制。任務列表里面保存任務的完整信息。指令倉庫保存常用的命令個腳本和上下文關(guān)聯(lián)的命令組合。
　　在UJOBS平臺上，游戲版本更新流程如下：
　　版本庫的版本變更自動觸發(fā)構(gòu)建； 從版本庫拉取變更后的版本文件； 通過構(gòu)建操作后，推送目標程序到分布式的全局版控服務器集群； 在作業(yè)平臺下發(fā)更新操作后，UJOBS的agent取得該次更新的版控服務器地址、變更清單以及版本信息； 從版控服務器拉取更新文件到本地執(zhí)行預定的更新腳本。
　　同時在UJOBS執(zhí)行的過程中可實時查看輸出的日志。當游戲版本更新出現(xiàn)異常，有兩種回滾方式：第一種，游戲服務器上保留歷史版本，異常時回退到歷史版本；第二種，覆蓋回滾，將老版本再次發(fā)布進行回滾。
　　數(shù)據(jù)庫備份與恢復
　　相對于游戲版本更新備份而言，數(shù)據(jù)庫備份更為重要。ALLINONE模式或者非集群模式的游戲業(yè)務場景下，會存在多達好幾千個MySQL實例，若是要按常規(guī)的MySQL備份方案來實施，管理難度和成本都要翻好倍。因此游族網(wǎng)絡(luò)采用Xtrabackup在主庫上直接備份數(shù)據(jù)文件方式，備份文件暫存本地；本地備份完成后在備份系統(tǒng)選舉一臺遠程服務器進行異地備份；備份策略每小時一次備份，半小時本地備份半小時遠程備份。該備份方法在單主庫業(yè)務場景下可能是最靠譜的數(shù)據(jù)備份方案，但備份過程對主庫會有影響、（限制IO操作），最壞情況下可能出現(xiàn)1小時的數(shù)據(jù)丟失（業(yè)務接受少量的數(shù)據(jù)丟失）。
　　在數(shù)據(jù)恢復方面，通過一鍵恢復工具，只需要提供恢復的IP、時間段和業(yè)務信息（如庫名）即可實現(xiàn)數(shù)據(jù)恢復；24小時內(nèi)的數(shù)據(jù)通過本地的數(shù)據(jù)恢復（結(jié)合二進制日志），超過24小時的數(shù)據(jù)通過異地數(shù)據(jù)恢復。
　　云上遷移歷程
　　現(xiàn)在游族已經(jīng)將幾款老游戲遷移到阿里云上。在將ALLINONE架構(gòu)平滑遷移到云上的過程中，首先要求就是遷移過程不能長時間停服，只能接受正常的版本更新的停服時間。整個遷移過程分為以下幾步：
　　第一步提前準備資源，在阿里云提前申請好資源，初始化環(huán)境并把VPC與自有機房的網(wǎng)絡(luò)打通，實現(xiàn)內(nèi)網(wǎng)互通為數(shù)據(jù)同步做好準備；第二步提前同步數(shù)據(jù)，使用Xtrabackup備份在線把MySQL配置成主從同步模式，將數(shù)據(jù)同步到阿里云ECS，在一段時間后完成數(shù)據(jù)遷移。第三步正式遷移，正常的游戲停服維護時間（0.5~2小時）就可完成業(yè)務上阿里云的遷移。目前已經(jīng)平滑完成3款游戲產(chǎn)品的遷移，每款產(chǎn)品準備時間3~5天，正式遷移用時1~2小時，在阿里云平臺使用的虛機超過1000臺。
　　
　　圖三：新游戲上阿里云部署方案
　　上圖為ALLINONE架構(gòu)遷移在阿里云后的游戲部署：游戲邏輯運行在ECS上，業(yè)務中使用VPC網(wǎng)絡(luò)，通過自建的ULB對外提供服務。游族網(wǎng)絡(luò)下一步計劃將集群模式部署在阿里云平臺上，游戲邏輯將在ECS集群運行，后端數(shù)據(jù)存儲在RDS集群中，前端通過SLB和負載均衡保證業(yè)務高可用，同時會接入LOG和大數(shù)據(jù)計算服務MaxComputer確保大數(shù)據(jù)業(yè)務。
　　在遷移到云的過程中，阿里云的技術(shù)支持起到了關(guān)鍵作用，線上線下及時溝通，以及特定技術(shù)的定制，保證了整個遷移過程的順利進行。
　　如何去選擇合適的數(shù)據(jù)庫？
　　在游戲遷移過程中，遇到了很多困難，其中一點是選擇自建MySQL還是RDS。根據(jù)游戲遷移經(jīng)驗，解決該問題，他認為應從以下三個因素進行考慮：
　　實例數(shù)量：實例數(shù)量多且業(yè)務規(guī)模小（無需進行針對性的優(yōu)化）適合自建MySQL服務；實例數(shù)量不多業(yè)務相對會比較集中，數(shù)據(jù)庫負載較高需要針對性的進行優(yōu)化適合使用RDS服務；數(shù)據(jù)大?。簲?shù)據(jù)量的大小會直接影響到數(shù)據(jù)庫性能和數(shù)據(jù)備份的機制，數(shù)據(jù)量越大越需要對數(shù)據(jù)庫進行精細化管理，數(shù)據(jù)的備份難度也越大，這種情況下建議使用RDS服務，反之可自建；成本核算：從實例規(guī)格來看RDS會比ECS自建MySQL要貴，但若是必須用到RDS的某些特性（如：數(shù)據(jù)安全和穩(wěn)定性）時成本也就不會放在首要位置了。
　　與此同時，大數(shù)據(jù)量的自建MySQL可以采用延時同步的方法，此方法已在游族網(wǎng)絡(luò)的女神聯(lián)盟（手游）的集群架構(gòu)方案中在使用。游族運維團隊獨創(chuàng)的數(shù)據(jù)備份系統(tǒng)、UJOBS、業(yè)務網(wǎng)關(guān)等獨具特色解決方案確保了其業(yè)務量在行業(yè)內(nèi)處于領(lǐng)先地位。
　　QA環(huán)節(jié)：
　　1、游族目前的運維人員數(shù)量是多少？
　　答：游族網(wǎng)絡(luò)最初運維團隊在二十人以上，經(jīng)過技術(shù)優(yōu)化后，目前團隊人數(shù)在十人左右。從原來的十幾款產(chǎn)品到現(xiàn)在的三十幾款產(chǎn)品，運維業(yè)務量增長一倍，整個運維團隊人員縮減一半。團隊不斷將技術(shù)轉(zhuǎn)化為生產(chǎn)力，這是一個持續(xù)推進的過程。
　　2、從運維小白到總監(jiān)的成長過程？
　　答：首先，我對運維這個行業(yè)保持很高的興趣。從游戲?qū)?zhàn)平臺接觸運維開始，就愿意持續(xù)花時間投入游戲運維，曾耗費兩天三夜的時間來處理運維中遇到的故障。當然最初也是從底層的運維人員做起，團隊管理是被逼出來的，是一個慢慢成長的過程。在團隊中，學習應居于首位，每個運維人員需要不斷地學習，提升自己的能力。
　　3、DB除了MySQL還有其他類型嗎？比如NoSQL這類數(shù)據(jù)庫是如何管理和部署的？
　　答：游族網(wǎng)絡(luò)的產(chǎn)品絕大多數(shù)都是使用的MySQL，有少數(shù)產(chǎn)品使用了Mongodb，因為量少暫時還是通過手工管理；緩存業(yè)務有使用Redis但不存儲關(guān)鍵數(shù)據(jù)，Redis的數(shù)據(jù)備份使用數(shù)據(jù)備份系統(tǒng)進行集中管理，所有的軟件部署都是通過標準化的業(yè)務模板進行管理的。
　　4、在新方案中，大數(shù)據(jù)計算服務MaxComputer的應用場景是什么？
　　答：在游族之前的架構(gòu)中，游戲日志是分開存儲，易丟失。在新的架構(gòu)中，通過Log服務將游戲日志搜集到大數(shù)據(jù)計算服務MaxComputer，對后續(xù)的游戲和運維數(shù)據(jù)分析提供便利支持。
　　5、數(shù)據(jù)庫的部分是單DB多實例嗎？有沒有啟用分布式DB的架構(gòu)呢？
　　答：ALLINONE架構(gòu)下，在一個MySQL實例中只運行一個業(yè)務；在集群架構(gòu)下，在單DB實例下，會運行多個業(yè)務，分布式DB架構(gòu)也相應是必備的。
　　6、游族私有云是用的OpenStack，本身組件很多，后續(xù)和公有云之間如何銜接的？
　　答：目前游族使用OpenStack僅限于機房，短時間內(nèi)不會與社區(qū)版本同步，機房內(nèi)修改和使用都很簡單，整個OpenStack定制和修改不多，更多著重于框架的使用。
　　7、國際節(jié)點和國內(nèi)節(jié)點的高可靠鏈路如何建立？
　　答：該鏈路使用的基本資源是遍布全球的阿里巴巴骨干網(wǎng)，阿里云是將自己的資源分享出來給使用VPC的客戶，實現(xiàn)國內(nèi)外高可靠鏈路的建立。
?