风靡全国，日活8000万，《王者荣耀》后台技术架构演进！

《王者荣耀》能够成为如今国内最成功的手游，其背后成熟的技术团队支持可以说是功不可没。

这个曾经在端游时代主导搭建 RTS 游戏《霸三国》框架的技术团队，在转型做 MOBA 手游《王者荣耀》后为游戏提供了巨大的支持，但这个过程也并非一帆风顺。

在今年刚结束的腾讯 TGDC 上，《王者荣耀》技术总监孙勋在技术专场中，对这款游戏进行了一次技术复盘，从技术层面上为听众嘉宾讲解了游戏在引擎、整体网络架构与网络同步方案上的尝试与转变。

孙勋称，目前游戏的服务器架构主要由“游戏大厅”和“PvP”2 个部分组成，而在不断探索中，后来又在架构中加入了 Proxy 中转服务器，也正是这个服务器的加入为《王者荣耀》解决了后来“安卓、iOS”同服等一系列出现的问题。

此外，他还介绍了《王者荣耀》在网络协议以及同步方案上的一些尝试，并一一复盘了这些尝试的优劣势。

为大家解答了为什么，最终游戏会放弃 TCP 协议(传输控制协议)与曾经在《霸三国》中所使用的 Client-Server 结构(C/S结构)，并且转而使用了 UDP 协议(用户数据报协议)与帧同步方案。

本文是腾讯王者荣耀项目技术总监孙勋带来的《王者荣耀技术架构》主题演讲内容整理。将分几部分为大家介绍王者后台开发过程中的一些内容和思考：包括《王者荣耀》整个背景介绍、后端架构、上线后的调整，以及网络同步方案和反作弊方案等。

现在《王者荣耀》后端机器大概有 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 的模式，但其实在过程中有借鉴类似帧同步的概念：例如在断线重回对视野的处理这块。

传统的做法是，重回时会发当前的镜像和后续的其他下行通知信息。

这种做法会有一个问题，如果新增其他的场景内模块的时候，根据场景内包含的当前的各种物件、所在状态的各种各样信息，都需要把这些东西打包发下去，在后续开发、维护的时候会显得很麻烦。

我们的做法是，把服务器下发的所有序列包做缓存，并按顺序重发，让客户端做出快进的表现，它的概念和帧同步比较类似。

还有一点，就是预留设计弹性，在最开始的 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 通道数的同时，保持整个结构的通联。

Proxy Adapter 是上线后加入的，最开始上线只有四个大区，手 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 深度学习的方法，来更加精准的定位玩家本身的真实水平，让他能够匹配到更加真实的同等水平的对手和队友。

孙勋