游戲技術中臺調(diào)研
主要參考騰訊
從引擎中臺、devops、周邊、公共技術中心等方面
內(nèi)容參考tgdc
2020.06.27
-
騰訊游戲開發(fā)者大會（TGDC）2019
-
-
筆記-主要是引擎中臺
- 引擎技術移動化，我們在手游上大肆的使用端游時代的技術
- 引擎與工具也在不斷升級：UE4普及，Unity也升級到了2019，以Houdini與Substance為代表的美術工具被大家廣泛使用
- 硬件也在進步
- 此外，各種3A大作前沿技術被手游使用
- 技術深厚的公司出現(xiàn)了一大堆的高質(zhì)量的手游，技術競爭也會越來越激烈
- 傳統(tǒng)游戲開發(fā)團隊架構-在技術團隊中會有那么一小波同學會做一些引擎的開發(fā)工作，稱為“引擎工程師”，他們在負責一些面向于項目需求的特性的開發(fā)，性能優(yōu)化，解決一些技術的難題，去參與攻堅一些項目
- 引擎層、基礎引擎基礎（性能優(yōu)化、游戲框架、引擎基礎技術）
- 一般游戲產(chǎn)品都是需求驅動。往往團隊里面所使用的技術是為了滿足當前需求。團隊只關注單一產(chǎn)品，對一些前沿方向相關技術儲備不足
- 國內(nèi)做引擎或者做底層的開發(fā)者數(shù)量其實非常有限，需要去培養(yǎng)，而且要走引擎技術的全覆蓋
- 已經(jīng)沉淀出來的技術需要在各個項目里面不斷做傳承，已經(jīng)沉淀出來的技術需要在各個項目里面不斷做傳承。另外要對外不斷進行合作
- 引擎中臺
- 支持項目快速創(chuàng)新、規(guī)?；瘎?chuàng)新；提供完整的持續(xù)交付工具鏈
- 根據(jù)技術前瞻提前組織資源，利用技術先發(fā)和可復用的優(yōu)勢，賦能業(yè)務真正做到多（同一時間支持多個項目），快（持續(xù)快速交付），好（品質(zhì)保障），省（技術與人才充分復用）的逐個落地
- 中臺架構
- 業(yè)務團隊
- 流程支撐（目標管理、需求管理、代碼管理、開發(fā)流程 PM）
- 引擎技術組（引擎技術能力、開發(fā)制作管線、工作流工具建設、技術美術能力）
- 技術美術、引擎開發(fā)、工具鏈開發(fā)、自動測試開發(fā)
- 提供引擎技術能力，開發(fā)制作管線，工作流工具建設，技術美術能力等全方位能力去支撐業(yè)務，同時也會從業(yè)務發(fā)展過程中反哺中臺
- 和業(yè)務非常緊密結合是這個團隊最大的特別，我們不會一味做很多不落地的技術。我會根據(jù)工作室未來方向定義自己的Roadmap。我們70%的需求來源于業(yè)務，然后剩余30%來源于對業(yè)界趨勢的一些思考
- 同時中臺支撐需要有很好的流程支撐
- 引擎中臺技術全貌
- 項目前臺 穿越火線手游、使命召喚手游、UE4手游
- 開發(fā)框架（UE4/Unity開發(fā)框架）+ Lua插件（unrealLua）
- AI框架、角色控制、射擊手感、反外掛能力
- 任務系統(tǒng)、熱更新、打包版本方案、FPS游戲開發(fā)套件
- 管線/workflow
- 大世界制作管線、pbr畫面呈現(xiàn)標準/制作管線、fps動畫技術管線、workflow:程序化制作/資源管線
- 工具鏈/平臺
- DCC工具鏈、編輯器開發(fā)、自動化兼容性測試、技術沉淀wiki
- 引擎中臺
- 過程化制作（Houdini）、烘焙器擴展、可見性剔除方案
- 角色&頭發(fā)&皮膚、地形組件、prt技術
- 3D UI組件、高品質(zhì)天氣/晝夜技術、大世界/小世界渲染管線
- TA能力支撐
- 底層引擎
- UE4、Unity、自研引擎
- 建立畫面呈現(xiàn)標準
- 畫面品質(zhì)升級。要做畫面升級，首先是畫面呈現(xiàn)標準的建立
- 要考慮性能，做性能是永遠能服務于大盤用戶的
- 既然我們要做PBR，就需要統(tǒng)一制作管線和技術管線。對于制作管線來說，美術資源需要在線性空間計算。對于技術管線來說，我們要為引擎定義并且統(tǒng)一渲染管線，我們渲染管線是根據(jù)硬件scaleable的HDR渲染管線
- 有了渲染管線之后，對于畫面呈現(xiàn)來說，我們要建立一致的畫面標準
- 確定了shading model,materiel model, lighting model，畫面標準就基本建立
- 3A級手游制作管線
- 整個制作管線的核心因素有哪一些？我認為是有三個方面，一個是量產(chǎn)、一個是引擎、一個是性能
- 制作管線，需要使用流程與工具保證美術素材的正確和合理性。原則有兩個：一，美術素材輸入PBR標準；二，生產(chǎn)規(guī)格與生產(chǎn)環(huán)境
- 如何達到PBR資源的量產(chǎn)化？首先要可以驗證，其次要有詳盡、可追溯的文檔和記載，同時還要有科學性
- 量產(chǎn)我們要有標準的場景驗證
- 最后一個要點是正確性
- 《使命召喚手游》引擎技術沉淀
- 我們?nèi)粘５囊娴锩娑夹枰幸粋€自動化兼容性測試的框架，盡可能保證所交付的引擎是穩(wěn)定的
- 我們和騰訊Wetest質(zhì)量平臺合作，定義了一套devops自動測試框架，每日拉起TOP200的手機做測試。測試結果和基礎機器的backbuffer做對比，可以發(fā)現(xiàn)各種渲染異常。也可以驗證游戲graphic api的兼容情況。同時可以針對Top200機器做兼容性，性能測試，同時支撐新渲染特性以及渲染管線的評估
- 我們現(xiàn)在的第二個管線，大世界制作管線
- 基于Houdini的工作流
- 我們還對烘焙器做了很深度的定制，烘培器使用了GPU的烘焙
- 原來我們在PVP地圖里面單次烘培需要4-6個小時時間，使用這個烘培機。只需要3-5分鐘時間搞定了，整個效果也是有所提升，整個計算的正確性和參考也是非常科學
- 程序化生成LightProbe
- 程序化植被制作
- 我們提供了一系列Workflow保證美術制作、引擎、性能工具一體化
- 我們?nèi)粘５囊娴锩娑夹枰幸粋€自動化兼容性測試的框架，盡可能保證所交付的引擎是穩(wěn)定的
- Unity引擎特性升級
- 頭發(fā)：各向異性高光
- 皮膚：SSSS
- 角色：完整的3A PBR制作標準
- 總結：引擎技術中臺的能力
- 資源與經(jīng)驗復用
- 品質(zhì)與性能保障
- 工作流與制作管線
- 引擎技術能力
- 創(chuàng)新賦能
- 梯隊培養(yǎng)
-
-
-
筆記，關注最新動向（5g + 云游戲）
- 5G，高帶寬、低延遲、大連接
- 邊緣計算
- 關于云游戲
- 考慮當用戶對象是用5G來使用游戲的時候，怎么充分利用5G的網(wǎng)絡，才能讓你的用戶感受最好
- 邊緣云能夠更接近你最終的終端和最終的用戶
-
-
研發(fā)運營一體化，下一代企業(yè)級操作系統(tǒng)
-
筆記-藍鯨
- 我們團隊的職能是設計構建游戲“研發(fā)、運維、運營領域”的工具平臺，并經(jīng)營內(nèi)部的工具文化生態(tài)
- 研運中臺
- 基于PaaS的研運模式我們對外做過分享，在2016年之后對騰訊IEG投資的公司提供過私有化部署的版本，中小型公司提供易安裝維護的2012版，中大型公司提供2015版，這兩個版本在2017和2018年分別更名為“藍鯨社區(qū)版”及“藍鯨企業(yè)版”，前者免費提供給社區(qū)，后者由嚴格篩選的藍鯨服務商公司為甲方提供服務
- IaaS，PaaS，SaaS 的區(qū)別
-
-
-
騰訊游戲開發(fā)者大會（TGDC）2018
-
-
筆記-運營技術的加持
- 講到技術，大概會分成兩個方面：一是研發(fā)技術，在很早以前，大家覺得做好一款產(chǎn)品、做好一款游戲只需要研發(fā)技術強就行了。但是這遠遠不夠，如果你不知道你的用戶什么時候卡頓，是否下載成功，客戶端或是后臺程序crash了沒有及時發(fā)現(xiàn)和修復；如果你不知道用戶行為是怎樣的，不分析他購買的行為，不給他推薦他想要的東西，他要翻很多頁才能找到他想要的道具的話，估計他自己就放棄購買了；如果外掛橫行，你的游戲也會命不久矣。所以，還需要運營技術的加持
- 騰訊游戲在十幾年的發(fā)展中，在三個層面沉淀出技術能力：一是基礎的運營能力，比如說我們的藍鯨，在座的小伙伴可能聽到過、用到過，我們的安全包括內(nèi)部和外部的安全，傳統(tǒng)意義上的反外掛、內(nèi)部的反作弊，合起來才是安全的完整的解決方案；二是游戲開發(fā)過程中一些AI的幫助、公共組件，才會讓我們的研發(fā)速度和效率更快，以及WeTest開放的測試平臺；三是數(shù)據(jù)挖掘和數(shù)據(jù)應用能力，這些是騰訊經(jīng)過十幾年沉淀出來的能力
- 增值服務
- iData、DataMore、Pandore
- 心悅、小悅、游戲助手
- 研發(fā)技術
- 公共組件、游戲語言、AI
- WeTest
- 基礎運營
- 藍鯨智云、GEM
- TP、鐵算盤、反作弊
- 基礎設施
- 自建私有云、騰訊云、aws
- 增值服務
- 可參考騰訊游戲服務
-
-
-
筆記-UE4
- 上面的圖片其實不是她的寫真照，是通過UE4實時渲染出來的
- 虛擬數(shù)字人
- 我們可以借鑒電影行業(yè)的技術用到游戲開發(fā)，對我們有很多啟發(fā)性的應用。關鍵是這個經(jīng)驗是經(jīng)過很多皮克斯電影驗證的
-
-
-
筆記-UE4
從游戲線程、渲染線程、GPU、內(nèi)存等各方面進行優(yōu)化，從而提升游戲品質(zhì)
-
-
-
筆記-如何建設各項能力來支持游戲運營，提升游戲的營收、留存和用戶活躍指標，并提出了改變產(chǎn)業(yè)分工的美好愿景
- 《QQ飛車》的商城，我們看到這樣的商城，不管是道具的展示、交互的效果、支付購買，其實都是通過“潘多拉”完成的
- 《QQ飛車》做的視頻直播，這個視頻直播也是嵌入到游戲里的原生體驗，具備完善的開播、交互、彈幕功能，和虎牙、斗魚、熊貓的直播源都打通了。通過游戲內(nèi)嵌入的系統(tǒng)可以觀看到外部關于《QQ飛車》所有直播內(nèi)容，這樣一個方案可以在所有的游戲里進行上線、集成，開發(fā)商可以大大降低開發(fā)成本
- 《QQ飛車》做的好友和戰(zhàn)隊的匹配系統(tǒng)，可以幫玩家快速找到合適自己玩家，我們會分析玩家的地理信息、地理的聚群，讓玩家可以相互匹配在一起。這樣的一套社交系統(tǒng)在《王者榮耀》、《天天酷跑》都上線了
- 周邊系統(tǒng)可以單獨拿出來放在游戲建設中，可以重復應用到不同的游戲里，其實做這樣的系統(tǒng)可能并不是游戲核心樂趣所在，但又不可或缺，這些系統(tǒng)影響到玩家的留存、活躍等指標
-
-
-
騰訊游戲開發(fā)者大會（TGDC）2017
-
-
筆記-主要講述游戲基礎技術從端游到手游的發(fā)展和應用情況
- 其中我所在的團隊——負責游戲公共技術的研發(fā)。我們團隊成立之初到現(xiàn)在，一直在堅持的核心價值觀是希望加速整個工作室群研發(fā)游戲的效率，所有公共的模塊系統(tǒng)不需要重復開發(fā)，讓游戲開發(fā)團隊只需專注于核心玩法的開發(fā)上。此外騰訊游戲擁有海量的用戶，在設計公共技術時必須考慮高性能和高可用，基本上這三點是我們做設計的核心設計考慮因素
- 我們是2007年開始做公共技術
- 我們在《QQ幻想》的基礎上，前前后后花了3年時間，做出TSF4G（Tencent Software Framework for Game）的產(chǎn)品，它是一個比較完成的游戲后臺基礎開發(fā)框架
- 到2010年前后，那時候QQ空間很火，帶動基于SNS互動頁游的火爆，整個互娛很多團隊開始考慮怎么做頁游，我們的團隊也開始建設頁游基礎技術體系，其中最重要的產(chǎn)出是研發(fā)自己的分布式存儲系統(tǒng)tcaplus
- 自從《天天酷跑》發(fā)行非?；鸨螅屎芏鄨F隊迅速切入了移動游戲的研發(fā)，因此我們研發(fā)了手游基礎解決方案Apollo
- 近兩年很多手游項目開始考慮海外發(fā)行，我們團隊啟動公共技術云化和全球化支持體系的建設
- 我們的公共技術服務體系到現(xiàn)在積累了9年，基本上從前臺和后臺盡可能多的把可復用的功能提煉出來做成組件和服務
- 典型基礎技術演進之一：分布式開發(fā)框架
- 我們在TSF4G里研發(fā)基礎框架，當時來自端游的體驗，端游的整體架構基本上是分區(qū)分服，整個基礎架構是相對固定的，中間各種進程之間的協(xié)作也是偏固定的，所以形成了相對靜態(tài)的分布式系統(tǒng)。到頁游和手游時代，有更多的新創(chuàng)意進來，整體架構不是簡單分區(qū)分服的游戲。比如全區(qū)全服，全服分服等等各種豐富的玩法，整個后臺架構更動態(tài)：SNS互動玩法的引入，某些模塊性能壓力也有顯著的變化，很多邏輯系統(tǒng)是一個進程搞不定，需要對等的一組進程。另外用戶量的動態(tài)變化也需要很多進程去動態(tài)的去擴容；同時服務進程所在機器會出現(xiàn)故障，從服務訪問的角度看我們需要屏蔽這些機器故障，提升服務可用性。此外物理部署也帶來一些變化，現(xiàn)在全區(qū)分服的游戲，剛開服的時候人多，隨著運營節(jié)奏，慢慢單個服人變少，需要考慮合服的邏輯，以及怎么把物理資源利用起來，有些物理機器上運行幾個服。總體而言不管是邏輯上還是部署上都更偏動態(tài)，我們也希望將這些變化集中的基礎框架層面統(tǒng)一解決，從抽象層面看，每個對等邏輯的進程組可以看成一個服務，整個后臺系統(tǒng)是由一組不同邏輯功能的服務組成，類似業(yè)界的微服務編程模式。如果把動態(tài)的伸縮放到基礎框架設施里面，更像云化的服務。所以我們做框架提煉的時候，整個后臺的基礎架構應該是分布式云服務體系
- 我們思考新pebble框架的時候，首先要解決的是整個編程理念往服務的方式做思考，任何系統(tǒng)，比如幫派、家族都是服務，你不需要太關心到底由幾個實例組成。像服務的注冊、注銷和可用性探測，服務調(diào)度與負載均衡都希望在這個基礎框架層完成。因為服務能夠提供動態(tài)伸縮的能力，故障屏蔽的能力，服務通信也需要提供動態(tài)的通信能力。同時后臺邏輯系統(tǒng)通常比較復雜，考慮到性能，很多邏輯都是異步處理的，通常我們會設計一些異步編程框架來簡化這種復雜度?，F(xiàn)在我們發(fā)現(xiàn)游戲后臺開發(fā)節(jié)奏更快，希望進一步降低這些復雜性，比如沒有豐富后臺經(jīng)驗的同事不需要理解這個復雜異步編程，用人類更習慣的順序性編程思路，因此新的pebble框架引入了協(xié)程的支持
- 服務管理與調(diào)度、動態(tài)分布式通信系統(tǒng)、協(xié)程是新框架體系三個核心思考和實現(xiàn)的模塊
- 典型基礎技術演進之二：分布式存儲系統(tǒng)
- 最開始在TSF4G端游時我們做了Tormsvr的存儲組件ORM即參考業(yè)界對象關系映射理念。這個組件設計主要考慮到游戲數(shù)據(jù)有一個特點，游戲數(shù)據(jù)是變化的，隨著不斷的運營，存儲的數(shù)據(jù)結構不斷變化，系統(tǒng)存在不同時期的異構數(shù)據(jù)，數(shù)據(jù)存取時需要考慮這種異構數(shù)據(jù)的兼容，而這個處理是重復并且消耗開發(fā)時間的，在我們看來是占用工程師寶貴的研發(fā)時間。前面也提到我們公共技術研發(fā)的核心價值觀是讓游戲研發(fā)更簡單一點，因此我們希望把這塊數(shù)據(jù)處理做成組件，從數(shù)據(jù)存儲建表、改表等數(shù)據(jù)庫表維護到數(shù)據(jù)讀寫的SQL代碼處理，都在tormsvr組件層接管。程序員通過簡單的API即可完成數(shù)據(jù)存取
- 數(shù)據(jù)與SQL編程的映射用到另外一個數(shù)據(jù)表示TDR組件，類似google的PB，它的基本思想是把數(shù)據(jù)是什么描述出來，除了描述數(shù)據(jù)之外還要把它的操作語義也描述出來。有數(shù)據(jù)的描述和操作語義之后，我就可以寫出一些自動化數(shù)據(jù)處理的算法，比如我們把內(nèi)存的數(shù)據(jù)打印成各種格式，包括配置文件的讀取，策劃各種設定表格的讀取等等都可以實現(xiàn)通用化處理
- 到頁游和手游的時候，剛才的tormsvr方案碰到了一些挑戰(zhàn)。由于游戲互動性更強時對后臺數(shù)據(jù)存取壓力也會更大，比如我們會碰到有的游戲業(yè)務每秒對數(shù)據(jù)后臺的讀取超過100萬次。到目前為止我們新的存儲平臺，每天的數(shù)據(jù)讀寫次數(shù)超過了4000億次
- 其次因為移動游戲的用戶導入速度比以前更快，配合一些運營活動，可能一天就會有上千萬的用戶活躍，后臺系統(tǒng)容量規(guī)模更難預測，要求更快的伸縮能力來應變用戶的快速增長
- 第三個挑戰(zhàn)是早期手游研發(fā)開發(fā)節(jié)奏非常快，大家都在搶時間，早一兩個月發(fā)布就比別人先成功?？紤]到上面提到數(shù)據(jù)存儲的高性能要求以前程序員考慮做數(shù)據(jù)存取的時候，都會考慮數(shù)據(jù)緩存設計，考慮緩沖與數(shù)據(jù)持久化層的數(shù)據(jù)同步，這些代碼設計也是挺枯燥和重復的，我們希望讓游戲開發(fā)者盡可能少地關心這些東西，這些都放到存儲系統(tǒng)中去解決?；谶@一系列的考慮，我們自己開始了新的存儲系統(tǒng)設計
- 其中幾個設計思路是這樣的，我們希望優(yōu)先提供無損動態(tài)伸縮的能力，即存儲前端感知存儲系統(tǒng)擴縮容和節(jié)點故障，因此我們在存儲API層實現(xiàn)了節(jié)點動態(tài)探測和故障屏蔽。其次API層我們用負載一致性的Hash對接入層進行負載均衡，以盡量保證會話數(shù)據(jù)讀寫的一致性，即從客戶端角度看，同一個會話、數(shù)據(jù)讀寫順序性是有保障的
- 我們設計了一個接入層，主要考慮是希望屏蔽后面存儲節(jié)點的變化，由于數(shù)據(jù)的搬遷是有狀態(tài)的搬遷，通過接入層協(xié)調(diào)把這些數(shù)據(jù)的變化對外來看是透明的
- 存儲層的關鍵設計點，主要考慮是怎么樣使性能更高。我們把數(shù)據(jù)熱點管理考慮進來，相當于把原來在游戲邏輯層做的熱點cache管理移到這一層。同時我們采用了數(shù)據(jù)核心管理數(shù)據(jù)和業(yè)務數(shù)據(jù)分離，熱點多級淘汰隊列等多種設計來提升性能
- 典型基礎技術演進之三：下載式分發(fā)技術
- 下載分發(fā)粗看是很簡單的，從CDN里面拉回更新文件就完事了。但當把整個BG的游戲更新綜合起來時會發(fā)現(xiàn)有兩個核心訴求需要通過技術手段去不斷平衡：一個核心訴求是快速下載，玩家希望盡可能快的拿到新版本，最理想的情況是玩家不需要感覺有更新的過程；另外一個核心訴求是下載帶寬成本的控制，整個BG游戲的更新需要上T的帶寬。游戲更新的特點是下載帶寬和登錄是相關的，一般在線高峰，也是下載的高峰，發(fā)布版本初期帶寬通常又是平時的好幾倍，而帶寬是按照峰值付費的，從帶寬使用成本角度看按峰值付費不合算，為控制成本希望盡量把這個峰值降下來。這方面我們做了很多優(yōu)化嘗試，比如不斷優(yōu)化提高P2P下載的帶寬占比，包括研發(fā)預下載技術，還包括動態(tài)調(diào)節(jié)CDN下載帶寬等等。通過這些技術手段以優(yōu)化玩家的下載事件和CDN帶寬成本
- 為優(yōu)化玩家下載體驗，特別是優(yōu)化下載時間，我們也做了一些其他技術探索，首先探索的是微端IIPS技術，其核心設計是，對應每個版本更新，構建一個精簡版本，玩家下載這個精簡版本就可以開啟游戲體驗。我們把程序版本分成兩塊，比如基于剛進游戲會有10-15分鐘會玩到的場景和體驗，盡可能把這塊提煉出來做成微端的包，其他場景和體驗，在游戲過程中用到的時候在動態(tài)下載。當時典型案例是給軒轅傳奇做了300M的安裝包，通過下載這個精簡更新包絕大部分用戶的游戲體驗和下載上G的完整游戲安裝包體驗是沒有差異的
- 手游的微端技術：代碼通常沒有辦法切分，所以微端技術更多在資源上做切分，除了游戲開始體驗階段必須要下載一部分資源，其他都是動態(tài)下載，這就是手游微端的思路
- 至于手游代碼切分技術，我們研發(fā)的XLua組件提供了一種選擇。XLua組件本質(zhì)上是一種可以在Unity中動態(tài)執(zhí)行的lua游戲腳本的技術，如果邏輯用lua實現(xiàn)，可以將這些邏輯按照資源文件的方式進行更新，從而達到邏輯程序切分更新的效果
- 相對業(yè)界其他unity lua插件技術，我們的設計實現(xiàn)了幾個相對更優(yōu)的特性。首先是更完成的反射支持，能夠比較好的支持lua補丁技術，可以不在編譯階段生成代碼，節(jié)省構建時間。lua補丁優(yōu)勢在于移動程序構建的時候可以通過xlua工具打一些標記。當程序發(fā)布后，如果萬一有問題，我們只需將有問題的地方用XLua重寫發(fā)布即可。另外XLua在C#和lua層之間傳遞數(shù)據(jù)的時候做了特別的處理，可以盡量減少對對GC的調(diào)用
- 上面提到的都是通過優(yōu)化客戶端程序大小來優(yōu)化下載體驗的思路，業(yè)界還在探索的另一中思路是將整個客戶端云化，這就是所謂的云游戲技術
- 云游戲，它核心的想法是客戶端的計算都在服務器，這樣就可以實現(xiàn)即點即玩。此外還有很多其他優(yōu)勢，比如提升防外掛等安全保障能力，支持多終端等等。有很多公司和團隊在這一領域做了探索，包括我們的團隊
- 傳統(tǒng)云游戲方案采用視頻流方案，會在服務器端把每幀游戲圖像計算出來，傳遞到客戶端，客戶端就直接做展示，這很像看電影的方式。但這種方案最大的問題是成本非常高，服務器方面需要安裝GPU芯片卡，目前GPU芯片比CPU芯片貴很多。對視頻云游戲的成本，用一個不太準確的對比是：拿互娛能夠支撐傳統(tǒng)1萬人在線的服務器的相同成本，來購買支持視頻云游戲的服務器，可能只能支持到十來個玩家
- 我們團隊這兩年在云游戲技術上做的探索，主要集中在探索服務器成本更低并發(fā)更好的方案上。我們的想法是服務器不生成畫面，但是把生成畫面需要的指令和數(shù)據(jù)提煉出來，把數(shù)據(jù)發(fā)到客戶端，這樣可以把客戶端的計算能力利用起來。我們在端游和手游上，已經(jīng)把整個技術方案跑通了。最后的結論是，因為所有的計算都是用CPU完成的，基本上可以比傳統(tǒng)的視頻方案在并發(fā)能力上提高5-10倍。但整體對于傳統(tǒng)模式服務器上萬的并發(fā)量來說，整個云游戲技術的未來還要依賴將來硬件和帶寬的發(fā)展，還有很長的路要走
- 騰訊游戲服務
- 在這兩年有一個比較大的變化。因為很多游戲開始往海外走，所以我們要支持整個基礎技術架構在全球能夠部署運營起來
- 同時，近些年騰訊開放的策略，我們也希望積累這些基礎技術輸出給公司投資的游戲公司和合作伙伴，為游戲生態(tài)改善出一份力
- 我們基本思路是公共技術擁抱云計算，將技術向云上遷移，因此我們逐步建立游戲技術服務平臺Gcloud（gcloud.qq.com）,目前這個云服務平臺發(fā)布了Gvoice語音、存儲Tcaplus、下載和區(qū)服導航服務。同時我們也把pebble框架、Xlua在Github上做了開源
-
-
-
筆記-后臺整體架構、網(wǎng)絡同步技術
王者目前后臺的整體架構的設計是源自產(chǎn)品的需求，大家玩過王者的就知道，PVP的對抗是不分區(qū)服的，你登錄微信1區(qū)可以和微信2區(qū)一起PVP，甚至ios平臺可以和Android平臺的人一起玩PVP，但是同時又保留了分區(qū)的概念，比如戰(zhàn)隊、排行榜是基于區(qū)的概念，區(qū)在王者里面就是編號，是打在玩家新建角色上的Logo
我們最開始做架構實現(xiàn)的時候，服務器當時做得比較簡單，從原型開始只是保留了大廳和PVP服務器這兩塊，是分開的。PVP服務器的使用類似CGI調(diào)用，可以分配資源使用，用完之后回收，不負責其他的東西，需要的東西從大廳拿，用了之后回給大廳，讓大廳回寫DB
包括大廳和PVP之間做直聯(lián)，后來把直聯(lián)改成中間的轉發(fā)，在王者里面我們叫Proxy，相當于代理服務器，屏蔽本身后端很多進程分布的細節(jié)。因為王者本身的機器、進程很多，還有不同的路由規(guī)則，某些排行榜或者戰(zhàn)隊根據(jù)邏輯區(qū)的編號來確定有哪臺機器或者多臺機器進行處理，有些消息采用隨機轉發(fā)或者多發(fā)廣播，都是由Proxy負責路由
之后又加入了房間服務器，它負責的是王者里面匹配、排位相關的功能，怎么樣把實力比較接近的人糅合到一塊兒玩，是由房間匹配服務器來做相應的負責的。也會有戰(zhàn)隊和其他的服務器
最后我們在上面加入了一個Adapter，作用是用本身已經(jīng)部署的大區(qū)資源實現(xiàn)跨服匹配的功能。王者的后端架構，除了戰(zhàn)隊這樣的服務器之外，所有其他的模塊都可以在線擴容，或者在發(fā)現(xiàn)在線下降的故障時，從整個架構里自動屏蔽掉。因為路由方式會限定比如一區(qū)、二區(qū)、三區(qū)到這臺機器處理，如果故障，影響的只是某幾個邏輯區(qū)玩家請求的處理，降低故障影響范圍
王者目前的機器數(shù)量，可能每周都會發(fā)現(xiàn)有機器壞掉，至少有一臺機器宕掉，在架構里面保證模塊自動屏蔽，和在線擴容，是非常重要的事情。整體結構比較像MMO的三層結構，MMO在騰訊有比較典型的三層級別的結構。大廳服務器會根據(jù)玩家的所在區(qū)登錄具體區(qū)的大廳服務器。單個大廳進程可以承載2萬人，單個PVP可以承載1.2萬，小區(qū)登錄微信一區(qū)還是二區(qū)就是角色Logo打在他身上。王者就是全區(qū)全服的結構，如果剝離了戰(zhàn)隊，不管是大廳還是PVP服務器，其實每個都是按組的概念。我們可以在線擴容，如果組里面某個宕掉，不會有什么太大的影響。王者現(xiàn)在外網(wǎng)有四個大區(qū)，比如Android手Q、Android微信、iOS手Q、iOS微信，還有搶先服。我們會用程序開關的方式，在大版本發(fā)布之前，優(yōu)先更新?lián)屜确@時候它不能和正式服玩家匹配在一起，因為他們的版本不一致。當全服發(fā)布之后，它的版本更新一致之后，我們會打開開關，搶先服的玩家可以和正式服的玩家一起進行PVP的匹配。除此之外，我們還有專門的體驗服，是給策劃驗證相關設計的，體驗服保留可能刪檔的操作，但在正式環(huán)境這是絕對不允許的。另外，以前的傳統(tǒng)手游偏單機，就會做很多協(xié)議兼容，客戶端版本沒有更新可以玩。但是王者里的主要玩法是PVP，同時結合實現(xiàn)方式，不同版本的玩家不能匹配一起，所以我們沒有做多版本協(xié)議兼容
架構上的微調(diào)，像剛才提到的中轉模塊，我們架構中大廳機器很多，PVP機器很多，架構中不需要每個進程知道詳細信息，比如大廳服務器不需要知道后面有多少房間服務器，只需要知道后面有房間服務器，可以訪問就OK。怎么劃分、平衡負載、怎么屏蔽后端故障節(jié)點，都是由Proxy路由功能在負責。因為大廳、pvp機器太多，我們通過Proxy將整個架構劃分成彼此之間沒有交集的樹枝的概念，每組Proxy只負責一部分的大廳和PVP服務器
ProxyAdapter是上線后加入的，最開始上線只有四個大區(qū)，手Q、微信、Android、iOS四個環(huán)境，最開始Android的玩家不能和iOS開黑。開始Android和iOS分開也有一定原因，我們之前設想Android會先更新，iOS后跟新，以保持版本更新的穩(wěn)定性。但后來我們希望Android和iOS的玩家可以因為關系鏈一起開黑。所以當Android、iOS版本更新頻率一致時，我們希望不需要部署太多額外的機器資源和開發(fā)，直接利用Android和iOS已有的PVP服務器和大區(qū)資源，打通Android和iOS的pvp。當Android玩家登錄Android大區(qū)會連接到Android大廳，iOS登錄之后連接iOS大區(qū)的大廳，當他們需要開黑的時候，我們通過Adapter把中轉模塊所有的大區(qū)橋接起來，通過一定的算法投遞到某個大區(qū)，投遞的選擇和大區(qū)資源占比有直接關系
幀同步網(wǎng)絡抗抖動能力比較弱，因為不能丟包。該技術的要點在于局內(nèi)的運算都是基于客戶端運算，10個人每個人各自算一份，有相同的起始、相同的輸入、完全相同的中間運算邏輯，不存在隨機過程，這時候運算的結果，理論上應該是一致的。甚至包括浮點數(shù)運算都不應該存在，它有精度的問題。包括很多碰撞，動畫，還有基本的數(shù)學運算庫都是后臺自己實現(xiàn)的，要去浮點整形化，避免客戶端的本地邏輯，這是最容易犯的錯誤，這是出現(xiàn)不同步最常見的原因。如果某個經(jīng)驗不是很足的客戶端程序，寫程序時候用本地的代碼做相應的邏輯，可能跑得越來越遠，10個人都是平行的世界
-
整體的網(wǎng)絡結構，大體看來是分三層，服務器、客戶端邏輯層，客戶端表現(xiàn)層
- 服務器主要負責的功能有兩部分：一是收集所有玩家上行的輸入，把它按定時的間隔打包成輸入的序列，投放給所有客戶端；二是當客戶端出現(xiàn)丟包的時候，服務器進行補發(fā)；還有把客戶端上行冗余的信息替換掉，比如有新的輸入到了，就把老的輸入Drop或者替換掉。王者我們的邏輯是66毫秒一次，1秒同步15個包，這是不能少的，因為幀同步不能丟包，數(shù)據(jù)包必須有嚴格的執(zhí)行序列
- 客戶邏輯層理解為客戶端本地的服務，就是所有客戶端運行的結果必須強一致，不能有真的隨機，不能有本地邏輯，不能有浮點數(shù)的運算，拿到相同的輸入，產(chǎn)生結果必須一致
- 客戶端表現(xiàn)層是根據(jù)邏輯層的數(shù)據(jù)去做Copy或者鏡像，然后在表現(xiàn)層進行平滑，幀數(shù)不一樣，但是不會影響最終的運算結果，只影響動畫和動作的表現(xiàn)
幀同步的消息比較小，按照理論1秒15個驅動幀來算，20分鐘的錄像是10M左右。但是我們外網(wǎng)統(tǒng)計，正常的5V5對局20分鐘，錄像的大小大概是3M左右。服務器會把玩家的操作做純內(nèi)存的存儲，當出現(xiàn)丟包的時候，服務器會通過編號快速找到緩存信息進行下發(fā)。同時根據(jù)丟包的情況，我們會計算給這個人發(fā)送冗余量的變化量。最開始發(fā)送每個包會冗余前面3幀的信息，如果丟包嚴重，我們會嘗試冗余更多信息再下發(fā)?？蛻舳四玫街髸M量壓縮邏輯執(zhí)行的過程。幀同步有比較麻煩的模式在于，它不像CLIENT-SERVER的模式隨進隨出，崩潰之后重回必須從一開始運行，中間運算過程不能少掉
幀同步方案，所有客戶端進行運算，期望產(chǎn)生一致的結果，但如果因為bug或者某個人使用修改器，跑出來的結果會和其他人不一樣，當不一樣出現(xiàn)，我們的說法是不同步了。我們會定時把一些關鍵信息提取出來做hash，不同步的人的hash和其他人會不一樣。王者不同步率上線時大概是2%，也就是100局可能有2局出現(xiàn)一個人或者多個人結果和其他人不一樣。我們現(xiàn)在把不同步做到萬分之三，一萬局里面只有三局出現(xiàn)這個情況。是怎么提升的呢？如果你用幀同步一定會遇到不同步的問題，客戶端寫錯了，用了本地邏輯，可能浮點數(shù)的運算誤差達到那樣的臨界點，它就會產(chǎn)生運算結果不一致。我們的方法有很多：自動化測試，用機器人不斷跑，比如上新英雄之前，有腳本測試不斷跑，看會不會產(chǎn)生不同步的結果；有專門的體驗服、搶先服大區(qū)，發(fā)布到正式網(wǎng)絡之前先測試，先暴露問題，再解決問題；另外，當不同步的時候，我們會把這局整個錄像和客戶端間的log上傳和保存下來，這樣可以根據(jù)錄像和中間執(zhí)行的日志序列快速的定位是哪個地方出現(xiàn)問題
我們對延遲和單局質(zhì)量也有相應的監(jiān)控，這一局有沒有卡或者卡多少次，有沒有出現(xiàn)丟包，丟包多少，最大的延遲、最大的抖動是多少，我們都是有相應的記錄和統(tǒng)計。運營部的同學給我們提供了很多幫助，我們會有相關的網(wǎng)絡測速、問題分析的SDK的合入。按照我們自己的統(tǒng)計，主要的原因有幾個：一是小區(qū)的帶寬比較繁忙，很多小區(qū)其實都是公用帶寬出口，比如有人在下電影、看直播，占用了很高帶寬，你玩游戲就可能會卡。二是wifi路由器延遲比較高，家里的wifi路由器長期沒有重啟，就會存在終端過多、信道干擾、其他大流量的應用下載情況，這也會影響你玩王者。還有手機信號差、信號抖動，wifi、4G空口丟包等。我們其實在網(wǎng)絡優(yōu)化上做了很多的嘗試，例如根據(jù)丟包情況加大冗余，然后優(yōu)化我們各方面執(zhí)行的效率，去減少CPU的占用。王者后臺方面，有兩個點是我們一直努力在做的，網(wǎng)絡優(yōu)化和匹配機制，我們嘗試用各種各樣的方法，甚至后面也會嘗試用AI深度學習的方法，來更加精準的定位玩家本身的真實水平，讓他能夠匹配到更加真實的同等水平的對手和隊友
-
-
-
筆記-騰訊上線經(jīng)驗
- 騰訊對項目上線有一系列標準，在此簡要列舉幾點：1、架構設計要合理，支持彈性動態(tài)擴容能力，高可用容災能力。2、服務器性能要滿足要求。3、符合DB規(guī)范。4、符合運維規(guī)范
- 設計架構要求：1、彈性動態(tài)擴展能力，邏輯層要求支持線上動態(tài)擴容，并且要求對用戶無影響。2、高可用容災能力，核心模塊和關鍵路徑不允許有單點，不允許無法擴展。3、要求對同時大并發(fā)訪問有防雪崩機制，比如排隊、訪問頻率控制等，防止過載。4、要求非關鍵核心模塊故障不影響玩家主邏輯服務，可提供有損服務。5、不允許數(shù)據(jù)變更未及時入庫，導致可能發(fā)生10分鐘以上的回檔
- DB規(guī)范：1、按需Cache，存儲層實現(xiàn)分庫分表平行擴展或接入TSpider集群。2、使用域名+Port的配置方式訪問存儲層。3、存儲層訪問必須支持故障或者超時后的重連機制
- 運維規(guī)范：1、接入騰訊TGW。2、客戶端需采用域名+VIP的配置方式訪問服務端。3、日志文件支持按小時或大小滾動。4、程序用到的系統(tǒng)參數(shù)不能hardcode到代碼中，必須以配置項形式寫在配置文件中。5、應用程序必須支持通過工具實現(xiàn)動態(tài)加載相關的配置文件，而無需中斷服務。6、蘋果審核服和正式服的訪問切換必須通過服務端控制實現(xiàn)
- 單服架構、分區(qū)分服
- 單服內(nèi)模塊
- 多開負載均衡和容災
- 單機宕機拉起后恢復
- 單大區(qū)內(nèi)的模塊
- 分4個大區(qū)： ios-qq ios-wx android-qq android-wx
- 跨服匹配服務器 主備容災
- 全區(qū)全服模塊
- 單服內(nèi)容災、大區(qū)內(nèi)容災
- 單服內(nèi)模塊
- 體系結構
- 分層設計
- 網(wǎng)絡層提供通用的二進制傳輸
- 中間是框架層，提供RPC、Protocol、定時器、網(wǎng)絡連接封裝，RPC封裝，由工具生成RPC代碼
- 網(wǎng)絡層：1、跨平臺的網(wǎng)絡模型封裝，對外提供統(tǒng)一的抽象接口，內(nèi)部Windows下封裝IOCP，Linux下封裝Epoll。2、網(wǎng)絡IO在單獨的線程中執(zhí)行，不影響主線程邏輯，通過無鎖的環(huán)形隊列與邏輯線程交換數(shù)據(jù)。3、Windows下開發(fā)調(diào)試，Linux下部署運行，提高開發(fā)效率
- 框架層：1、主要提供基于時間輪的定時器；2、網(wǎng)絡連接的封裝，自動重連，心跳保活；3、日志支持；4、RPC，封裝通信請求、處理；5、協(xié)議的注冊、處理分發(fā)；6、Utility
- 應用層：1、場景管理，靜態(tài)場景+動態(tài)場景。龍之谷有一個主城，是靜態(tài)管理，副本是動態(tài)創(chuàng)建，根據(jù)負載均衡副到各個不同的服務器上。2、視野管理：主城9宮格+戰(zhàn)斗場景全同步+特殊場景分線。主城是九宮格視野管理，戰(zhàn)斗場景全同步，我們戰(zhàn)斗場景人數(shù)不多，全場景同步，特殊場景分線，公會大廳，公會中有很多人，這些人都是按照靜態(tài)分線機制，N個人之間可見。3、AI是基于行為樹實現(xiàn)的4、戰(zhàn)斗：服務器結算所有的邏輯，做狀態(tài)同步；5、協(xié)議：RPC用工具定義，自動生成代碼6、各邏輯系統(tǒng)
- 性能優(yōu)化
- 運用性能分析工具(Gprof, Perf)找出瓶頸模塊，熱點函數(shù)
- 對熱點模塊進行優(yōu)化
- 對熱點函數(shù)進行優(yōu)化
- 注意一些依賴庫的坑
- 統(tǒng)計服務器的各種壓力參數(shù)：流量，協(xié)議發(fā)送/處理頻率，定時器數(shù)量等，定期輸出到文件中
- 架構上支持進程多開，分攤壓力
- 性能優(yōu)化-壓測
- 前期刪檔測試期間記錄下高峰期服務器所有協(xié)議的處理次數(shù)，處理時間，得到重點協(xié)議的接收頻率，處理時間消耗等數(shù)據(jù)，有針對性的優(yōu)化
- 根據(jù)測試得出的協(xié)議接收頻率模型，騰訊壓測部門寫機器人工具，直接發(fā)協(xié)議到服務器，模擬真實玩家，對重點流程(登陸，切換場景，戰(zhàn)斗，大規(guī)模的活動等)進行壓力測試，測試響應速度，重點事務tps，找出瓶頸
- 使用機器人進行綜合測試，模擬大規(guī)模玩家的行為，不停上下線，不停切場景，打副本等，持續(xù)跑幾天，觀察CPU負載，內(nèi)存增長等指標
- 壓測下來，單服最高承載8000人，出于保守考慮，最高允許的同時在線人數(shù)設置為7000，到了7000就開始排隊
- 經(jīng)驗教訓
- 做好容災，服務器各進程要做到宕機拉起后可重新恢復服務，極端情況是可能出現(xiàn)的
- 服務器硬盤寫滿，所有進程一起崩潰，要防止重要數(shù)據(jù)丟檔
- 虛擬機母機硬件故障，整個機器掛掉，要防止重要數(shù)據(jù)丟檔
- 內(nèi)網(wǎng)波動，服務器之間的連接中斷一段時間后又恢復，要有自動重連機制
- 網(wǎng)絡波動導致服務器進程和 TSpider之間的連接斷開，要能夠處理這種情況，定時嘗試重連TSpider，未寫入成功的數(shù)據(jù)要緩存起來，待連接OK后繼續(xù)寫入，若重試達到一定次數(shù)，則禁止玩家登陸，等候運維介入
- 控制好內(nèi)存分配，多用內(nèi)存池，對象池，能事先分配好的事先分配好，各系統(tǒng)的內(nèi)存申請、釋放盡量統(tǒng)一控制，禁止隨意分配。內(nèi)存中的Cache要控制上限，避免無限膨脹
- 流量、協(xié)議發(fā)送/接收頻率，場景數(shù)量，各系統(tǒng)性能統(tǒng)計數(shù)據(jù)等定時記錄，以備查問題時用
- 關鍵流程和大規(guī)?；顒油娣?要有頻率控制，防止壓力不可控。我們做了很多全服玩法，中午12點30開世界Boss，打的人很多，晚上也有公會Boss，還有大規(guī)模的跨服活動玩法等，這類玩法的關鍵流程要有頻率控制，防止壓力不可控
- 重要數(shù)據(jù)實時落地，防止意外情況重要數(shù)據(jù)丟失，對于非重要的數(shù)據(jù)丟失給玩家補償也可以接受
- 重要流程（支付等）的日志要非常詳盡，有問題方便排查
- 數(shù)據(jù)庫表格要合理設計，重要數(shù)據(jù)單獨成列，避免更新時被其他數(shù)據(jù)影響。龍之谷的設計是每個系統(tǒng)的數(shù)據(jù)自成一列，做成Blob數(shù)據(jù)，如果某些重要的數(shù)據(jù)和其他非重要的數(shù)據(jù)放在一列存儲，非重要數(shù)據(jù)的更新如果有BUG，可能會影響重要數(shù)據(jù)，得不償失
- 測試用具要完善，單元測試，壓力測試，模擬客戶端，壓測機器人等
- 負載均衡要多考慮，避免各節(jié)點之間壓力不均，要均攤到整個集群。我們設計跨服路由集群的時候也考慮過負載均衡，但后來發(fā)現(xiàn)某些情況下，整個集群內(nèi)部的各個節(jié)點的壓力不均衡，有的節(jié)點壓力很大，有的很空閑，我們后來優(yōu)化了一下，最好在最初設計時多考慮權衡，做到把壓力均衡到整個集群
- 引入腳本，做到部分邏輯可熱更，或通過腳本修復某些錯誤。如果代碼全部是二進制，出現(xiàn)某些問題需要重啟服務器，有腳本會更加靈活一些
- 邏輯系統(tǒng)做功能開關，出問題后可動態(tài)關閉特定功能，防止問題蔓延。龍之谷所有系統(tǒng)都做了動態(tài)開關，根據(jù)系統(tǒng)ID可以關閉或打開一個系統(tǒng)，如果某個系統(tǒng)出現(xiàn)問題，就動態(tài)的關掉
- 重要數(shù)據(jù)異常，嚴重錯誤要監(jiān)控記錄。比如玩家數(shù)據(jù)膨脹，最開始創(chuàng)建角色的時候玩家數(shù)據(jù)很小，玩家玩的過程中不斷增大，每個系統(tǒng)數(shù)據(jù)的大小都會被監(jiān)控，發(fā)現(xiàn)異常就會警告，我們再去排查
- 所有大規(guī)模的全服，跨服玩法上線前都要做壓力測試，盡可能的模擬真實情況，避免上線才暴露問題
- 數(shù)據(jù)做集中式存儲，對后期合服會很友好。盡量把全區(qū)全服的數(shù)據(jù)存儲在一起，這樣后期合服就不需要合數(shù)據(jù)
- 對日志做關鍵字監(jiān)控，便于知曉問題的發(fā)生。通過腳本進行監(jiān)控，發(fā)現(xiàn)問題實時上報
-
-
