中国IDC圈11月13日报道，昨日，2013中国云计算用户大会在北京国家会议中心盛大开幕。本次大会以用户大会及高端沙龙为主体，围绕可信云服务标准、公共云服务发展、企业私有云PAAS平台建设实践等议题，通过主题演讲、技术演示等形式进行。大会积极推动了针对云计算产业战略、政策、规划、标准、监管和法律法规等方向的研究工作，促进政府主管部门与产业界的沟通与交流。光宇游戏CTO、技术副总裁沈崴先生出席大会并跟大家分享游戏云运营现状。

光宇游戏CTO、技术副总裁沈崴

以下为沈崴演讲实录：

沈崴：尊敬的各位嘉宾、委员、来自互联网业界的朋友。大家上午好！非常感谢大会给我提供这样一个机会跟大家分享光宇游戏在云计算里面的经验。

沈崴，光宇游戏的CTO.现在负责公司游戏平台的运维以及研发工作。我今天给大家带来的题目是游戏运维实际经验的分享。把我们在运维中用到的虚拟化、大数据、案例呈现给大家。

首先跟大家介绍一下网络游戏运营的现状。当前的格局正在发生剧变。端游的份额在下降，页游和手游正在崛起。传统的端游在当前依然占据了绝大部分的市场份额。主要是收入方面。收入和在线人数的下降趋势是非常明显的。它的主要特点在于研发周期非常长，而且成本很大。特别是在上线前的推广原料、推广拉新的成本非常可观。04、05年的时候只需要花五块钱就可以拉新。10年之后，这个价格涨的很快，现在三四十块钱也拿不下来。新游戏的上线必然面临着一个很尴尬的局面。老用户已经被现有的游戏巨头的旧产品瓜分。新用户要用极高的成本争取。老游戏的环境因为用户基数大，具备了雪球效应，可以吸收新用户积极进入。

近一两年来，新游戏，特别是成功的端游非常少见，如果没有新鲜血液的注入，端游市场的没落应该是一个必然。当前的热门是页游，页游当前占20%到25%的份额，而且一直在成长。它的特点是开发周期短、上线快。技术也在发展。大的页面展现能力和端游在接近。它的客户接入端门槛非常低。基于这些特点，未来若干年页游的发展还会保持一定的活力。

手游增长非常迅速，每年能达到200%到400%的速度，可以用井喷来形容。手游的发展完全依托于智能手机的诞生和普及。另一方面，手游的开发门槛非常低，有非常大的开发群体作为基础。今年9月份我在东北几个学校里面，我发现大四的学生，仅仅在学习JAVA的过程中，一个月内就捎带着做了五款手游。直接手机给我展示，做到第五款，无论展现的形式和效果已经非常接近他拷贝的原版了。从这一点来看，开发者群体的壮大、开发门槛的降低是手游发展非常好的一个环境。而且今年的资本市场也会非常看好。股票涨靠的是讲故事，故事的核心是对未来的预期和描述。这也跟我们对手游市场未来的发展是相互映射的。在不久的将来，手游的市场份额必将占据最大的份额。

随着页游和手游的发展，有一些自己的特性，我总结了一下在游戏运维的环境下我们面临的挑战有五点：页游和手游服务器网络架构具备多样性。高频次的开服及维护工作。对带换服务器环境的高弹性要求。海量游戏数据存储及挖掘的需求。新的联运模式的后台大并发高实时性数据查询要求。

下面介绍一下光宇游戏的运营环境。光宇游戏是从2004年发力做游戏的。最早是从端游开始的。游戏平台也是规模比较庞大的。在12年之后我们基本停止了端游的开发和运营。所有精力全转入页游和手游。与此匹配，我们的技术团队也在研究手游和页游的平台游戏的架构。特别是关注于云计算技术的应用。我们着重切入了两块应用。第一个是基于KVM的虚拟化应用。对设备进行工厂化管理，极大的降低了运维的成本。第二，机遇Hadoop大数据的应用。主要用于游戏数据的挖掘，为企业的BI打下一个很好的基础。Hadoop的使用能让我们轻松的操控海量的运营数据、深度分析，并且提供游戏运维的决策依据。

平台游戏面临的挑战，我们的页游和手游产品线长、产品多。架构充满多样性。早期我们做端游的时候每年就是几款产品，页游达到了十几款产品。手游今年我们要上线几十款新产品。开发团队很多。他做的这个服务器端，基于LUNIX的，windows2003、2008、win8的sever.还有用芒果BB的。还有各种文本的数据库。

服务结构的多样性。一个区内的服务器架构是定复杂的。DD、LOG、凯奇。总结来说，我们有门槛很低的开发团队，游戏的多样性非常大。产品选择游戏，他看重的是游戏性。他不关心架构。我们运维要做的事情就是用你的运维能力去适应各款游戏的架构多样性。我们的应用还需要隔离化。它有很多安全性、管理性、交互性的隔离要求。造成我们服务器的规模非常庞大。也给我们带来运维操作的要求。高频次的开复。一款火爆的页游一周开复几十个是很正常的。关复、合复、磨复频次也是很高。生命短、变化快，一款游戏上线的时候，一组很可能达到上千人。而下线的时候很有可能达到三千人。广种薄收。这带来了对服务器的弹性要求。开始人很多，到后面人就很少了。这给我们带来的主要是成本。周期和频次带来了人员操作成本。服务器上下架，OS的安装和更改，以及应用的部署。都会带来巨大的人力操作。弹性需求导致了资源的浪费，这个资源包括服务器、IDC多种弹性资源。

采用了标准化IDC之后，为我们服务器带来了虚机的变化。端游以后考虑到有一些负载率很高的机器转化率不合适。所以我们占了30%的份额。页游和手游除了个别的服务器之外，基本上百分之百都在采用虚机在跑。同时，我们为手游和页游量身订作了匹配的虚拟化运维环境的运维流程。所有游戏运维进行了WEB化的管理。运维操作上也带来了一些变革。比如说OS、动态迁移。监控方面可以实现BIOS级的带外管理。带来Host和Guest两级监控。手段也会增多。最终目标会实现运营手游和页游服务器的集群化。另外，游戏区的一键安装。这是一个终极目标，目前我们还实现不了。

最后总结，虚拟化应用应该是平台游戏最后的必然选择。不光我们公司这么做。大的平台游戏厂商基本上也在采用虚拟化的方式来运营平台游戏。最直接的带来成本的节约。一块可以提高资源的利用率，显著劲敌IDC的成本，另一方面，虚拟化可以降低运维管理成本。从数据看光宇游戏虚拟化成本节约。13年达到了852%.意味着一台实机可以虚出来8.5台机器。别小看这个数据，跟大家透露一个私密的经验，在座的很多都是技术的负责人，当你年底给老板呈现述职报告和绩效的时候，这个数据能说明很大的问题。1：8.我们现在一个机架最多承受14台机器。而北京地区平均的机架费用大概在五千左右。用两台服务器替代了一个机架，先不用说服务器上的节省。单说机架来说，两台服务器一个月能节约五千块钱里面的四千，一年就是四万八。大家可以考虑考虑这个数据的意义。

下面介绍一下我们这几年来虚拟化IDC游戏的历程。从2008年开始。我们开始接触基于VMwar esx的服务，他很难找到二次开发接口进行系统改进。所以我们的操作多数是基于手工的操作。后来发现随着虚机规模膨胀。资产的数据变得非常的混乱。到最后都难以为继。后来我们用一小段的字，在2010年的时候直接介入了KVM的技术。KVM技术使用带来了全新的面貌。它能够提供一个非常庞大的应用接口库。针对此，我们自己开发了一套类似于OPEN  Stack的管理软件。这里面能够应对我们所有的问题。它对游戏和运维的价值：第一是硬件成本的节约和资源成本的节约。第二，带来管理上的便利和高效。

下面介绍一下技术架构。我们虚拟化的前端采用的是KVM，后端采用两种存储模式，基于网络的MFS存储集群和基于本机的RAD硬盘组。前者提供了廉价的大容量的但是相对小IO的存储环境。后者提供了一个相对小的空间，但是大IO的环境。我们默认优先采用前一种情况。所有虚拟机的管理全部依托于KVM管理系统，它能够高效灵活分配资源、一键部署、动态迁移。虚拟机和我们的资产系统是联动的，这也是我们没有去用开元OPEN  Stack的原因。

下面一个图是私有云的现实的架构图。整个IDC中大家可以看到，有很多服务器的节点。整个蓝色的虚线框框出来的节点都是KVM的节点。提供的是KVM的运算能力。而黄色的框里面的节点都是基于MFS的节点，它提供了存储的空间，每个机器都是12盘位的大硬盘服务器。中间黄的容量我们虚出来了一百个T的空间。虚机的分配和使用，旁边两个红色的虚线框出来的机器，我们从前端分配了CPU、内存、网卡这些计算资源。后端从存储资源里边拿出来20T的空间，加起来形成了windows  2008  20G服务器的服务器。这个云是企业架构私有云的很好范例。

下面介绍一下KVM管理系统。如果不依托于这个系统，主机是一对多。主机上的资源是分配的非常复杂。比如说你16个核，分配给8个机器怎么分。内存怎么分，硬盘怎么分。多对多的环境是蜘蛛网的环境，非常头疼。所以我们开发了KVM的管理系统。每个色块代表了一台虚机。下面的实机能覆盖十台以上的虚机。蓝色的条，我新建的一台虚拟机，点选机制，增加GUST之后，虚拟机管理系统会非常智能把你需要的虚机资源在现有的实机环境中进行实际匹配。很多侯选都是满足实际的虚机。你只要从环境中默认第一条，就可以在两分钟类生成一台新的虚拟机。如果更加自动化之后，可以根据一个区组的需要，多台机器一块生成。甚至在生成的机器上附加应用。这就是我刚才说的一键部署区的技术。

下面介绍一下实机、虚机、游戏数据库的机群之间的匹配使用。并不是我们的虚拟化平台就把所有的应用全包括进来了。还有一个配合问题。我们建议每一个区组开放之前的测试区每一款游戏都要匹配相同环境的实体机进行匹配和对比。对比的数据得出性能，兼容性、稳定性的报告。在达标的情况下再把所有的应用全部切入到虚拟机。在这个环节里经常会出现很多很怪异的问题。不兼容、不稳定。这都需要服务架构的调整和参数的调整。虚机主要是低IO的需求，高IO的需求我们用本地的存储。

我们不太建议把数据库放在虚机上。主要是因为它的资源利用率，特别是IO非常高。在虚机上还要经过一次转化，性能会降低更多。我们通过方法是实现多实例，在一台机器上假设多个实例，满足多个实例的运行。它的原理跟虚机的类似。在节约成本和资源管理上同样达到类似的效果。实例要混放，你不能把组合全放在一台机器上。在第一台机器上我们把主一从二，主三从四布局。第二台机器是从一主二，从三主四。能够保证主从在同一台机器上。

接下来我们切入今天跟大家分享的第二个技术方面，大数据，大数据和虚拟化是一对好兄弟，要用应该一块用。我们的平台游戏面临的数据环境跟原来是不同的。首先平台游戏时代，海量的数据是一个现状。这些数据是可以更新以及插入的。日志数据是一条一条的记录。同时，还有外围的数据，社区和平台的数据。还有监控的数据。比如说游戏运维里面的故障和网络。数据库的多样性造成了数据格式的多样性。我们从不同的数据源导入数据。最后进入数据中心。之后联运的形式也带来新的数据要求。原来我们做数据挖掘和分析都是基于前一天的数据。夜间跑。但是现在大的游戏平台提供联运的模式。特别是三国、神仙道这种游戏，它的游戏已经提供了一种标准，提供了大量实时高负载的查询。既然成为标准。我们公司也要做联运，也要对外放游戏。所以要遵循这种标准。所以他带来高实时性和并发查询的要求。我们11年之前，都是在使用mysql的游戏架构，最说性能比mysql标准高很多，但是它的单机运算能力不能达到要求，运算时间不断增加。在11年起我们逐步的使用了hadoop的架构，当前处于非常低成本的环境。我们用的都是五年以上报废的服务器，成本非常低，我们加了内存和硬盘，作为一个hadoop的成本。上了hadoop之后，我们有所有数据的保存，包括对话、包括地上掉一个东西，包括一个小的变化，这些数据可以永久的保存下来。而且实现了以往无法企及的运算能力。

介绍一下我们hadoop集成的数据环境。当前我们光宇拥有一百台以上的hadoop的节点，总容量300T，当前已经使用了200T，每日的新增数据在5个T以上，每日任务书220多个。这跟阿里、百度的hadoop相比是非常渺小的。但是作为一个游戏公司是非常适用的。而且我们当前还在不断的发展这个环境，这是一个很好的基础。在游戏运维中什么样的范围适合hadoop在里面搞。我们的日志文本、游戏库数据，阿怕奇，以及一些特定的全部是在hadoop做。我们还把IDC和本地网络syn和fin包也导入hadoop进行运算。我们可以得到一个非常好的网络审计的功能。它有点类似于以前的CDS.

我们最说拥有了hadoop，但是它不是包罗万象的。我们根据需要把数据查询需求分别分配给了，比如说基于mysql的和基于hadoop的。这些场景怎么匹配编程，这是非常实际的问题。第一，我们实时的低负载查询。简单例子就是在线人数。我要求得到五分钟前的在线人数。这个数据压力不大，但是实时性很高。第二，我们需要得到复杂查询，要连表，索引不一定起作用。这个时候我们要做一定的延迟。把数据导入hadoop，三十分钟之后，我们动作HBase基于PY6的查询。第三种，非实时小负载日志及记录查询。这两种形态的差别，我们尽量用hadoop因为它的开发成本非常低，但是大的执行效率非常高。当hab解决不了问题的时候，我们要转到mapreduce.这些查询都是预设的，查询的时候也是及时返回。我要把一个大量的数据集和日志全取出来。我们也是通过两种形式实现。第一，负载不大的时候，把每天的数据还是导入到mysql引擎里面。对于高负载的查询，一种是放在HBase里面，这些数据可以给玩家提供他在一年前的登陆和充值信息。我迅速把他的数据调出来。接口能实施一段时间。另外一种情况，我不需要马上出结果。我们最标准的是用mysql运算大数据。尤其mysql的预启动和资源分配需要有几十秒的延迟。最后一个场景是我们面临最大一个课题。我们希望减少这个时间，并且希望尽量把这个应用往这个上面来放。

下面这个是光宇hadoop的系统架构图。所有的游戏数据和相关的日志数据分别通过ETL和mysql系统导入hadoop平台。mysql提供了一定的实时查询。hadoop提供了大数据的运算。也实现了OLAP和数据发掘的能力。之后我们把任务跑的结果导入mysql的库。最后通过光宇数据中心的核心的API接口提供各个需求层面对于数据查询的具体需要。

下面也是自己研发的一个环境，我们把hive进行了外部化的改进，能够在实时的系统里面挑出一些测试语句和平时的查询语句。不用面对敲代码的环境。除了hive的使用，还提供了EDS监控集群和平时的管理。

虽说我们已经用了很长时间的云计算，但是自身感受很深。我们在云计算的路上刚刚起步。我们面临着很多的问题和有待解决的挑战。下面是我们正在解决的或者还没有解决的问题。希望之后有机会跟大家进行交流：第一，存储集群带宽制约了虚拟机的IO.盛大、百度也会存在这种问题。我们后端现在采用的是一个网络存储的集群。他的带换限制于，当前我们是牵着网络在个别环境下进行了捆绑。你可以提升到万兆，他从存储、本机或者FC的光纤环境还是有差别的。所以，对于大IO的应用我们还是在躲避。测试中在虚拟机环境下还有很多的应用是不太稳定的。诸多的疑难杂症，我们长期会遇到一些新问题。下面是大数据的问题。配合使用mysql、hive、hbase、mapreduce，怎么配合使用。以前一个sql语句做过分析，在mysql里面一千多秒，转到hadoop里面提升到200秒，hbase一百秒。用mapreduce直接编程，不到十秒。mapreduce的成本会非常高。mapreduce的数据实时查询，hadoop系统权限管理。超大型维度表的更新效率提升。