游戏停服维护更新一直是在线游戏的难题，这个过程会面临维护当天日新增减少等问题。目前，网易游戏在《楚留香》等几款大型游戏中实现了不停服维护，节省了用户时间、大幅度提高了运维效率。

如何做到不停服维护？不停服维护在运维上会带来哪些改变和升级？作为 SRE 该如何应对？1月20日，网易游戏高级运维经理Richard在2019网易游戏开发者峰会上，为大家分享了网易游戏半年来的积累的一些经验。

以下是分享实录：

我在这里要和大家分享的是游戏不停服维护运维实践。游戏维护是我工作以来一直无法回避的一个话题，游戏会面临维护当天日新增减少，维护当天日流水减少的问题。

以前游戏项目人员会从两方面出发：第一，挑选维护的时间；第二，缩短维护时间。项目人员需要在很不清醒的时间内（如凌晨四点）快速地完成操作，故障率就很容易升高。

业界有两种较为通用的不间断维护方案，一种是灰度更新，另一种是红蓝更新。但为什么一直以来我们没有用这两种方案，一是因为服务端的开发进度，二是因为在运维上存在资源利用率不足，成本有限，集群又过大的问题。

经过思考，维护时其实用户在线总数是不变的，也就是虽然需要两套环境，但计算资源总量不变。用一套的资源实现两个服务端。我们先尝试了在一个服务器上进程多开的方案。不过，实施起来还是有问题，很难将各种计费、周边分布端口、网络开关服都结合起来，与实际的运维体系也不匹配。

对比研究后，我们想通过docker虚拟化资源，宿主超卖的形式实现资源环境的隔离，宿主配置两套 docker 实例，运行 AB 服新两套服务端，这时用户下线后从旧服登出，再登录时即进入新服务器，一套资源即可实现红蓝服更新。

在确立了方案之后就开始进行了一系列的调研工作。包括 Docker 的性能测试、兼容性测试、K8S 集群的部署以及内部专用的 Image 管理平台搭建。整个过程都比较顺利。

但随着部署服务器规模的增长，我们遇到了第二个问题：虚拟网络设备增加导致的，网络拥塞。

因为时间紧任务重，开始时想通过最短平快的方式实现虚拟网络间的互通，于是采用了一个最简单的网络方案“Host Network”将游戏服务器的虚拟IP也配置成实体IP，并注入到主路由中。但这使得主路由的设备条目数比设计容量多了三倍。硬件设备不足以支撑虚拟网络设备，是否有比较好的解决方案哪？我们又调研了docker环境下较常的Calico 网络方案。

这是简化之后的网络图。这其中有几个模块：在宿主上的BGPClient，Felix，在网络集群内又多了Route Reflector和ETCD， 分别负责宿主路由表的更新以及将虚拟机路由通过 Reflector 注入到主路由。这种方法可以使虚拟机通过主路由进行通信。

但通过仔细对比可以发现，其实 Calico 方案只是把 hostnetwork 方案配置自动化了。由于还是通过物理设备进行虚拟设备的管理和通信，所以整个网络依然受物理设备的限制影响；另外因为项目及设备数量的增加，内网IP也面临耗尽问题。所以必须有一套凌驾于物理网络的虚拟网络方案（Overlay），因此我们也对比了 docker 下另一个虚拟网络方案：Flannel。

Flannel 是一套覆盖网络 Overlay network，通过上图可以看出，主要的实现原理是将数据包通过隧道方式进行再封装，从而实现虚拟网络数据在物理网络上的通信。虚拟网络的信息主要通过 ETCD 进行查询与互通。总体来说 Flannel 可以解决虚拟设备占用物理网络设备数的问题，但依然无法满足大规模部署要求。

总结来说我们在搭建大规模 docker 虚拟网络的时候遇到了这些问题：网络没有隔离，网关性能不足，物理网络无法承载虚拟网络冲击，没有与宿主网络配置隔离。结合内部需求，总结了几点对网络的要求：

首先是不需要改造现有物理网络，其次是需要高性能网关，并且可以扩展。可以支持VPC，支持IP漂移，支持docker 与私有云网络混布。

为支持上述需求，我们基于openflow 协议开发了一套自研的SDN方案（Gon）。在宿主机上引入了 OVS（Open vSwitch） 用于管理宿主机内所有虚拟网络设备，OVS模块通过集群中NVC（Network Virtualization Controller）模块基于 openflow 协议实现互通。

我们同时引入了两个弹性虚拟网关设备 IGW 与 BGW，对内外网流量进行分离管理。整套 SDN 方案可以做到全局流控。根据网络组同事的测试，目前整套SDN单网关支持10G BPS，80W PPS、500W连接数，虚拟网关可依据需求在线弹性扩容，支持VPC，支持 IP 复用、支持 docker 虚拟网络与私有云的混布。

经过一些列研发与测试，Gon SDN方案可以 较好满足内部的网络要求，在并且在虚拟网络内部通信中，能做到接近物理网络性能。

解决网络问题之后，整体测试顺利，实现方式也相对优雅。不过如上面提到的，我们是需要对宿主机进行超卖的。这并不符合 Docker 一般的使用习惯。在容器编排上，需要有一定的特殊调整。要求对于一个业务群组（10001），需要严格按照一个pod A和一个pod B同时出现在一台计算节点。不然无法实现维护期间集群内计算资源的复用。

基于需求的特殊性，除了使用 docker 常用的 podAffinity 外，还需要结合 nodeSelector 特性来完成容器亲和性操作。

我们给需要复用的集群资源打上集群标签，然后通过NodeSelector的特性，进行实例编排，之后运用PodAntiAffinity的特性，保证不会出现AA 或 BB 分配到同一个宿主的情况。可以实现AB服的运行要求。但依旧有很多待优化的问题，包括资源层和应用层耦合，方案的通用性低。

经历了一系列之后，我们终于完成了不停服维护。以下就是完成的效果，在维护的同时，是不影响玩家的正常游戏的，使玩家体验上升，据我了解，整个产品团队的工作满意度也有了比较大的提升，大家都不需要熬夜维护了。

除了不停服维护，基于 docker 虚拟化环境的特性我们也取得了其他一些收获：包括从物理网络变成VPC隔离，新服准备耗时缩短，故障节点可自愈，系统环境升级做到不耗时，资源调度API化。

总结

与大家回顾一下不停服维护运维方案的实现，包括对资源的复用、docker 下 SDN 的探讨以及特殊情况下容器编排的尝试。其实整个方案基于 docker 实现，但不是常见的 CICD，能够根据需求想到用法这一块是最难得的，而后的技术问题反而比较好解决。

作为技术人员尽量不要被固有思维禁锢想象力，要知道技术能落地到业务才能产生价值。

运维的工作也已经不再是传统的劳动力密集行业，更多的工程化业务，驱使技术人员不断深入基础环境与业务内容。我们需要与各个部门的高度协作，结合各自专业一同完成共同目标。