王者荣耀不停服更新的技术方案是怎么样的？

ainatipen · 发表于 2021-8-8 18:19

pc8888888 · 发表于 2021-8-8 18:28

企业级别的服务，高可用本来就是很基本的要求，当然也包括更新时维持其可用性。消费者级别的服务比如游戏服务，一直以来采用停服更新无非是节约开发成本罢了，因为这个需求也不是特别重要，半夜停个服没什么大不了的。

对于王者荣耀这个游戏来说有个特点是state是很容易分割的，一场战斗就是个独立的state，而且持续时间不长，可以由独立的节点来处理。这样更新起来就简单了。

比如一个节点（比如一台服务器）正在处理1～N场战斗，因为战斗时长有限，完全可以先部署一个新版本节点，停止向旧节点派发新的战斗，然后等所有战斗在旧节点上处理完了再移出旧节点就行了，这个过程称为drain。当然这种方式需要临时增加capacity，并不经济。更有可能的做法是一个细粒度更小的节点只处理一场战斗（比如就是一个进程处理一场战斗），新的战斗用新版本来起节点就可以，那么从宏观来看旧版本节点会持续不断地消失，新版节点持续增加，最后经过最长战斗时长（几个小时？）后所有旧版节点就都没了。

用这种方式可以解决战斗处理这类的stateful服务。如果是stateless的服务（业务state都在外部存储）就更简单了。

当然如果王者荣耀一场战斗要打个好几天甚至一个月，估计在线更新的难度就完全不一样了。

比如像魔兽世界这种完全不间断的低延迟的互动响应模式，如果要做无缝不停服更新就很难了。比如说你放个火球术，在火球飞行过程中要把处理火球飞行轨迹的服务切换到另一台服务器还要用户察觉不到卡顿，这个才是非常难。

Baste · 发表于 2021-8-8 18:31

大多数时候会采用灰度服务器的做法。
啊你叫灰度也好，叫ab服，红蓝服也好，叫法很多种。核心思想是差不多的。

首先，现代大型手游的服务器都是分布式的……
王者农药的战斗部分可能是python啊，go啊，c++啊，js啊之类的写的一个长连接服务器。
然后他的其它部分，比如匹配可能就是通过一个web服务器来实现的。

然后，这还不是想怎么更就怎么更？
服务器的架构里面，可能有成千上万台战斗服务器在运作。
把其中一部分变成新版本。
一部分依旧是老版本。
非战斗部分也是一样处理。
只要新功能不涉及到数据库的大幅度变动，就没什么问题。

到点以后通过xlua在unity客户端做热更，通过不同的客户端版本号控制匹配队列，和前端连接的网关服务器来分配具体版本的游戏服务器。匹配队列和网关服务器等控制系统，会自动把不同版本的玩家分配到不同版本的战斗服务器当中。

接下来，运维只需要坐等更新前的客户端全部退出游戏以后，升级所有老版本服务器。
在腾讯有自家云的技术支持下，做到这点很简单。
甚至夸张一点还能做到你一边玩游戏一边更版本，等你下次loading以后，就变成新版本了……
然而这样复杂意义不大，我就是瞎鸡巴吧吹一下。

话说那些说服务器本身也是热更新的朋友，你们不嫌麻烦么……
而且根据腾讯的尿性，服务器是c++的可能性极大。
用c++做热更新然后我天天坐办公室里修bug大概是吃饱了，
还不如回家泡老婆。

redhat9i · 发表于 2021-8-8 18:35

没人邀，以下均为瞎猜内容。
如果是非战斗部分不停服更新很简单，替换二进制、重启服务就好了，状态数据应该持久化在内存里面（大概是走共享内存的方案）；
战斗部分大概是这样：
1、匹配服务器根据玩家版本号不同匹配到不同的池里面。
2、战斗服务器应该能支持不同版本战场逻辑的执行，因此不停机更新仅仅是增加了一份新版本的逻辑。考虑到数据持久化在内存中，理论上也可以不停机更新，但是估计风险比较大。比较合理的做法应该是先将部分战斗服务器从匹配池中移除，等待所有战斗结束后再进行更新，再放入匹配池。这样这部分战斗服就能支持新版本的特性了。

zt3ff3n · 发表于 2021-8-8 18:40

恐怕是老服务器不关，保证正在游戏的玩家不受影响，新登录的玩家走新的服务器，新老不会匹配上即可

JoshWindsor · 发表于 2021-8-8 18:46

本人虽说不怎么玩农药但是我玩deadgame 算个码农。deadgame更新也是热更新的而且是全球同步更新（虽然经常会在大版本更新之后服务器大姨妈）。

认真观察的玩家会知道deadgame的服务器除了拿来玩游戏的地区服务器之外还有一台用来管理玩家匹配的联络服务器至于这个服务器是一个国服共用一个还是全球共同一个就不知道了。

基本上思想是更新中不影响正在玩的服务器这局结束就进行版本切换约定好一个时间联络服务器就把匹配到的玩家分配到新版本的服务器中。

这时有人就会问如果这时没有足够的服务器版本切换完成供玩家使用怎么办.. 这大概就是deadgame时常因为更新服务器大姨妈的原因了吧... 毕竟我们一局平均40min

franciscochonge · 发表于 2021-8-8 18:47

红蓝切换
像这种先匹配再分配机器的游戏，前端一个coordinator负责为已经匹配好的游戏分配worker机器，更新的时候，调整分配策略，所有新建立的游戏都分配到已经更新好的worker机器上，旧的worker机器最终会空闲出来，然后patch,完了再丢到正常的worker pool里面。

登录这里，如果是要更新登网关服务器，那也是有loadbalance负责把所有新登录的用户分配到已经更新好的登录网关。所以整体应该是这样

Loadbalancer -> LoginGateway -> Coordinator -> GameWorker
Loadbalancer 可以根据策略为用户分配LoginGateway
LoginGateway可以根据策略为用户分配Coordinator
Coordinator可以根据策略为用过分配GameWorker

所以每一个业务模块都可以实现zero-down更新

我从不玩游戏，上面都是我瞎扯的：)

maltadirk · 发表于 2021-8-8 18:56

比如网易这样基于python、lua脚本语言的，热更新就直接reload function，做到只更新逻辑，玩家体验是会有顿卡，因为cpu在做热更新，占用高。

腾讯有做法是用共享内存的，所有逻辑和数据分离，加上网络连接的代理，更改逻辑之后可以restart服务，但是玩家感受不到。

我是做client端的，server端了解得不细，不过看很多回答都不靠谱…只好装x强答一发。

Arzie100 · 发表于 2021-8-8 19:03

两个层面：
1. 脚本与配置文件的reload。没啥技术含量。

2. 逻辑服务器内的所有对象通过共享内存中的内存池分配和管理。逻辑服务器与gate通过大容量的ipc交换数据，gate处理网络连接。更新服务器时，只重启逻辑服务器，这过程中共享内存中的内容会被保留。只要逻辑服务器的的对象内存结构不变，拉起来就可以继续跑。网络连接不会断，客户端可能只是卡了一下而已。当然，这中间有非常多的实现细节。

KaaPexei · 发表于 2021-8-8 19:07

都在扯架构，真正的问题是数据库啊

		自动登录	找回密码
密码			立即注册