为什么说游戏更应该用容器!
当前微服务架构如火如荼,首先选择使用微服务架构并且使用容器的是电商,由于游戏的运营花的钱太多,游戏的运营不愿意冒任何风险,因而导致游戏的运维相对保守,处于观望态度。
其实游戏更应该使用容器,因为游戏的运维往往面临以下的问题。
、游戏数目多,运维人员少
很多非常火爆的游戏,你问他们每个月赚多少钱,发现赚的钱非常多,但是你问他们又几个运维,往往发现运维的人数非常的少。
游戏往往分工作室,一个大的游戏厂商往往有很多的工作室,但是运维则往往是统一由运维部进行运维的,当大量的游戏的上线发布压到运维的头上的时候,运维的压力非常的大。
第二、游戏周期长短不一,底层环境复杂多样
如果一个游戏厂商需要同时运营多款游戏,则不同的游戏由于周期不一,有的发行的早,有的发行的晚,底层的依赖的操作系统和依赖包多种多样,于是当游戏需要安装,扩容的时候,需要非常的消息,选择指定版本的操作系统和依赖包。
第三、同一台机器进程数目多,配置复杂
很多游戏的部署方式是同一台物理机上部署很多的进程,分接入,中心,场景,战斗服等,每种服的配置方式都不一样,并且不同的服之间相互关联,而且在同一台机器上,还会有大量的端口冲突的问题,需要小心配置。
第四、资源预估不准,临时扩容困难
一款游戏的火爆程度是难以准确预估的,比电商更难预估,因而如果遇到突然游戏非常火爆,采用物理机的方式,临时扩容比较困难,需要通过临时攒机器搞定。
第五、游戏容易被攻击,多采用多云部署
由于公网上的游戏容易被攻击,而且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地址也很重要。
第六、数据库的多份配备
首先数据库应该使用主从部署,并且定时进行增量备份和全量备份到对象存储,并且对象存储中的数据会定时备份到异地对象存储,从而实现异地灾备的功能。
每次升级,合服,开服之前,都要进行数据库备份,从而可以随时回滚。
听到这里,作为游戏运维的你,是不是要试一下容器呢?
相关文章