为什么说游戏更应该用容器！

当前微服务架构如火如荼，首先选择使用微服务架构并且使用容器的是电商，由于游戏的运营花的钱太多，游戏的运营不愿意冒任何风险，因而导致游戏的运维相对保守，处于观望态度。

其实游戏更应该使用容器，因为游戏的运维往往面临以下的问题。

第一、游戏数目多，运维人员少

很多非常火爆的游戏，你问他们每个月赚多少钱，发现赚的钱非常多，但是你问他们又几个运维，往往发现运维的人数非常的少。

游戏往往分工作室，一个大的游戏厂商往往有很多的工作室，但是运维则往往是统一由运维部进行运维的，当大量的游戏的上线发布压到运维的头上的时候，运维的压力非常的大。

第二、游戏周期长短不一，底层环境复杂多样

如果一个游戏厂商需要同时运营多款游戏，则不同的游戏由于周期不一，有的发行的早，有的发行的晚，底层的依赖的操作系统和依赖包多种多样，于是当游戏需要安装，扩容的时候，需要非常的消息，选择指定版本的操作系统和依赖包。

第三、同一台机器进程数目多，配置复杂

很多游戏的部署方式是同一台物理机上部署很多的进程，分接入，中心，场景，战斗服等，每种服的配置方式都不一样，并且不同的服之间相互关联，而且在同一台机器上，还会有大量的端口冲突的问题，需要小心配置。

第四、资源预估不准，临时扩容困难

一款游戏的火爆程度是难以准确预估的，比电商更难预估，因而如果遇到突然游戏非常火爆，采用物理机的方式，临时扩容比较困难，需要通过临时攒机器搞定。

第五、游戏容易被攻击，多采用多云部署

由于公网上的游戏容易被攻击，而且DDoS攻击的门槛越来越低，因此虽然每个机房都部署的防DDoS攻击的设备，但是仍然可能被打满流量，因而很多情况下需要多个机房，甚至多云部署。

那面容器能够帮到游戏什么呢？

第一、基于容器的DevOps，减轻运维压力

DevOps流程没有容器也可以执行，但是基于容器镜像的好处在于，对于整个流程有了重新的梳理，交付物由原来的二进制包和文档，变为容器镜像，从而使得对于环境的配置提前到开发阶段，使得开发完毕的时候，就开始要考虑环境部署的问题，而不是完全交给运维来做。

这虽然看起来只耗费研发5%的工作量，但是却节约了运维大量的时间，因而研发多，运维少，每个工作室的研发考虑自己的游戏的环境，工作量不大，也不容易出错，一旦全部压到少数的运维头上，则工作量极大，还容易出错。

第二、容器可保持环境一致性

无论游戏依赖的是什么操作系统，什么包，都可以由研发人员放在容器镜像里面，这样对于运维来讲，可以统一使用最新的物理机的操作系统，包括打补丁，使用最先进的软件，使用最先进的设备等。

而容器内的操作系统和依赖包，老游戏可以使用老的，新游戏可以使用新的，不会产生冲突。

第三、容器简化多进程部署

在同一台物理机上使用容器部署多个进程，可以使得进程之间的环境隔离，每个进程可以使用独立的端口，独立的存储空间。

很多进程的配置可以打到容器镜像里面，进程之间的配置可通过容器编排搞定。

第四、基于容器易横向和纵向扩展

当最初的预估资源不准确的时候，基于容器容易横向扩展，例如通过修改副本数，就可以快速扩展应用。

由于容器对于资源的限制是软限制，通过cgroup做的，因而纵向扩展也容易的多。

第五、基于容器易实现跨云迁移

多云部署是防止一个云被DDoS攻击的常用方案，然而实现跨云的迁移对于虚拟机和物理机是非常麻烦的事情。

没有一个公有云支持虚拟机镜像的下载和上传，哪怕是私有云，虚拟机镜像的下载和上传是非常的慢的，这就导致在一个云上好不容易搭建起来的环境，到另一个云上要重新搭建。

如果基于Ansible脚本搭建也是有问题的，每一种云的操作系统都有少许的不同，例如有的里面启动了DNS相关进程，有的关闭的某个端口，有的iptables设置了一些规则，有的路由表设计的比较复杂等等，同一个Ansible脚本在这个云上能够很好的工作，在另外一个云上就不行了。

如果基于容器，能够通过编排，实现环境的跨云迁移更加容易。

那么你应该怎么做呢？

第一、一切从Dockerfile开始

不需要对当前的开发和部署的流程做任何的改变，先写Dockerfile，并且在原来的持续集成流程里面，将打包后，加入一个编译Docker镜像的过程。

为了方便开发接受这些额外的工作，运维可以构建核心的基础镜像，然后开发可以基于基础镜像，非常方便的书写Dockerfile。

第二、仍然使用Ansible，变成启动容器

原来的环境部署都是使用Ansible，如果一下子改为Kubernetes，可以还不放心，没问题，还是用Ansible，只不过原来启动进程的地方，现在启动容器，原来用本机网络，现在还是用Host模式，一切和原来一样。唯一改变的是，DevOps的流程提前到了开发，并且可以屏蔽环境不一致性，减少了运维大量的工作量。

第三、非核心业务使用Kubernetes部署

整个运维团队需要开始熟悉Kubernetes的部署和运维方式，最好从非常像电商的非核心业务，如商城，网站，充值，直播等开始。

第四、如何保证基于Kubernetes部署的容器的性能

这个是运维最担心的，好在现在有了成熟的技术，例如裸机容器，使用CPU绑定的技术，可以实现无虚拟化损耗，因为CPU的性能决定了一个场景服上的最多的人数。

网络方面，裸机容器可以使用SR-IOV网卡，实现容器之间的横向流量接近物理网卡的水平。当然kube-proxy的服务发现则不好使了。

第五、有状态容器的IP保持，支撑核心业务的接入

实现可保持IP地址的有状态容器，使得游戏的核心业务，接入服，中心服，场景服都可以保持自己的IP地址。

接入服多使用有状态的socket连接，因而不能使用短连接的负载均衡器，只能绑定公网IP的有状态容器实现。

接入服，中心服，场景服之间的交互也是有状态的，需要知道当前的用户在那个场景下，而不能使用kube-proxy这种无状态的内部负载均衡，因而使用有状态容器保持私有IP地址也很重要。

第六、数据库的多份配备

首先数据库应该使用主从部署，并且定时进行增量备份和全量备份到对象存储，并且对象存储中的数据会定时备份到异地对象存储，从而实现异地灾备的功能。

每次升级，合服，开服之前，都要进行数据库备份，从而可以随时回滚。

听到这里，作为游戏运维的你，是不是要试一下容器呢？