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

2020-06-01 00:00:00 镜像 部署 容器 进程 游戏

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


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


、游戏数目多,运维人员少


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


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


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


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


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


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


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


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


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


由于公网上的游戏容易被攻击,而且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地址也很重要。


第六、数据库的多份配备


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


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


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

相关文章