2016年6月30日-7月1日，万众瞩目的GITC全球互联网技术大会将走进上海，在上海宝华万豪隆重举行。 GITC2016上海站将始终以汇聚行业精英、促进技术交流、加深商务合作、推动行业发展为大会宗旨，持续聚焦互联网领域的最新技术成果和未来发展趋势，就云、运维、大数据等技术热门话题进行主题、专题演讲，分享互联网的核心、尖端技术。 此次大会还特别增设了“互联网+”论坛、VR体验特展，技术&产品秀等一系列特色专场，给参会者带来更多直观的互动体验，打造更专业、有趣的技术交流分享及商务合作的平台。

我在两三周之前准备这个话题的时候想了很久，最后无意中看到PPT，发现有三个关键词跟演讲很贴近，第一叫分享，第二个叫简单，第三个叫快乐。今天首先是一个分享，希望能与大家共享；一会要分享的内容从思路从实现上来看，其实是非常简单的；然后这个过程当中，是痛并快乐着，所以“分享简单的快乐”很适合用来描述我们在游戏运维方面的自动化建设之路。

游族是2009年成立的一开始做网页游戏的游戏公司，比较幸运在2014年的6月份整整五年的时候完成了上市，是国内登陆A股，登陆主板的第一家游戏公司。游族目前发行的产品平均每年是30多款吧。我们在业务上来讲，会有几个特点，第一个是研运一体化；另外最早做页游，现在页游和手游都在做；以前是只做国内，现在国内和海外都在做，可能再过两三年，主要的业务会反而在国外了。

在一开始，既然要讲游族的运维肯定脱离不了业务，就是我们游戏是什么架构和特点。游戏的架构经历了一些过程，我们不说最早的端游，从页游开始，这也是游族比较熟悉的。从页游开始差不多2008年、2009年兴起到现在又逐渐的过渡到手游，我们自己总结是有三个阶段的，最早的第一个阶段其实很简单，就是物理机，那个时候通常一个区就是一组物理机，每一组里面可能有前端、有后端，有数据库，不同的服务又放在不同的机器上为了避免干扰，那么这样平均一个区需要几台服务器，少则两三台，多则四五台的样子，这样会带来一个问题，就是其实你在开服、配服的时候，你的成本会相当的高，而且对资源的耗用会很大。



总结就两点：第一个，配服的成本会比较高，周期会比较长，工作量会比较大；第二，就是资源浪费。当然这个架构显然是不算特别合理，所以以神仙道为典型，大家迅速进入了第二代架构，就是虚机的架构，这个时候虚机大量的被使用，游戏会改造成all in one的架构，一台机器上，同时把前后端的服务，包括存储，无论是数据库还是其他的存储都放在一起，这就是单区单服。



如果我想要去复制区服，相对来讲比较容易了，这个就解决了前一代的两个问题，第一个问题是资源的问题，因为我们也都知道，滚服前面的玩家会流失，消耗的资源非常小，就用虚机把资源给复用起来。另外all in one的架构，可复制性就会高很多，就可以适用快速开服的需求，所以在第二代架构和联运是相互促进，因为开服变得很容易，所以联运也会起来，联运起来反过来对第二代的架构又有了进一步的促进，这就是第二代。



再往后，有的游戏会进化到第三代。第二代模式仍然会有一个问题，就是对资源的利用率还是会有问题的，比如说我们一台物理机正常情况下开个16个虚机可能到头了，但是当你开到16个时候，你会发现CPU磁盘的使用仍然很低，这个资源还是有浪费。



所以会有一些游戏会发展集群式的架构，用集群来去实现前端的计算和后端的存储，可能会有配有全局的ID，然后用分表、分层来实现虚拟上的逻辑上的区。这个时候开区服就会变得很容易，往往就是配制一些表，或者一些配制项就搞定了。当然这个架构一开始会有一堆服务器，比如说基本架构可能要8台、10台甚至更多，但是在新开服的时候就不需要再增加机器，比如说现在线上正在跑的游戏，平均下来一台物理机可以开到100个区，100跟16相比就是好几倍的差异，这个成本差异就会非常的显著。



当然现在线上，第二代、第三代的架构都存在，第三代虽然有他的优势，但是也有他的问题，就是后端架构会相对来讲会比较复杂一些，在一些故障下，可恢复性要略差一点。对于游族来讲，这三代都会有一些比较典型的游戏，第一代最典型的就是十年一剑，第二代就是大皇帝、大将军，第三代就是女神联盟的手游以及女神联盟2的页游。

这是一个大背景，说完大背景以后，再说我们的系统运维做了什么事情。谈到游戏的运维，我们不能避开一个现实，很多公司不挣钱，即使未来会很挣钱的公司可能历史上也经历过非常窘迫的阶段，这种背景下，你上来就用特别豪华、特别奢侈的架构，往往都是不太现实的。游族最早2009年成立的时候做页游，当时用的就是双线机房。大家都知道会遇到一个障碍，就是南北互通的问题，这是极具中国特色的，在国外会遇到的比较少。



我们的做法是，我们只在一个地方布机房，那可能比如说电信，那么联通的访问怎么解决，以及那些小的运营商怎么解决，这时候我们自己做了一套优化，我们在全中国的主要几个地方设置了代理，当地的用户先访问我们的代理，然后通过反向代理转过去。如果你的机房是在电信的，就再通过电信的网络再转过去。最外的一层，我们可以用BGP，或者联通和电信的网络，然后我们转过来里面的这一层，我们用机房所对应的运营商的网络。这个会有优势也会有缺点，优势就是成本很低，如果你之前就有机房，你总不能把机房撤了，你可以把资源复用起来。



但是成本也是有的，就是因为多转一层，延时会增加10%到20%，但是如果业务上觉得10%到20%是可以的这个事情也可以干。这套技术的成本非常低，但是从业务上来讲，这个代价又可以接受。后来我们发现这个架构又有另外一个优势，就是在一些地区网络波动的时候又多了一个可调控的手段，我们可以把它这个地区的请求，再给调度到其他地区去，再给导入到我们的机房里，那这个也算是一个意外之得。当然访问速度，或者说效率会有一点降低，但是至少访问没有中断，这比访问中断要好太多了。

另外一件事情就是私有云，私有云现在很多的游戏公司都会去做，我们也不例外，我们是用openstack来做，基于openstack G版本做了一些改造。



这就是我说的第二代要做的事情，从这个第二代其实业务需求很简单，第一代你的物理服务器的资源耗用太高，第二个就是开服开的太慢了，这个背景之下，大家都是往虚机的方式去转。我们也是这样做，基于openstack的G版本，但是做了很多的调整和优化。你很多事情不是从零开始做，你要基于你现有的基础，基于你现有的机房，基于你现有的网络基础，基于你公司的实际的运营情况，而不是说你设置一个理想化的，从零开始把以前的东西全抛弃掉。



做私有云也同样如此，我不可以把原来的网络完全废弃掉，上来就构建一个全局的私有云，那是不可能的，所以我们做了VLAN跟我们现有的网络实现兼容。最终我们的现状是大概有超过一万台虚机。我们也有用一些共有云，主要是基于一些伸缩性的考虑，和业务合作的考虑，除此之外，几乎所有的游戏都是跑在私有云上的。另外，我们在openstack上还做了一些接口封装，封装成适合游戏来使用的API，然后跟我们自己的运维管理系统又做了对接。这是在系统层，跟网络层类似，其实都是脱离不了游戏发展的，或者说游戏架构发展的若干个阶段。

运维进化的过程，几乎是所有公司都会经历的过程，手工的，然后工具化，然后自动化，这个过程按理说都没有什么例外，但是不同的行业会展现出来不同的特点，最早在手工运维的时候，搭一个新区快的话要半个小时，慢的话是好几个小时，一天开几十个区，然后手工去操作，我们当时就是摊派，你今天要开五个区，另外一个人也要开五个区，十个人今天要开五十个区，谁把自己的区配完谁回家，那这种手工的模式导致很多人基本上天天都在加班。



公司业务发展的最好的时候就是运维是最惨的时候。所以这个背景下，我们很快进化到第二个阶段，就工具化的方式去做，最早我们是做expect脚本，你开一个服是一个小时或者是两个小时，你开一百个服也是同样的时间，就很快的进入到这个阶段，当然我们也发现了副作用，就是当你出错的时候，错的不是一个区服，而是一百个区服全都错了，不小心删了一个东西，所有的区全部挂掉了。这是自动化运维进化过程当中极大的副作用，工具变得更便利的同时，破坏力也在增加。

现在从工具又进化到系统，我们会把后端的脚本提炼、抽象，变成了所有的游戏都可用，一开始的话，不同的游戏会用不同的脚本，游戏的类型本身会有一些不同，不同的工作室后端架构也有一些不同。一开始要不同的游戏是用不同的脚本去做，后来慢慢发现可以统一到一起，再把这些脚本从操作端又给屏蔽掉，开发出可视化的界面去做控制，这就是作业平台，这个作业平台其实也经历过若干个阶段，集中式可配置，但是还会遇到一些演变，一开始可能只有一个机房，但会出现第二个机房和第三个机房，然后是异地机房，以及海外机房。这个时候你的对应的系统也要做对应的改造。



还有就是原来一款游戏或者是一个业务都在一个机房里面，但是会发现逐渐的出现一个业务会同时分布在若干个机房，这些对作业系统其实都是有一些改造的。海外还更特殊，海外的访问往往会有一些问题，你还要考虑到带宽的延迟，以及不稳定，就要考虑容错和重试等等，还要考虑一致性等问题。



但是不管怎样，我们都是朝着一个目标走，就是变成系统，变成可视化的系统，通过API的接口，去完成所有的操作，尽量的减少人为的操作，现在应该说没有意外的话，负责产品的运维工程师是接触不到任何的服务器和底层的脚本的。

最后我们讲一个例子，这个例子很小，但是我们自己觉得很体现整个发展过程中，结合了业务实际场景的考虑。你如果是做游戏的，你很多区服，你对这个问题还是有感触的，就是在第二代架构，一个区一个服，数据就是存在你所谓的这台机器上，备份也是在这里。



页游通常开个几千个区，上万个区也不是特别少见的，那什么时候备份，备份到那里，什么时候恢复，怎么恢复，实例能不能找到，备份是否成功，磁盘是不是爆了，爆了以后怎么办？等等的问题都会冒出来。还有公司肯定运营的游戏还不止一款，有特别老的第一代架构，还有第二代架构的，还有第三代架构的。还有就是存储方式。这些特点都会不一样，还有不同的版本，数据库的版本，redis的版本不同，可能在细节上也都会有不同。如果你哪点一不留神没注意到，都会出问题。



我们也是一开始，都在每一台机器上都布一个脚本去备份，后来发现磁盘会有满的问题，我们解决，发现这个机器会坏，坏了怎么办，我们考虑异机备份，异地备份。那么在这个背景之下，我们就想着把整个备份的过程从最早的手工变脚本，脚本变工具，工具变系统。

我们是先理了一下需求，第一个要备份的实例比较多，这里不是指数据量，通常单区单服数据量往往不一定大，但是类型会多样，一个游戏的类型会多样，要备份的存储的类型多样，同时还有一个需求，就是说要可靠，一定要可靠，这个过程一定要是可靠的，一定要自动去容错，磁盘满迁移，重试等等这些问题，所以我们也是一步一步的改进，现在到目前为止已经进化成一个系统。我们会首先在每一个机房会布一个节点，然后业务机和备份机之间，通过任务队列的方式通信，服务器负责把这些任务，把备份的任务下达下去，以及把备份好的实例传输过去。



整个过程是，按照你的需求，按小时，甚至是15分钟，去做备份命令的发起，去察看这个命令是否执行成功了，以及备份完的实例我是否给转移到了或者复制到了本地的其他的服务器上去。但是备份这个命令本身，这部分由你业务方自己去负责。同时我们又实现了一个前端，去察看昨天备份了多少，平均备份了多少，你的带宽使用是怎样的。



我们察看下来，可能每天都会有失败，因为多多少少会有一些网络的抖动，或者是一些磁盘的问题，当你服务器，或者是集群大到一定程度的时候，这种问题还是比较频繁的发生，那我就通过一个前端去检测问题，有一些任务是可重试的，由我这个系统自己重试解决，有一些是不可重试的，这个时候会把异常的发送到对应的团队，或者是数据库的团队，或者是游戏方的团队，由他们来去处理。我们现在在线上每天要差不多备份两万多个实例，有几十万个文件，从大小上来讲，大概有40多个T。另外就是我们同时还支持了回档的功能，如果说你想要把哪个区回档到什么时候，只要有对应的实例，那么我在前端去操作就可以了。

我们还做了一个开源，因为我们自己会觉得，这件事情可能对于行业里头，很多朋友还是有意义的，这个问题是很普遍的。所以我们就想说，把这个事情给共享给大家。当然这里面还有很多不完善的地方，因为有一些问题我们也没有完全遇到或者说处理过。这个二维码就是我们在github上的地址，这是我们前端的截图，这是前两天，一个星期之前，这是线上的涉及的业务，这个是你对游戏和一些区组的统计和分析，会有一些折线图或者等等来去察看他的分布情况，资源耗用的情况，以及是否有异常等等。我们相信这个系统其实还挺不完善的，但是我们是先做了一些改造，然后逐渐的也会跟行业内的朋友们多一些交流，先开放出来大家看这个系统能不能用，能用再怎么改。



整体来讲，运维这件事情，我们有一些小的总结，第一个叫做审时度势，就是你一定要基于你自己业务的实际情况去做那个阶段应该做的事情，你过早的做一些更宏大的事情，其实没有什么意义，比如说一开始就要想好我备份上万个区服，你做这个事情的意义就不是很大。



另外就是像我们刚才分享的经验，比如说最开始分享的关于网络的经验，是基于我们自己机房的特点去做的，所以什么阶段或者说跟你业务的实际特点会要相结合去做什么事情。另外一个就是复用，像我们的机房，我们的网络等等，我们其实在充分复用我们的资源，你可以把你自己的资源全部给替换成更好用的，更奢侈的，也可以替换成云，但是你自己原有的服务器，你自己原有的机房，你自己原有的网络，是否就这么废弃掉，如果不能废弃掉，你尽可能挖他的潜力，充分复用现有的资源。第三点就是尽可能的工具化。



刚才我也说到工具化有一个缺陷，就是在便捷的同时，他的破坏力也在增加，这是一个副作用，是双刃剑，但是这个路一定要去走。另外一个我们自己也会做很多运维的系统，一开始我们朝着集中化的方向去走，我们把所有的，无论是任务作业系统，所有的配置全部都集中在一个系统，我们认为这样模块和模块之间通讯和接口会变成系统内的调用，都会比较好用，但是实际上不是，系统后来慢慢变成了极其庞大的而又复杂，又无法维护的系统。



所以差不多从前年到去年开始，我们又改变了一个思路，我们是分散化，我们把我们的很多自动化的系统柴分开，作业系统是作业系统，任务树是任务树，CMDB是CMDB，备份是备份，都变成各自的相对来讲简单小而美的系统，相互之间是用API的方式来去做通信。这样也会有一些代价，在部分模块通信上会有一些代价，但是这个代价我们自己发现还是值得的。