企业级别的服务，高可用本来就是很基本的要求，当然也包括更新时维持其可用性。消费者级别的服务比如游戏服务，一直以来采用停服更新无非是节约开发成本罢了，因为这个需求也不是特别重要，半夜停个服没什么大不了的。
对于王者荣耀这个游戏来说有个特点是state是很容易分割的，一场战斗就是个独立的state，而且持续时间不长，可以由独立的节点来处理。这样更新起来就简单了。
比如一个节点（比如一台服务器）正在处理1～N场战斗，因为战斗时长有限，完全可以先部署一个新版本节点，停止向旧节点派发新的战斗，然后等所有战斗在旧节点上处理完了再移出旧节点就行了，这个过程称为drain。当然这种方式需要临时增加capacity，并不经济。更有可能的做法是一个细粒度更小的节点只处理一场战斗（比如就是一个进程处理一场战斗），新的战斗用新版本来起节点就可以，那么从宏观来看旧版本节点会持续不断地消失，新版节点持续增加，最后经过最长战斗时长（几个小时？）后所有旧版节点就都没了。
用这种方式可以解决战斗处理这类的stateful服务。如果是stateless的服务（业务state都在外部存储）就更简单了。
当然如果王者荣耀一场战斗要打个好几天甚至一个月，估计在线更新的难度就完全不一样了。
比如像魔兽世界这种完全不间断的低延迟的互动响应模式，如果要做无缝不停服更新就很难了。比如说你放个火球术，在火球飞行过程中要把处理火球飞行轨迹的服务切换到另一台服务器还要用户察觉不到卡顿，这个才是非常难。
