大容量分布式游戲平臺架構及關鍵技術

炫彩互動網絡科技有限公司 陳 杰 付志鵬 楊維云 張 丹

中郵建技術有限公司 宋昌青

中國移動通信集團山西有限公司 郭 寶

中國移動通信集團公司 張 陽

大容量分布式游戲平臺架構及關鍵技術

炫彩互動網絡科技有限公司 陳 杰 付志鵬 楊維云 張 丹

結合游戲平臺業務特點，提出了大容量分布式游戲平臺架構。討論了平臺架構體系，平臺關鍵技術中的負載均衡和分布式架構。平臺已承載了手機游戲、電視游戲、游戲社區等多元化游戲產品，能快速響應不同運營商用戶的服務請求，實現了平臺架構設計的高性能、高可用、可伸縮、易擴展的目標。

平臺架構； 負載均衡； 分布式

0 引言

近年來，移動互聯網業務如游戲、視頻等訪問量劇增。傳統的集中式業務平臺多采用IOE（IBM、Oracle、易安信公司）架構[1]，即基于IBM小型機、Oracle數據庫與EMC存儲設備組合的架構，投資成本高且擴展性受限，難以支撐業務快速發展，已經被百度、阿里巴巴、騰訊（BAT）等互聯網公司逐步放棄。

為了解決業務平臺面臨的高并發訪問、海量數據處理、高可靠運行、業務隨需應變等一系列問題與挑戰，業界在實踐中應用了多種技術，包括分層架構、大規模集群、分布式緩存等。本文基于業界解決方案，結合游戲平臺業務特點，提出了大容量分布式游戲平臺架構，有效滿足移動互聯網應用億萬級規模的用戶并發訪問和大規模數據存儲等需求。

1 平臺設計要素

與傳統應用相比，大型移動互聯網平臺應用具有以下特點：

高并發：移動互聯網業務用戶增長快速，需要面對高并發用戶以及長時間的大流量訪問?！疤詫殹?014年“雙十一”活動全天成交金額571億元，其中移動端交易額243億元，物流訂單2.78億個。

高可用：系統7×24 h不間斷服務，服務的中斷會帶來嚴重的損失。2015年攜程網宕機12 h，造成了巨大的負面影響。

海量數據：業務數據增長快速，存儲、管理海量數據，需要使用大量服務器。Google有超百萬臺服務器為全球用戶提供服務。

用戶接入環境復雜：面向全球用戶提供服務，用戶網絡環境千差萬別，國內不同運營商網絡存在互通問題。

需求多變：移動互聯網產品用戶需求變化快速，多采用迭代開發的模式，快速發布新版本。微信朋友圈的研發過程為4個月，團隊完成了30多個版本的迭代。

上述需求使得平臺架構的設計需要關注性能、可用性、伸縮性和擴展性等關鍵要素，具體說明見表1。

表1 平臺設計關鍵要素

2 平臺架構體系

平臺采用分布式架構和層次化模塊設計，并根據移動互聯網業務需求，將公共核心業務能力（如計費）抽取出來，形成可共用的對內對外服務。系統主要核心模塊如圖1所示。接入層負責用戶客戶端的接入以及互聯網服務的分發，主要包括智能DNS（域名系統）、CDN（內容分發網）等服務模塊。業務層面向用戶提供門戶、計費、內容搜索等服務，包括業務應用層和業務接口層兩層；業務應用層包括用戶、計費等共用功能模塊；核心層包括核心接口層、核心層以及底層數據庫。其中核心接口層與業務接口層對接，供業務層調用。核心層對緩存及數據庫進行封裝和訪問，當數據在緩存中時直接對數據進行訪問，數據不存在緩存中時再訪問數據庫。

3 平臺關鍵技術

3.1 負載均衡

隨著手機游戲的快速發展和業務量的不斷提高，負載均衡是游戲平臺必不可少的基礎技術手段。負載均衡將負載分攤到不同的服務單元，不僅可以實現平臺的伸縮性，又保證了服務的可用性，還提升了響應速度，給用戶好的體驗。隨著硬件技術的迅猛發展，越來越多的負載均衡硬件設備涌現出來，如F5 Big-IP、Citrix NetScaler等，但其價格卻十分高昂，因此一些免費又可靠的負載均衡軟件方案是比較好的選擇。

游戲平臺首先利用DNS域名解析作為第一級負載均衡手段，采用智能DNS技術與多線接入的方式加速異網用戶的訪問。智能DNS帶有IP地址庫，可根據用戶的源IP（網際協議）識別和自動判斷用戶來源、所屬運營商，智能把用戶請求重定向到用戶所在運營商網絡部署的服務器，從而減少跨網流量，加快用戶的訪問速度，提升用戶的體驗。目前DNS解析服務提供商DNSPod提供免費的智能DNS服務。

平臺可以根據用戶訪問情況實現IP負載均衡。通過增加用戶接入點做到負載分流，避免單負載均衡器的性能瓶頸。如對于電信用戶比較多的游戲平臺，可以增加電信網絡下的服務器，通過各種負載均衡策略優化訪問體驗。一般常用的負載均衡算法包括輪詢算法、加權輪詢算法、隨機算法、最少連接算法、源地址哈希算法等。

游戲平臺選用免費開源軟件Haproxy[2]作為負載均衡的軟件解決方案。Haproxy是一種提供高可用、負載均衡、基于TCP（傳輸控制協議）和HTTP應用的代理技術。作為免費開源的解決方案，Haproxy特別適用于負載大、需要會話保持或七層處理的網站，支持虛擬主機，可以支持數以萬計的并發連接，并且可以簡單安全與當前的平臺架構進行整合，并實現Web服務器與外界隔離。在游戲平臺的實踐中，Haproxy對外提供HTTP代理服務，包括游戲大廳、用戶中心、計費、能力開放平臺、門戶等HTTP服務；對內主要用與TCP代理服務，用于代理核心、數據層服務，分別代理游戲核心業務、用戶核心業務、數據庫業務。

為了實現集群的高可用，還需要對節點進行檢測以避免單點故障，使得節點做到雙節點備份，故障無縫熱切換。游戲平臺采用開源軟件Keepalived[3]方案，Keepalived是一種高性能的服務器高可用或熱備解決方案。

3.2 分布式架構

游戲平臺采用分布式的架構設計模式，通過分布式緩存、分布式數據庫、分布式文件系統，實現平臺的高性能、高可用與高擴展性。

緩存是網站性能優化的第一解決方案，通過將數據存儲在訪問速度較高的存儲介質，能有效提升用戶訪問速度。分布式緩存將緩存部署在多個服務器組成的集群中，其架構主要有兩種，一種是以J Boss Cache[4]為代表的需要更新同步的分布式緩存，一種是以Memcached[5]為代表的不相互通信的分布式緩存。對于目前的游戲平臺，需要緩存的數據量一般比較大，采用需要同步的方案代價太大，一般采用Memcached方案。Memcached是一套高性能的、分布式的內存對象緩存系統，用于在動態應用中減少數據庫負載，提升訪問速度。通過在內存里維護一個統一的巨大的哈希表，Memcached能夠用來存儲各種格式的數據，包括圖像、視頻、文件以及數據庫檢索的結果等。

平臺的數據存儲需要結合游戲業務的特性進行設計。游戲業務，尤其是手游業務所產生的數據與其他業務存在較大差別。一方面，數據時效性突出，手游內容和用戶游玩生命周期都較短，因此必須對業務數據實時處理；另一方面，數據碎片化突出。非關系數據庫（NoSQL）基于非關系、分布式、可擴展的設計模式，適合上述復雜查詢場景。平臺采用MongoDB[6]來提升海量數據處理效率。MongoDB是非關系數據庫當中功能最豐富，最像關系數據庫的。其支持的數據結構非常松散，可以存儲比較復雜的數據類型。同時，對于用戶付費、購買和平臺/游戲收入等關鍵經營分析數據，依然保持結構化數據的特點，可以采用MySQL進行處理。

平臺采用NFS（網絡文件系統）作為分布式文件系統，提供底層的存儲。NFS允許一個系統在網絡上與他人共享目錄和文件。通過使用NFS，用戶和程序可以像訪問本地文件一樣訪問遠端系統上的文件。

4 結束語

本文介紹了大容量分布式游戲平臺架構，重點討論了負載均衡與分布式技術。愛游戲平臺是由炫彩互動網絡科技有限公司（中國電信游戲基地）全力打造的互動娛樂平臺，采用了上述架構與關鍵技術。平臺已經上線兩年，系統運行穩定。目前平臺承載了手機游戲、電視游戲、游戲社區等多元化游戲產品，平臺用戶超2億戶，其中月活躍用戶3 000萬戶，最高并發用戶數500萬戶，門戶訪問量十億次，實現了5個9的可用性。應用接口響應速度最高不超過500 ms，90%在100 ms以內；能快速響應不同運營商網絡用戶的服務請求，命中率達到99.99%。實現了平臺架構設計的高性能、高可用、可伸縮、易擴展的目標。

[1]金峰. 電信運營商“去IOE”的思考[J]. 通信世界, 2014,(3)：39.

[2]劉鍇. 利用HAProxy實現選課系統Web負載均衡[J]. 電腦知識與技術, 2011(7)：35-36.

[3]汪海洋, 凌永興, 包麗紅, 等. 基于Keepalived的高可用性應用研究[J].電子技術, 2014(7)：21-24.

[4]鄭雅萍, 張立東, 孫毅夫, 等. J BossCache緩存技術在集群系統中的應用[J]. 控制工程, 2008(S2)：155-157.

[5]陳康閑. 大型分布式網站架構設計與實踐[M]. 北京：電子工業出版社，2014: 60～70.

逍遙七絕陣自開創以來，生死二門，三重變化，至此才被諸圣淋漓盡致地演繹出來。東方宇軒看得心潮澎湃，感慨萬千，武學之道固然是罔有其極，神妙如斯，也算是有一點小成吧，不知道父親方乾，未婚妻方碧玲，他們看到會做何感想，他們會理解我此生的個中癡念嗎？

[6]霍多羅夫. MongoDB權威指南[M]. 北京：人民郵電出版社，2011: 1～3.

分時長期演進系統語音回落全流程時延優化

中郵建技術有限公司 宋昌青

中國移動通信集團山西有限公司 郭 寶

中國移動通信集團公司 張 陽

摘 要：針對CSFB（語音回落）業務流程分析影響通話接入時延的各種原因，給出全流程時延優化的總體解決方案。目前TD-LTE（分時長期演進）系統語音業務解決方案是CSFB與VoLTE（基于LTE的語音業務），由于語音回落過程中涉及尋呼、回落、TCH（業務信道）指配等過程，全流程時延比普通2G3G語音呼叫要長2～3 s。優化后效果明顯。

關鍵詞：語音回落； 尋呼策略； 指配

1 呼叫時延分析

TD-LTE（分時長期演進）系統語音回落（Circuit Service Fall Back，CSFB）業務過程包括4個步驟：LTE/GSM（全球移動通信系統）網絡聯合附著，通話建立過程回落到GSM，在GSM發起語音呼叫，結束后返回LTE網絡。通過全流程分析，CSFB呼叫時延縮短方法的研究主要涉及GSM核心網和無線網[1]。

以GSM普通呼叫時延為參照，對比CSFB呼叫全流程信令節點時延與GSM普通呼叫，通過量化統計，分析定位出CSFB呼叫較GSM普通呼叫存在3個時延增長點[2]。

1） 主叫鑒權：CSFB主叫收到immediate assignment至網絡下發鑒權請求階段；

2） 被叫尋呼響應：CSFB被叫paging response至網絡下發鑒權請求階段；

3） 被叫回落：CSFB被叫發送call confirmed至網絡下發assignment command階段。

2 CSFB主叫鑒權優化

CSFB主叫鑒權優化主要體現在呼叫鑒權組數量優化，分析發現，LTE網絡的鑒權四元組會使CSFB呼叫鑒權時長多于GSM普通呼叫[3]。由于GSM網絡鑒權僅需要鑒權三元組，故為進一步縮短CSFB呼叫時延，對GSM無線網絡進行挖掘研究，發現BSC（基站控制器）中存在參數MSCR〔MSC（移動交換中心）release〕可以優化網絡下發的鑒權組數量，從而縮短CSFB呼叫時延。

MSCR參數定義了MSC（網絡）支持的終端能力，其取值范圍為0和1，0表示MSC支持R98及之前的終端，1表示MSC支持R99及之后的終端。該參數在系統消息3中下發給手機，手機根據MSC支持的終端能力和自身終端能力取交集進行使用終端能力的上報。

根據3GPP（第3代伙伴計劃）規范，在UMTS（通用移動通信系統）中，若手機上報的終端能力是R98及之前的終端，系統將下發鑒權三元組，若手機上報的終端能力是R99及之后的終端，系統將下發鑒權四元組。因此，若將MSCR參數設置為0，則可以使R99及之后的終端上報使用R98及之前終端能力，如此就可以使網絡下發鑒權三元組，從而縮短CSFB鑒權時長，進而縮短CSFB呼叫時延。

經現場測試，參數修改達到預期效果。如表1所示，手機上報的使用終端能力由R99+變為GSM phase 2，鑒權要素由四元組變為三元組（即不帶AUTN參數），CSFB呼叫時延顯著縮短，而GSM網絡運行正常，BSC及其下小區各項關鍵性能指標保持平穩，各項基本業務功能均使用正常，無異常波動和異常問題出現。

表1 MSCR參數修改前后CSFB呼叫時延對比s

需關注的問題是：目前GSM網絡的異頻切換（900 MHz與1 800 MHz之間切換）會要求classmark3，而classmark3只有R99及之后終端才會上發，R98及之前手機只會上發classmark1或classmark2，所以在將MSCR參數修改為0時曾擔心可能會導致手機的異頻切換失敗。但是從現網修改試點看，無論是在MSCR參數修改前還是修改后，classmark change消息中都帶有classmark3上報支持頻段信息。這主要是由于MSCR參數的修改只是改變了手機上報的使用終端能力，而并不會改變手機本身的終端能力，所以無論MSCR參數設置為什么值，對于R99+手機classmark change消息中都會攜帶classmark3，所以異頻切換不會受到影響。

3 CSFB尋呼時長優化

3.1 CSFB尋呼間隔時長優化

試驗區域MSC發送CSFB尋呼的尋呼間隔時長等于MME（移動管理實體）上S1口尋呼間隔加1 s。經核查，試驗區域網絡S1口尋呼間隔為6 s，而MSC上CSFB兩次尋呼間隔時長為9 s。為縮短CSFB呼叫時延，對MSC-S（MSC服務器）上CSFB的尋呼間隔時長進行修改，由9 s修改為7 s。

CSFB尋呼間隔時長修改后，對于響應一次尋呼的被叫用戶，尋呼總時延沒有發生變化；但對于一次尋呼無響應而二次尋呼響應的被叫用戶，尋呼總時延減少了2 s?，F網MSC pool下每小時有大約1.66%～2.27%的二次尋呼響應CSFB被叫通話，其尋呼時長縮短了2 s，提升了用戶等待呼叫接續的感知，而MSC pool下CSFB一次尋呼成功率和CSFB尋呼成功率都保持平穩。

3.2 被叫選擇性鑒權縮短尋呼時長

試驗區域規定主叫每次鑒權，被叫選擇性鑒權，建議啟用選擇性鑒權縮短接續時延[4]。針對CSFB用戶回落2G時做被叫進行鑒權調整試驗，通過對被叫1/16鑒權和1/4鑒權參數調整，達到縮短CSFB時延的目的。

選取試點區域內兩個地點做定點測試，分別在功能開啟前、開啟1/4鑒權和開啟1/16鑒權時各進行20次CSFB呼叫。為排除其他因素對實驗效果的影響，只統計被叫RR（無線資源）paging response至RR assignment complete的時延，如表2所示。

表2 各種鑒權方式時延統計對比

從全鑒權、1/4鑒權和1/16鑒權三組定點測試的時延綜合分析，開啟被叫選擇性鑒權后，從RR paging response至RR assignment complete時延統計時延減少約500 ms，達到預期的目的。

小結：CSFB用戶回落2G時做被叫進行鑒權調整試驗，通過對被叫1/16鑒權和1/4鑒權參數調整，開啟被叫選擇性鑒權后，從RR paging response至RR assignment complete時延統計時延減少約500 ms，達到縮短CSFB業務時延、改善客戶感知的目的。建議針對CSFB被叫啟用選擇性鑒權縮短接續時延。

4 CSFB被叫回落TCH指配建立優化

4.1 精簡2G頻點保證CSFB精確回落

UE（用戶設備）能否回落至2G最強頻點是被叫回落成功的決定性因素，與2G優化人員建立良好的協作機制，第一時間刪除2G回落頻點中的超遠、故障、高擁塞等質差小區，同時推動2G側及時處理故障、擁塞小區。UE回落2G時會優先搜索RRC（無線資源控制） release中下發頻點組的頻點，當頻點組中頻點RxLev均低于某個門限時（各廠家的門限不同），才會搜索頻點組以外頻點。

如下因素會影響會導致回落質量：

· 由于未配置MTRF（恢復業務平均時間）跨pool回落必定失??；

· 是否回落到最強2G頻點；

· 4G測回落頻點組配置是否合理；

· UE選中回落頻點是否2G質差小區。

精簡2G頻點、精確回落優化措施如下：

1） 結合拓撲結構，參考2G同站鄰區，刪除冗余回落頻點。

目前MSC pool邊界外回落頻點數都在28個以上，刪除冗余2G頻點降低回落超遠質差2G小區概率。在優化4G小區回落頻點可按區域場景來規劃2G鄰區：密集城區只添加1.2 km以內2G鄰區，縣城、城郊添加2 km以內2G鄰區，縣郊、農村添加4～8 km以內2G鄰區；同時參考最近2G鄰區關系，對投訴處理、路測發現的一些重要重要鄰區進行補漏。

2） 重點處理CSFB業務次數較多區域2G小區擁塞，提升無線接通率。

如圖1所示，A點E-UTRAN（演進的通用陸地無線接入網）向GERAN（移動通信全球系統和增強型數據速率移動通信全球系統演進無線接入網）執行的CSFB重定向記錄點，聯合2G側對CSFB重定向到GSM區域高發區域2G質差小區進行集中處理，提升CSFB回落和接通概率。

3） 及時從頻點組中剔出2G質差、故障小區，提高回落質量。

不定期收集2G越區小區、擁塞常發小區，及時刪除2G問題小區周邊區域4G小區回落頻點組中的質差頻點（做好備份，2G側問題問題閉環后，及時補上已刪除頻點）；加大2G故障處理，4G側及時清除回落頻點組中配置2G故障小區。

4.2 TCH分配機制優化

針對CSFB被叫TCH（業務信道）分配時長偏長的問題，對TCH分配機制開展研究分析，發現試驗區域在核心網計數器timemgwdm（媒體網關選擇之前等待的時間）設置上與外省存在差異。試驗區域計數器timemgwdm是主叫端等待被叫端接入確認的時長為5 s，而取值范圍可以為1～14 s。

根據集團公司規定，當前核心網的呼叫接續流程采用前向延遲承載建立的方式。試驗區域核心網愛立信MSC在這種要求下，主被叫TCH資源采用串行分配的模式：即在被叫端完成尋呼響應、接入證實后，才通知主叫端分配TCH資源，而在主叫端完成TCH資源分配后，最后再通知被叫端分配TCH資源。在不違背前向延遲承載建立方式的前提下，通過縮短計數器timemgwdm使被叫端提前回復APM（應用傳送消息）消息，使得主叫端TCH資源分配流程與被叫端尋呼接入流程并行執行，從而優化呼叫時延。

現網CSFB呼叫從paging到call confirmed的平均時長為3.8 s，將timemgwdm的設置值由5 s設置修改為3 s，使現網主被叫TCH分配由串行分配變為并行分配。修改后，CSFB呼叫時延由修改前的10.4 s縮短到修改后的9.7 s，縮短了700 ms，優化效果明顯。

5 總結

通過開展CSFB呼叫時延縮短方法的專題研究，總結出了基于多網段（核心網、無線網）、多級網元設備（MSC、BSC、cell）的CSFB呼叫時延縮短優化建議，研究成果可以有效指導CSFB業務質量提升優化工作，達到預期效果。

參考文獻：

[1]徐德平, 耿魯靜. 淺析LTE系統CSFB話音解決方案[J]. 電信工程技術與標準化, 2013(1): 21-24.

[2]劉宇, 李赟, 聶永霞,等. LTE網絡部署CSFB話音時MSC改造范圍分析[J]. 廣東通信技術, 2012(12): .35-37.

[3]許鵬飛, 蔡玉坤, 曹云娣, 等. 淺談CSFB方案在LTE中的應用[J]. 科技創新與應用, 2014(12): 26-29.

[4]周彥, 武欣. TD-LTE CSFB話音解決方案研究[J]. 移動通信, 2011(19)：.22-24.