《王者榮耀》能夠成為如今國內最成功的手游，其后方成熟的技術團隊可以說是功不可沒。這個曾經在端游時代主導搭建RTS游戲《霸三國》框架的技術團隊，在轉型做MOBA手游《王者榮耀》后為游戲提供了巨大的支持。但這個過程也并非一帆風順。

在今年剛結束的騰訊TGDC上，《王者榮耀》技術總監孫勛在技術專場中，對這款游戲進行了一次技術復盤，為聽眾嘉賓就從技術層面上講解了游戲在引擎、整體網絡架構與網絡同步方案上的嘗試與轉變。

孫勛稱，目前游戲的服務器架構主要由“游戲大廳”和“PvP”2個部分組成，而在不斷探索中，其后來又在架構中加入了Proxy中轉服務器，也正是這個服務器的加入為《王者榮耀》解決了后來“安卓、iOS”同服等一系列出現的問題。

此外，他還介紹了《王者榮耀》在網絡協議以及同步方案上的一些嘗試，并一一復盤了這些嘗試的優劣勢，并解答了為什么，最終游戲會放棄TCP協議（傳輸控制協議）與曾經在《霸三國》中所使用的CLIENT-SERVER結構（C/S結構），并且轉而使用了UDP協議（用戶數據報協議）與幀同步同步方案。

以下為會議速記整理：

大家好，今天由我帶來《王者榮耀》后臺技術上面的分享。

我叫孫勛，是一名后臺開發程序員。2005年加入騰訊，最開始不是做游戲，2007年前一直做拍拍網，2007年加入成都臥龍工作室，也就是現在的天美L1工作室。之前參與過《QQ三國》、《封神記》、《霸三國OL》，到后來的《王者榮耀》，現在是這款游戲的技術總監。

今天分幾部分和大家介紹王者后臺開發過程中的一些內容和思考：包括《王者榮耀》整個背景介紹、后端架構、上線后的調整，以及網絡同步方案和反作弊方案等。

現在《王者榮耀》后端機器大概有4600多臺，我們的容量也有一定的擴展，進程數目是4萬多個。

《王者榮耀》游戲背景
?

2012年，我們當時做的端游《霸三國OL》，就是王者的前身。這款產品最開始是偏向RTS的游戲，后來我們把它改成了端游MOBA，再后來做成了手游MOBA，即現在的《王者榮耀》。從2012年開始做RTS游戲到2013年，從多控制單位的RTS游戲，變成MOBA游戲，到2014年啟動手游MOBA的預研，再到2015年2月份我們把大量人力（大概100多號人）投入做《英雄戰跡》（《王者榮耀》前身）開發，時間并不長。

《霸三國》的玩法是玩家可以在戰前通過排兵布陣構成自己局內的策略，通過控制多個單位，技能釋放、兵種特性的釋放形成對抗。我們最開始做《霸三國》的時候客戶端引擎是unreal，但在做《王者榮耀》的時候改用了unity引擎，3到4個月的研發時間內，產品本身從代碼層面沒有任何東西是從《霸三國》那里搬過來用的，全部代碼都需要重寫。

《霸三國OL》的一些啟示
?

做端游《霸三國OL》的這段經歷，給我們做王者帶來很多相應的啟示，比如策劃、程序及整個團隊對MOBA的理解。另外當時在做端游《霸三國》的時候，我們采用了CLIENT-SERVER的模式，但其實在過程中有借鑒類似幀同步的概念：例如在斷線重回對視野的處理這塊。

傳統的做法是，重回時會發當前的鏡像和后續的其他下行通知信息。這種做法會有一個問題，如果新增其他的場景內模塊的時候，根據場景內包含的當前的各種物件、所在狀態的各種各樣信息，都需要把這些東西打包發下去，在后續開發、維護的時候會顯得很麻煩。

我們的做法是，把服務器下發的所有序列包做緩存，并按順序重發，QQ買賣平臺讓客戶端做出快進的表現，它的概念和幀同步比較類似。還有一點，就是預留設計彈性，在最開始的RTS中，每個玩家最多可以操作5-8個單位進行對抗，到后來改成MOBA游戲，只能操作一個英雄，并且加入各種各樣的場景，我們本身的技術框架并不需要做出顛覆性的改動。

整體架構
?

《王者榮耀》目前后臺的整體架構設計是源自產品的需求。如果大家玩過《王者榮耀》就會知道，PvP對抗是不分區服的。微信1區的玩家可以和微信2區玩家一起對抗，甚至iOS平臺也可以和Android平臺的人一起玩，但同時一些共地方也保留了分區概念，比如戰隊、排行榜是基于“區”概念的。“區”在游戲里面就是編號，可以理解為打在玩家新建角色上的Logo。

我們最開始做架構實現的時候，服務器當時做得比較簡單，從原型開始只是保留了大廳和PvP服務器這兩塊，兩者是分開的。PvP服務器使用類似CGI調用，可以分配資源的使用，用完之后再回收，不負責其他的東西。需要的東西從大廳拿，用了之后回給大廳，讓大廳回寫DB。

我們在大廳和PvP之間做直聯，后來把直聯改成了中間轉發，在《王者榮耀》里面我們叫Proxy，相當于代理服務器，以屏蔽本身后端很多進程分布的細節。因為游戲本身的機器、進程很多，還有不同的路由規則。

某些排行榜或者戰隊是根據邏輯區的編號來確定哪臺機器，或者多臺機器進行處理的。有些消息采用隨機轉發或者多發廣播的方式，這些都是由Proxy負責路由。之后又加入了房間服務器，它負責的是《王者榮耀》內匹配、排位等相關功能，怎么樣把實力比較接近的人糅合到一塊兒玩，是由房間匹配服務器來做相應的負責的，因此會有戰隊和其他服務器戰隊匹配到一起。

最后我們在上面加入了一個Adapter，作用是用本身已經部署的大區資源實現跨服匹配的功能。游戲的后端架構，除了戰隊這樣的服務器之外，所有其他的模塊都可以在線擴容，或者在發現引起在線下降的故障時，從整個架構里自動屏蔽掉。因為路由方式會限定比如一區、二區、三區到這臺機器處理，如果故障，影響的只是某幾個邏輯區玩家請求的處理，降低故障影響范圍。

《王者榮耀》目前的機器數量，可能每周都會發現有機器壞掉，至少有一臺機器宕掉，在架構里面保證模塊自動屏蔽，和在線擴容，是非常重要的事情。整體結構比較像MMO的三層結構，MMO在騰訊有比較典型的三層級別結構。大廳服務器會根據玩家所在區，登錄具體區的大廳服務器。單個大廳進程可以承載2萬人，單個PvP可以承載1.2萬，小區登錄微信一區還是二區就是角色Logo，打在玩家身上。

《王者榮耀》現在外網有四個大區，比如Android手Q、Android微信、iOS手Q、iOS微信，此外還有搶先服。我們會用程序開關的方式，在大版本發布之前，優先更新搶先服，這時候它不能和正式服玩家匹配在一起，因為他們的版本不一致。當全服發布之后，它的版本更新一致之后，我們會打開開關，搶先服的玩家可以和正式服的玩家一起進行PvP的匹配。

除此之外，我們還有專門的體驗服，是給策劃驗證相關設計的，體驗服保留可能刪檔的操作，但在正式環境這是絕對不允許的。另外，以前的傳統手游偏單機，就會做很多協議兼容，客戶端版本沒有更新可以玩。但是《王者榮耀》里的主要玩法是PvP，同時結合實現方式，不同版本的玩家不能匹配一起，所以我們沒有做多版本協議兼容。

上線后的調整
?

上線后，《王者榮耀》本身的后臺架構，整體上沒有做太大的改動，因為我們做端游的時候，對這套結構比較清楚，我們知道哪個地方可能有什么樣的問題，所以整個結構一直比較穩定。

但是我們做了相應的微調，做得最多的是網絡本身的優化。《王者榮耀》上線的時候，市面上要求網絡及時性強的即時PvP游戲是比較少的。我們做了各種各樣的嘗試，比如在網絡做CPU方面的性能優化、延遲、丟包等等，網絡本身花的時間是最多的。

架構上的微調，像剛才提到的中轉模塊，我們架構中大廳機器很多，PvP機器很多，架構中不需要每個進程知道詳細信息，比如大廳服務器不需要知道后面有多少房間服務器，只需要知道后面有房間服務器，可以訪問就OK。

怎么劃分、平衡負載、怎么屏蔽后端故障節點，都是由Proxy路由功能在負責。因為大廳、PvP機器太多，我們通過Proxy將整個架構劃分成彼此之間沒有交集的“樹枝”概念，每組Proxy只負責一部分的大廳和PvP服務器。這兩種服務器在《王者榮耀》服務器里面最多，但是后端通聯之外，Proxy之間再建立連接，減少單個Proxy通道數的同時，保持整個結構的通聯。

ProxyAdapter是上線后加入的，最開始上線只有四個大區，手Q、微信、Android、iOS四個環境，最早Android的玩家也不能和iOS開黑。開始Android和iOS分開也有一定原因，我們之前設想Android會先更新，iOS后跟新，以保持版本更新的穩定性。但后來我們希望Android和iOS的玩家可以因為關系鏈一起開黑。

所以當Android、iOS版本更新頻率一致時，我們希望不需要部署太多額外的機器資源和開發，直接利用Android和iOS已有的PvP服務器和大區資源，打通Android和iOS的PvP。當Android玩家登錄Android大區會連接到Android大廳，iOS登錄之后連接iOS大區的大廳，當他們需要開黑的時候，我們通過Adapter把中轉模塊所有的大區橋接起來，通過一定的算法投遞到某個大區。投遞的選擇和大區資源占比有直接關系。

網絡同步方案
?

之前做《霸三國》的時候采用CLIENT-SERVER的模式，服務器判定客戶端表現，那為什么我們在做《王者榮耀》的時候選用幀同步的方式呢？

CLIENT-SERVER模式的好處在于：

首先，安全。因為都是服務器計算，客戶端只是負責表現層面的功能，不會影響各種判定的結果。

另外，CLIENT-SERVER模式因為是基于結果的表現，所以中間可以出現丟包，丟包是可以被接受和處理的，只要最終結果補發一致即可。

幀同步在端游用得比較多，大家比較熟悉的DotA，還有《星際爭霸》，都是用的幀同步技術。幀同步本身對網絡要求更加嚴苛，下發的執行序列是不允許丟包的，需要嚴格保證順序性，包是12345，就必須是12345，如果丟包，必須要等到丟的包到達之后才能順序后續執行。

MOBA本身的單位比較多，同屏時客戶端最多有將近100個單位，假如一個AOE技能打到20個單位，然后種了一個debuff，CLIENT-SERVER狀態模式需要發這些信息下去，可能潛在的同步狀態信息是比較多的。

另外一個CLIENT-SERVER模式本身開發的方式，客戶端表現與服務器的判定，要完美的匹配是比較困難的。

我們之前做端游MOBA的時候，一個英雄技能我們開發要兩三周的時間。《王者榮耀》當時開發周期是三、四個月，這樣的時間壓力下，我們用CLIENT-SERVER的方式搞不定，時間不夠。當時團隊心里會比較緊張，因為那時候市面上并沒有看到用這種方式做強PvP、高及時性手游的。

幀同步網絡抗抖動能力比較弱，因為不能丟包。幀同步的基本原理，大家有興趣可以下來自己了解一下。一般會有區分，是網絡還是主機模式。該技術的要點在于局內的運算都是基于客戶端運算，10個人中，每個人都會各自算一份，有相同的起始、相同的輸入、完全相同的中間運算邏輯，不存在隨機過程，這時候運算的結果，理論上應該是一致的。

甚至包括浮點數運算都不應該存在，它有精度的問題。包括很多碰撞，動畫，還有基本的數學運算庫都是后臺自己實現的，要去浮點整形化，避免客戶端的本地邏輯，這是最容易犯的錯誤，這是出現不同步最常見的原因。如果某個經驗不是很足的客戶端程序，寫程序時候用本地的代碼做相應的邏輯，可能跑得越來越遠，10個人都是平行的世界。

整體的網絡結構，大體看來分三層：服務器、客戶端邏輯層，客戶端表現層。

服務器主要負責的功能有兩部分：一是收集所有玩家上行的輸入，把它按定時的間隔打包成輸入的序列，投放給所有客戶端；二是當客戶端出現丟包的時候，服務器進行補發；還有把客戶端上行冗余的信息替換掉，比如有新的輸入到了，就把老的輸入Drop或者替換掉。在《王者榮耀》里，我們的邏輯是66毫秒一次，1秒同步15個包，這是不能少的，因為幀同步不能丟包，數據包必須有嚴格的執行序列。

客戶端邏輯層理解為客戶端本地的服務，就是所有客戶端運行的結果必須強一致，不能有真的隨機、不能有本地邏輯、不能有浮點數運算。拿到相同的輸入，產生結果必須一致。

客戶端表現層會根據邏輯層的數據去做Copy或者鏡像，然后在表現層進行平滑，幀數不一樣，但是不會影響最終的運算結果，只影響動畫和動作的表現。

PvP最開始上線時，我們用的是TCP技術。TCP在局域網的情況下表現還是不錯的，沒有什么問題，但是當外網出現丟包或者抖動的時候，受限于實現方式，比如窗口、慢啟動各方面的原因，會發現當出現重連的時候游戲非常卡，所以后來我們沒有用TCP，改為了采用UDP。如果出現丟包，服務器會在應用層做補發。UDP受限于MTU（最大傳輸單元）的大小，大于MTU，會出現分包，可能也會出現整包的丟失。

所以我們也會有些比較大的包會在App層由服務器做分包，中間出現丟包再由服務器補發，把零碎的包拼成整包再做解包。比較有價值的是UDP包，如果手機因為信號抖動等出現丟包，下發的時候通過冗余方式，是比較有效的解決方法。

幀同步的消息比較小，按照理論1秒15個驅動幀來算，20分鐘的錄像是10M左右。但是我們外網統計，正常的5V5對局20分鐘，錄像的大小大概是3M左右。服務器會把玩家的操作做純內存的存儲，當出現丟包的時候，服務器會通過編號快速找到緩存信息進行下發。同時根據丟包的情況，我們會計算給這個人發送冗余量的變化量。

最開始發送每個包會冗余前面3幀的信息，如果丟包嚴重，我們會嘗試冗余更多信息再下發。客戶端拿到之后會盡量壓縮邏輯執行的過程。幀同步有比較麻煩的模式在于，它不像CLIENT-SERVER的模式隨進隨出，崩潰之后重回必須從一開始運行，中間運算過程不能少掉。

當然，我們也嘗試過其他的一些方法。比如客戶端上行之后，不需要服務器定時的間隔去做收集然后下發，而是通過染色幀編號直接下發，這樣響應更及時，操作反饋更強、更快。當時我們做出來的結果是，這對手感的提升微乎其微，但是帶來的負面問題卻很大，因為不再是一秒15個包固定的下發，下發包的數量非常多，完全和這個人的操作習慣有關系，有可能一個人一秒之內產生了十幾二十個輸入，就需要把這些輸入打包之后對客戶端下發。客戶端因為收包很多,設備也會明顯發燙。

我們也有和其他部門合作，做類似于TCP的技術，大家直觀想到如果丟包就在io層做重發。但是實際的結果會發現，做的這個技術偏底層，所以對丟包的控制性不那么靈活，而且可能出來的結果還沒有tcp本身好。

傳統的幀同步的方式會做延遲投遞，這個我們也有嘗試過。如果間隔時間內出現丟包，或者出現包下行的時網絡波動，可以通過延遲投遞這種方式抹平抖動和丟包的情況。我們嘗試過這個方案但最終沒有這樣做的原因在于：《王者榮耀》里面一些英雄體驗起來感覺偏動作，對反應要求比較快，延遲投遞雖然抗抖動和抗丟包的能力確實不錯，但是手感上達不到我們的要求。

另外，做CLIENT-SERVER方式的實現，一般都會有一個套路，客戶端提前表現，根據服務器的表現做平滑或者拉扯。這個方案我們也嘗試過，但最終還是放棄了，因為這個技術會讓角色本身的表現有點發飄。客戶端本地動，馬上客戶端表現就跟著動，但根據服務器的下行，其實會做一些偏移或者修正。當網絡抖動出現的時候，角色會有一點發飄，所以這個方案我們放棄掉了。

幀同步方案，所有客戶端進行運算，期望產生一致的結果，但如果因為bug或者某個人使用修改器，跑出來的結果會和其他人不一樣，當不一樣出現，我們的說法是不同步了。我們會定時把一些關鍵信息提取出來做hash，不同步的人的hash和其他人會不一樣。《王者榮耀》不同步率上線時大概是2%，也就是100局可能有2局出現一個人或者多個人結果和其他人不一樣。我們現在把不同步率做到了萬分之三，一萬局里面只有三局出現這個情況。

這是怎么提升的呢？如果你用幀同步一定會遇到不同步的問題，客戶端寫錯了，用了本地邏輯，可能浮點數的運算誤差達到那樣的臨界點，它就會產生運算結果不一致。

我們的方法有很多：自動化測試，用機器人不斷跑，比如上新英雄之前，有腳本測試不斷跑，看會不會產生不同步的結果；有專門的體驗服、搶先服大區，發布到正式網絡之前先測試，先暴露問題，再解決問題；另外，當不同步的時候，我們會把這局整個錄像和客戶端間的log上傳和保存下來，這樣可以根據錄像和中間執行的日志序列快速的定位是哪個地方出現問題。

我們對延遲和單局質量也有相應的監控，這一局有沒有卡或者卡多少次，有沒有出現丟包，丟包多少，最大的延遲、最大的抖動是多少，我們都是有相應的記錄和統計。運營部的同學給我們提供了很多幫助，我們會有相關的網絡測速、問題分析的SDK的合入。

按照我們自己的統計，游戲卡頓主要的原因有幾個：一是小區的帶寬比較繁忙，很多小區其實都是公用帶寬出口，比如有人在下電影、看直播，占用了很高帶寬，你玩游戲就可能會卡。

二是Wi-Fi路由器延遲比較高，家里的Wi-Fi路由器長期沒有重啟，就會存在終端過多、信道干擾、其他大流量的應用下載情況，這也會影響你玩《王者榮耀》。還有手機信號差、信號抖動，Wi-Fi、4G空口丟包等。

我們其實在網絡優化上做了很多的嘗試，例如根據丟包情況加大冗余，然后優化我們各方面執行的效率，去減少CPU的占用。《王者榮耀》后臺方面，有兩個點是我們一直努力在做的，網絡優化和匹配機制，我們嘗試用各種各樣的方法，甚至后面也會嘗試用AI深度學習的方法，來更加精準的定位玩家本身的真實水平，讓他能夠匹配到更加真實的同等水平的對手和隊友。

總結

以上是生活随笔為你收集整理的《王者荣耀》游戏技术总监：技术架构与同步方案上做出改变？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。