当前微服务架构如火如荼，首先选择使用微服务架构并且使用容器的是电商，由于游戏的运营花的钱太多，游戏的运营不愿意冒任何风险，因而导致游戏的运维相对保守，处于观望态度。
其实游戏更应该使用容器，因为游戏的运维往往面临以下的问题。
第一、游戏数目多，运维人员少
很多非常火爆的游戏，你问他们每个月赚多少钱，发现赚的钱非常多，但是你问他们又几个运维，往往发现运维的人数非常的少。
游戏往往分工作室，一个大的游戏厂商往往有很多的工作室，但是运维则往往是统一由运维部进行运维的，当大量的游戏的上线发布压到运维的头上的时候，运维的压力非常的大。
第二、游戏周期长短不一，底层环境复杂多样
如果一个游戏厂商需要同时运营多款游戏，则不同的游戏由于周期不一，有的发行的早，有的发行的晚，底层的依赖的操作系统和依赖包多种多样，于是当游戏需要安装，扩容的时候，需要非常的消息，选择指定版本的操作系统和依赖包。
第三、同一台机器进程数目多，配置复杂
很多游戏的部署方式是同一台物理机上部署很多的进程，分接入，中心，场景，战斗服等，每种服的配置方式都不一样，并且不同的服之间相互关联，而且在同一台机器上，还会有大量的端口冲突的问题，需要小心配置。
第四、资源预估不准，临时扩容困难
一款游戏的火爆程度是难以准确预估的，比电商更难预估，因而如果遇到突然游戏非常火爆，采用物理机的方式，临时扩容比较困难，需要通过临时攒机器搞定。
第五、游戏容易被攻击，多采用多云部署
由于公网上的游戏容易被攻击，而且DDoS攻击的门槛越来越低，因此虽然每个机房都部署的防DDoS攻击的设备，但是仍然可能被打满流量，因而很多情况下需要多个机房，甚至多云部署。
那面容器能够帮到游戏什么呢？
第一、基于容器的DevOps，减轻运维压力
DevOps流程没有容器也可以执行，但是基于容器镜像的好处在于，对于整个流程有了重新的梳理，交付物由原来的二进制包和文档，变为容器镜像，从而使得对于环境的配置提前到开发阶段，使得开发完毕的时候，就开始要考虑环境部署的问题，而不是完全交给运维来做。
这虽然看起来只耗费研发5%的工作量，但是却节约了运维大量的时间，因而研发多，运维少，每个工作室的研发考虑自己的游戏的环境，工作量不大，也不容易出错，一旦全部压到少数的运维头上，则工作量极大，还容易出错。
第二、容器可保持环境一致性
无论游戏依赖的是什么操作系统，什么包，都可以由研发人员放在容器镜像里面，这样对于运维来讲，可以统一使用最新的物理机的操作系统，包括打补丁，使用最先进的软件，使用最先进的设备等。
而容器内的操作系统和依赖包，老游戏可以使用老的，新游戏可以使用新的，不会产生冲突。
第三、容器简化多进程部署
在同一台物理机上使用容器部署多个进程，可以使得进程之间的环境隔离，每个进程可以使用独立的端口，独立的存储空间。
很多进程的配置可以打到容器镜像里面，进程之间的配置可通过容器编排搞定。
第四、基于容器易横向和纵向扩展
