Docker对游戏研发带来的好处

在泛娱乐时代，游戏行业特殊的业务特点为威廉希尔官方网站 团队提出了更高的要求，而Docker对游戏研发的运营环境带来了很多好处。发展至今，游戏研发的行业现状是怎么样的？Docker和架构改进之间如何应用？通过Docker构建起来的容器平台，能否提高资源利用率？如何镜像分发威廉希尔官方网站 标准化、统一化应用部署流程？
　　以下为正文：
　　行业现状
　　开发语言方面我主要想讲的是后端程序语言。中国游戏兴起大致于2002~ 03年，在那个时候开始做服务器游戏，即有网络的游戏，当时大部分使用C++。到后来一直到现在，开发语言有C++、Java、C#、Python、php，这些语言虽然都可以支持游戏后端，但应用场景不一样。
　　目前的互联网大型游戏，例如征途这类需要支持一两百万人同时在线的游戏，开发语言基本上都是C++，而页面游戏则偏向于更轻量级的服务器，一般仅需要支持一两千人同时在线，有不少人用Java与C#语言来开发。在国外，Python语言是用来做服务器架构的，但在国内它一般是被当成脚本做服务器。PHP语言是这两年手游兴起后，互联网游戏中使用得比较多，但大多数是通过http协议或邮件协议通信。从这些年游戏行业的发展来看，不能确定Go语言是否肯定可以替代Java，但很大概率会替代C++，这也可能是游戏后端未来发展的方向。
　　当前后端开发脚本语言主要有两种：Lua和JS。在大型游戏中，Lua语言用得多， 后来JS语言也逐渐变多。而NodeJS是一种后端服务器开发框架语言，但更适合做相对轻量级的游戏。
　　后端的开发编译环境越来越多，大约有一半是在Windows下开发的。然而百分之七八十开发后的后端程序运行环境都是在linux中，中青宝的后端程序就是这样。
　　
　　图1
　　如图1所示，这是一个传统的服务器，是网络游戏后端架构的服务器拓扑图。图上所示的是一个游戏区，一个游戏区是什么概念？它可能是由一组分步式的服务器组成，一组服务器可能包括：网关，DB，逻辑服等。一般情况下，网关是可分布的，即横向扩展，用来实现网络的负载均衡。以前开发征途游戏时，这样一个区的架构部署，一般需要用16台宿主主机来部署。这样一套区的架构可支持四万多人同时在线。06、07年时，机器配置比较低，对开发人员和运维人员的技能要求比较高，加上C++语言的特点、并发、锁同步、异常等问题很容易造成服务器宕机，所以之前架构及语言的威廉希尔官方网站 门槛是比较高的。但这在当年算作非常好的一套架构，这套架构的思想对于后来大型网络游戏的发展有很重要的意义，甚至影响了后来互联网的发展。例如腾讯做大型游戏时也借鉴了这套架构，通过和他们交流才知道这对他们的影响也是巨大的。
　　在开发版本控制上， 2006年之前基本上是使用CVS管理，2006年之后换成SVN，在2012年、2013年又换成了git。开发流程一般是程序加代码，放在服务器上，由QA进行服务器代码测试，测试完成之后再做Release版本。开发网和运营网是严格隔离的，中间会有一个跳转机（跳转机对安全性的要求非常高），再通过运维部署到生产机上，以前的开发流程上对人和每个环节的要求都很高，特别是对测试，QA出版本与运维。因为很多测试和运维并不是研发人员，但安装软件都需要正版，还需要安装各种插件，这对他们的要求变得很高，由于经常出现开发环境和生产环境的不同，而导致出现了莫名其妙的问题。开发人员在开发过程当中，不能直接上生产机（游戏行业是不允许开发人员上生产机改动数据的），所以查bug非常难，做到最后才发现很多bug是因为环境不一样导致的。一个开发人员不能上机器，还需要猜测bug出现在哪，这其实很艰辛。所以描述现状之后，需要考虑docker后带来的好处。
　　架构改进
　　
　　图2
　　如图2所示的架构，理念上的改进比实际的改进要更多一些，我从2002年开始关注docker和Go语言。因为对老游戏的架构非常了解，所以我在架构改进思路的基础上，想通过docker和云化，让运维和测试变得更方便、安全、简单。一个是docker化，另一个是云化，即网络部分能拿出来，放在云服务上，但真正能给游戏公司做云服务的门槛都会稍高一些。相对来说游戏公司的人才也不缺乏，所以他们自己能管理好自己的机器。
　　还有一个更重要的原因，当年的那一些服务器架构，不适合用云服务器来管理。如果运行一两千人的游戏无所谓，但如果是同时在线几万人的大区模式，这对机器的要求就会很高。当时的架构，很难适应现在的云服务公司所能提供的这些流程。所以我们都是朝这个方向来做改进的。一个是docker化，一个是云化的游戏架构。
　　我们以前是一个游戏和网关，它们之间是绑定的。如果一区需要三个网关，这三个网关只能给一区服务。因为里面有很多分不开的逻辑，但这会导致一个很大的问题：如果想跑到云服务器上，它们之间的逻辑交互性太强，操作会比较难，利用率也不高。例如一组会配六个物理机，它的峰值能达四万人，但是实际上峰值四万人是开始的几天，之后并没有那么大的量。甚至每个游戏的峰值，可能因为活动的不一样，一区是八点，二区是九点。其实，为了承受住峰值很多硬件是超配的。
　　我们认为首先能云化的是网关。新的改进思路，就是把跟网络相关的部分全部拿出来，它和游戏本身无关，只是替用户和游戏之间转发数据而已，并不需要跟某一个区域绑定。区和区之间可以同时共享网关，玩家和服务器之间、客户端程序和游戏服务器之间，都不再有网络这一部分。这样就有一个很大的优势：对于开发人员的知识范畴降低了。因为做网络游戏开发有很大一部分都是在处理网络，网络要高效。从流量安全等角度，这部分的复杂度是很高的。
　　从业务逻辑看，由于现在大部分都在用脚本做，所以门槛没有网络层高。把网关相关的提出来，在游戏开发的过程当中，对于个人的使用能力降低，对于程序员的门槛降低，安全性提高。网关相关工作可能需要最核心的人做，我认为这方面需要有一些保密的要求。更重要的是现在网络相关的部分，已经可以独立拿出来放在云服务公司。例如今天一区搞活动，可能有四万人的峰值，我们用的六台网关。明天二区搞活动，一区不搞活动，同样用这个网关，这大幅度的提高了硬件的利用率，这个就是我们现在的改进思路。