GMGC亚马逊AWS专场：云·游世界

4399手机游戏网爆料。第四届全球移动游戏大会(GMGC2015)于北京国家会议中心盛大开幕。作为大会期间的重磅活动之一，“亚马逊AWS专场”于25日当天下午在国家会议中心三层310会议室隆重召开。

以下为现场实录：

费良宏：

非常高兴大家的到来，今天下午我们将跟大家分享一些我们认为非常有意思的话题，首先我跟大家介绍今天第一个主题，关于AWS云计算针对游戏架构的实践，在这个环节里面我会非常简单的跟大家分享一些我们架构的设计原则，以及一些在游戏行业的实践，主要是在一些移动游戏方面最佳实践的心得，希望大家能够从这些经验当中得到你所需要的东西。

首先，有这样一个环节，我为大家介绍一下游戏行业的发展现状，以及AWS公司在游戏行业的成果;第二，分享一下对于扩展性，尤其是游戏行业扩展性的实践，以及架构设计方面的要点;第三，介绍一下针对游戏的运维，尤其是DevOps理论在实践行业中的心得。用一个案例分享一下在实际的游戏运维当中实践的方法。

在过去几点当中，游戏业得到了长足的发展，按照很多的调查统计报告可以看到，年度的符合增长率游戏行业已经达到了8%以上，远远超过目前平均的GDP发展的水平。所以在众多行业当中处于领先的程度，尤其从2013年开始，由移动游戏行业得到了长足的发展，我记得那一年年度的增长率超过了50%，有人称之外移动游戏年，无论目前发展的如何，可以预见游戏行业第一可以得到长足的发展;其次随着游戏以及移动设备的不断普及，移动游戏的发展远远高于平均水平。尤其是在欠发达区域，或者说是在增长的市场，比如说亚太市场、拉美市场、东南亚等等，中国也是非常重要的区域，会远远高于世界的平均水平，以极高的速度得到发展。

在这些众多的发展趋势当中，有人总结了五大趋势，每一个趋势如果拆开来谈，可以谈很多内容这里面我最感兴趣的是两个很重要的趋势。

第一，多种屏幕的出现，大家知道现在的游戏面对的市场，面对的用户越来越复杂，尤其在设备方面也面临很多挑战，有手机、平板、手游、也有等等各种形态的出现，用户的选择也出现了多样化和差异化，所以多种屏幕的出现会给我们带来很大的挑战，当然这也是未来的明显的趋势。

第二，全球化市场的出现。由于云计算的普及，基础设施已经变得非常的成熟，全球化的壁垒慢慢在消失，所以我们完全有能力通过好的产品依托云计算提供的基础设施，能够走向全球去。这方面已经有了很多非常成功的案例，希望大家去关心这个发展的方向，将我们的产品更好的推向全球市场，不仅仅是针对一个小众的市场。

刚才我的前一张PPT当中跟大家分享到，在很多区域，比如说东南亚、拉丁美洲的发展空间还没有巨大，是足以引起我们重视的市场和区域。

在游戏行业大家知道对IT技术是重度依赖的行业，随着云计算的出现，游戏行业也找到了自己的立足发展方向，依托云计算所提供的良好的IT技术架构，可以提供给用户非常好的体验。AWS这家公司作过去的很多年里面通过自己的努力与游戏行业很多公司共同成长，在这张图大家可以看到很多耳熟能详的公司，他们的成功也是依托云计算，依托AWS所提供的各种云计算的服务取得了这样的辉煌的业绩。除了在国际上的大牌公司制外，在中国本路也有很多公司获得了长足的发展。比如说畅游、木瓜移动、CoCoS，他们都是杰出的代表，他们取得的成功就是AWS云计算提供的助力。提到AWS云计算服务部得不强调一点，AWS之所以成为游戏行业的首要的选择的合作伙伴，重要的因素在于它提供了全球化的优良的云计算的基础设施，有几组数字跟大家分享一下。目前AWS云计算基础设施在全球11个区域有数据中心，为了更好的满足用户访问的需要，更好的提供网络低延迟的服务性能，所以在全球部署了5个边缘节点，业务的覆盖已经超过了190个国家。正是有了这样一个基础设施的存在，才使得我们的游戏行业依托这样的基础架构可以实现全球化市场部署的可能性的存在。这也是游戏行业需要考虑的一个重要方向，就是如何利用这样优良的基础设施满足我们的发展，满足全球化市场的战略。

在游戏行业的诸多挑战当中，在技术领域里面有两点需要跟大家分享：一是高可用架构的设计，游戏行业的发展有其特殊的特性，对于互联网用户、游戏用户的高速发展产生的压力是非常大的挑战，如何针对这种挑战，针对这种发展趋势做合理的规划和设计是摆在每个人面前的一个重大的难题，在这方面有很多公司都有了很多的尝试，其实我们也从中学到了很多经验和心得，在这里跟大家做一点简单的分享。这两组图跟大家分享一下云计算与传统IT非常显著的区别，当我们运行一款游戏，发布一款游戏的时候会对用户规模、访问的等级做一个估量，由此决定我们的基础设施是什么样的水平，提供什么样的服务。但是很多情况下，由于市场的不确定性，由于竞争的存在，由于用户的行为习惯难以琢磨，会出现在一段时间内突然出现超出预期的可能。对于传统的IT管理方式来说，我们面临一个问题是需要重新规划，重新扩容，在此期间所有的停机时间，或者不能满足用户服务的期间就造成了用户的流失，造成了收入的下降等等。与之相对应就是云计算所提供的弹性的服务，大家看到在你的右手边的那幅图上，随着用户需求的增长，你的IT基础设施所能提供的扩展能力是随之而变化的，两者之间并不存在明显的断裂，我们称之为弹性的服务这也是最明显的云计算和传统的IT之间的的区别。如果我说这样的一个结论，大家还有点质疑的话，请大家看一个真实的案例。

韩国一个游戏公司叫DEVSISTERS，有一款产品是曾经非常成功的手游产品，一个手机游戏。这个公司只有12个员工，有一次意外的事件发生，在APP Store做了一推广，DEVSISTERS并不知道这个情况，短短一夜用户惊人的增长，压力立即产生出来，如果是以往，可能会出现宕机，出现连接失败，或者是用户的抱怨，怨声载道等等，但是这种糟糕的结果并没有出现，原因在于他们使用了AWS云计算，设计了一个策略，就是从两台服务器可以应对不同的需要，扩展到上限60台计算机，也正是因为他们使用了这样一个策略，使用了这样一种服务，所以在短短的时间内就可以满足用户井喷式的需求的增长。所以，很平稳的度过了这样一个挑战和压力，这也是他们取得成功的小小的秘诀。这张示意图是当时用户增长的示意图，增长非常惊人。

针对AWS云计算的环境我们有哪些考虑?通常采取哪些措施呢?首先我们要选择一个区域，如果大家熟悉AWS云计算的基本开年的话，我们有一个概念是每个区域有多个可用区，多个可用区在同一个区域内就可以保证服务资源、数据可以提供高效、可靠、稳定。在同一个区域内，你应该考虑的是部署在两个可用区之上，就是两个AZ之上，第一取得了负载平衡的效果，第二确保了在灾难面前不至于使得我们的服务失效。除此之外，可以讲现有的游戏的服务移植到EC2之上，将这个实力运行起来之后，就可以提供较你们之前一样的运行环境。为了确保负载均衡，在AWS云计算环境里面有一个特殊的服务叫做Elastic Load Balancing，当我们选择两个AZ就可以选择部署负载均衡期，在两AZ之间做好两个负载的性能的管理，满足最大的性能要求。一般在一个游戏里面都会使用数据库作为用户会话，用户数据的管理和存储，应对云计算环境，这种情况下，我们的选择也非常简单，就是有一款服务叫RDS，就是关系数据库服务的总称，RDS对我们来说不是一个陌生的产品，实际上有多种数据库服务供你选择，这些产品包括MySQL、Oracle等等，这些产品也是非常成熟的产品，这些产品移植到亚马逊云计算的环境里不存在任何的障碍，只要选择所对应的数据库产品，部署在亚马逊的云计算环境之上就会得到一样的效果。为了安全起见，为了高可用性，我们通常建议将数据库服务器部署在多个AZ之间，比如说经常会再一个AZ里面做一个主节点，另外一个节点做一个备份节点，或者是一个指路节点，两者之间通过现有的技术实现数据的复制，确保在不同的可用区之间你的数据各有一份拷贝，并且提供高可用性。

针对这个架构还是一个比较粗浅的简单架构，我相信每个人都可能了解或者熟知，只不过将刚才那个架构更多的在亚马逊云计算环境之上在现有架构做了一个影射。另外一个方法针对云计算环境是不是有其他的可以在勇的优化以满足高可用性的服务和架构设计的原则呢?这里跟大家介绍另外几种有意思的服务：

1、S3互联网存储服务。这个产品是亚马逊推出的第一款云计算产品，是一个非常成熟、稳定可靠的基于互联网存储的管理服务。简单来说，它是通过Http协议将任何文化对于，可能是文件、视频、图片或者是一个数据存储到S3的存储桶里面，任何时候在你的应用里面在你需要数据的时候都可以通过HTP协议获得这个文件的内容，这个服务我们称之为S3。很多情况下，我们在游戏行业里面，如何使用S3呢?都是将它作为游戏的用户，游戏的资产，用户游戏的状态以及相关的数据等等保存在S3里面，同时我们也注意到很多游戏公司也非常注重对用户行为，游戏状态的分析，这些分析也同样可以存到S3里面，S3是我们要考虑的针对云计算环境下的非常独特的有意思的服务。

2、Auto Scaling Group，这个产品可以设置很多策略，一旦这个策略被触发之后会实现自动的性能扩展，免除了干预和维护。利用这个服务可以很好的帮你解决未来我们将遇到的难题。

3、Amazon ElasticCache，大家开发一款游戏为了提高性能经常会使用成熟的缓存产品，针对这样的需求，在亚马逊的云计算环境里面也将这类服务部署为托管的云计算服务。这个服务的核心其实就是用两种不同产品构成的，如果你着手把游戏部署到亚马逊云计算环境里面，你可以从ElasticCache找到你需要的那一款服务，很自动的部署上去，而且这种代价很低，不需要做任何代码的修改可以得到内容上缓存的服务。

对于一个真实的网络游戏架构来说，刚才谈到的比较粗浅，实际上在一个真实的游戏案例里面，比如说韩国的那家DEVSISTERS，这种架构远远超过了刚才提前的原则。比如使用多个AZ，多个数据库的节点，而且部署在不同的AZ里面，甚至还使用了一个CDN加速服务，还使用了很多进行数据的分析的服务等等。这个架构就是一个非常真实的架构，这个真实架构的复杂性完全由刚才提到的两个基本原则慢慢扩展起来，从第一个简单的多AZ、ERB，增加了S3，增加了Cache之后增长起来了，这个案例可以参考，对比一下现有的游戏架构是不是能满足云计算，满足未来市场的需要。

在谈到了传统架构之后，不得不介绍一个新的服务给大家。原因在于这个新的服务可以从某种程度上极大的减轻我们所面临的很多的问题，这个新的服务我们称之为Beanstalk，这是一个新的概念的实现，就是容器的概念。最近在云计算市场里面有热门的概念叫容器，很多产品都以这样的方式出现，开发者也愿意用这样的方式打包部署我们的产品，针对游戏，针对这样的环境，我们的选择是什么?我们的选择其实就是Beanstalk而这样一个新型的基于云计算的产品，这个产品提供了什么样的服务呢?实际上是将传统的云计算最基础的几个服务，比如说EC2，比如说ELB、RDS变成管理的环境，由这个容器统一进行管理。开发者关心的只是游戏本身，涉及到ELB，涉及到数据库操作的运维、设置、优化等等全部要交给Beanstalk。现在的一款游戏如何跟B结合呢?管理和使用它非常容易，只需要打包Git文件，或者分发工具就可以部署到Beanstalk里面去，部署成功以后就可以成功运行这样一款游戏了，为了管理这样一个容器，提供了Web仪表盘，任何管理人员可以通过浏览器观测到容器的运行状况，游戏运行的状态等等一些指标，从而实现最基本的简单的维护。我所说的基本和简单并不是功能简单，只是对要求和复杂程度进行了极大的简化。

也许大家担心会不会对性能优很多损耗呢?通过各种技术不断地演进，或者说使用了很多更好的管理方法和技术手段，它能够提供非常一致性的性能，所以在这方面大家不用特别担心。请大家是不是可以考虑一下，在你的当前产品用Beanstalk去部署或者是体验一下它所带来的这种简单的容易使用的感觉。

我们来看一下，如果在一个真实环境里面，Beanstalk如何运作和管理呢?我们看到这是一个Beanstalk简单的示意图，在这个容器之内包含了ELB，就是所有的负载均衡的管理是由这个容器本身进行的，大家也会看到在这里面会有两个数据库的节点，这个数据库的服务或者是运维工作也是由服务器进行管理，我们所需要的仅仅将应用部署到容器就会得到这样的效果，同样容器也会将它的运行状况反馈给我们的管理人员。当然，在这个容器之外我们可能还会需要与其他的服务进行交互，这些服务可能是S3，可能是CBN服务，可能是Cache，也可以跟应用本身进行联系，开发者也可以提高通知服务、缓存服务提升性能，满足各种场景下用户游戏的需要。

关于Beanstalk：大家可能会担心这个产品是不是一个实验性，不是很成熟。我记得在去年下半年，AWS年度技术大会上面，当时索尼公司就分享了一个案例，那个案例就是他们有一款很经典的游戏，叫《击溃地带》，那款游戏就大量的使用Beanstalk作为他们运行的基础环境。Beanstalk的几个特点：一是它非常的简单，可以非常容易快速、简单的起步，不需要我们对象关的技术、环境有太多的深入的了解或者知识的需要;二是它可以帮助我们直连DynamoDB，这个服务是完全托管的基于云计算环境下的DynamoDB，性能非常好;三是CloudFront+S3提供了下载以及上传的能力;四是按需只能加游戏服务器。

在这个环节的最后为大家分享的是一个小小的案例，这是一个澳大利亚的游戏公司(Twiitch)，这个公司有几十款游戏，大概几十个人规模，有Android版本、ios、Face book版本，他们人手非常少，使用基于Beanstalk，他们需要将人员专注在游戏本身，不需要有太多的人员资源消耗在运维和基础架构上，所以这家公司选择了Beanstalk。目前的情况是，他们大约有60多万Face book在线用户，这是当时的数据，不包括Android、ios的用户规模，用Beanstalk使他们降低，减少运维的负责成为上取得非常显著的效果，这是一个比较经典的案例。除了刚才谈到的Beanstalk之外，在很多架构设计当中还会遇到一个非常头疼的话题，就是数据的问题。因为游戏本身是一个对数据库重度依赖的场景，所以数据的问题就成了我们一个非常头痛的话题。经常我们会使用一个数据库存储相关的内容，而且写操作的比重非常之高，所以传统的通过缓存或者相关的其他技术经过优化的手段往往在这个环境下并不是那么有效。归纳起来，对目前使用的数据库来说面临着极大的压力，也是数据库的瓶颈问题，针对数据库的瓶颈，在过去很多年采取了很多种方法，有很多尝试，比如说常用的方法是分片的方式，将数据库按照某种逻辑，应用逻辑也好，物理上的设计也好，分成多个不同的片段，由多个节点提供服务，这种方法在某种程度上可能缓解了刚才提到的数据库的瓶颈或者是数据库的压力，同时它也带来了一个很大的问题，一个是复杂性上升了，第二是可扩展性还是很成问题，使得应用开发的逻辑变得更难以管理。这个问题的出现一直以来并没有得到根本的缓解，目前采取的方法是在局部缓解了问题，并没有从根本上解决掉这个问题。对此我们有什么样的建议呢?其实一个很好的答案目前已经出现了，就是NoSQL数据库的流行，它的就要是对传统数据库弊端的补救，最大的特点是提供了横向的扩展能力，逻辑上它可以不受限的扩展多个节点，性能本身可以满足线性的增长，这是跟传统数据库来说最大的不同。NoSQL数据库有很多不同的版本，不同的实现，所以我们面临很大的挑战就是如何选择，并且如何将NoSQL数据库跟现有的游戏和现有的项目很好的结合在一起。在AWS环境里面我们针对这种需求已经提供了一款很好的解决方案，这个产品就叫DynamoDB，DynamoDB是一个非常经典的NoSQL的实现，除了NoSQL基本的特点之外，有独特的性能和管理上的优势。第一，高可用性非常好，是一种托管的方式，是用于AWS云计算环境来管理。第二，可扩展的吞吐量在这方面有很好的证明，很多应用本身利用DynamoDB达到了非常高的指标。第三，针对性能的要求也增加了很多NoSQL并不提供的功能。综上所述，DynamoDB变成我们在游戏场景里面非常好的NoSQL的选择。

这张图大家非常熟悉，就是《水果忍者》，它的再生刚上线的头两周用户规模就从100万增长到了800万的规模，当时对于这样一个很小的一款游戏，很小的一个公司来说这种压力无疑是非常惊人的，800%的增长，当时帮助他们度多这个难关，很平稳的实现了用户访问，涌袭进展的基础就DynamoDB ，这是一个非常好的例子，所以请大家记住。

关于扩展性的总结：

1、重新利用Auto Scaling来节省成本。刚开始可以配置比较小的规模，今后可以扩展。

2、记住Amazon CloudFront+AmazonS3可以用来解决下载和上传的需要。

3、引起痛苦的DynamoDB，这是一个可以解决数据库瓶颈的非常好的服务和产品。

4、使用APIs去动态的管理游戏服务器，AWS云计算的每个产品都提供了非常丰富的API，你可以利用这样的资源对他们进行非常好的动态的脚本化的管理能力。

5、过去一个环节就是在多可用区如何选择选择，去部署你的产品和游戏，这几个原则是在刚才谈到的几个场景里面的基本原则。

时间的原因不可能展开每一个环节，最后分享一个运维方面的实践经验。大家可能知道，DevOps是一个非常热门的话题，在游戏行业这个事情变得非常的棘手，就是要快速发布，快速部署的能力，这种情况的出现也面临一个挑战就是开发和运维之间产生了巨大的压力，因为部署一款游戏并不是一件很容易的事情，这种情况的出现也导致了我们去反思现有的开发、测试、部署、运维的流程是不是能够满足现在市场的需要，针对这样一个场景，各种的理论都层出不穷。我们达到的目的非常简单，就是要部署前、部署后，对用户来说毫无感知，没有任何影响不会产生数据碎片，但是实现它并不是一件很简单的事情，尤其是一款大型游戏，一般来讲对于场景来说需求是哪些?首先是自动化的，可以重复的过程，因为你面想不通的区域，可能由于产生异常需要经常进行重复这样的操作。所以，一个自动化的部署是一个最起码的要求。其次是要有恢滚的能力，一旦发现部署实效要回退到上一个可用版本。另外，对用户的影响要降到最低，因为如果产生任何问题造成的损失是难以弥补的。

分享一个案例就是一个游戏公司使用的蓝绿发布，它是针对DevOps里面的一个实践经验，蓝绿发布就是部署了两个环境，一个是蓝色的环境，一个是绿色环境，分别对应测试环境和生产环境，我们会在生产环境提供用户的服务，绿色环境里面安装部署新的硬件、软件、游戏等等，部署完之后进行验收测试，一旦就绪之后进行切换。在原有的环境里面进行标签的切换之后就可以重新部署新的游戏进行新的升级。大家可能感觉这个过程是一个比较简单的过程，逻辑上也比较容易实现，但是在一个真实环境里面，在一个大型的游戏环境里面有众多的资源服务器实力的时候这并不是一件容易的事情。SCOPELY这家公司实现的方法是什么样子的?这并不是一家非常小的公司，他们有很多产品，在APP Store里面很多产品都是排名第一的，而且一款游戏的用户规模有3500多万，每天有10亿规模的请求，而且完全构建在AWS之上的。这几个指标可以证明，在一个真实的复杂环境里面，蓝绿发布可以帮助我们起到怎样的效果。

这家公司总结了之前的很多经验，结合了自己的需求，形成了自己的独有模式，这个模式综合了其他的概念，比如说金丝雀，它是另外一种增量发布的方法，使用了很大量的AWS的服务和资源，做了一些归纳，并且将一些特殊场景的用法做了一些特殊的处理，满足不同游戏之间部署上限的独特的要求。

具体来说，将整个游戏的发布步骤反成了六个环节，从预览开始到切换部署了6个环节，每个环节都使用了大量的AWS服务，并且开发了多个脚本进行自动化的操作。并且使用了CloudFormation，是基于模板的一种快速部署和服务，在脚本模板文件里面进行部署对象的描述，之后就可以运行这样一个模板生成的脚本文件，实现大批量的快速的部署，可能在几分钟之内帮助我们形成几百个甚至更多的运行实力，帮助网络部署资源分配等等，这是一个非常好的工具和产品，在蓝绿部署里面，它起到非常重要的作用，不论是标签切换还是在原有资源的销毁方面都是依据它实现的。使用啊CloudFormation对原有标签进行销毁，并且创建新的环境，打上新的标签。在监控方面，这家公司也开发了自己的脚本，来获得相关的健康数据，健康数据汇集到Kinesis里面去，Kinesis可以24小时保持所有健康数据，对应的4个Glacier里面进行对数据的使用和管理，这是他们的一个实践的心得。

归纳一下，刚才谈到了这并不是一个简单的实现的步骤，这个规模非常惊人，他们实践的数字也可以给我们很多的启迪。3500万用户，每天有10亿次用户请求，每款有戏有10—50个实例，每款游戏每天都有多个版本的发布，所有这一切都是依托AWS提供的基础服务，依托于他们所设计的独特的自动化的管理模型完成的。需要强调的是，在整个环境里面他们只有两个运维人员，投入的人数非常之少，之所以能达到这样的效果完全是基于刚才谈到那些服务，谈到的那些方法实现的，在这里请大家考虑是不是在你的环境里面应用这些技术、手段和方法达到一个非常好的效果。

今天的内容就介绍到这里。谢谢大家!

庄富任：

各位在场的嘉宾大家下午好!

非常高兴有机会跟大家分享一下AWS大数据服务，我是庄富任，我是AWS中国产品策略和市场拓展负责人，今天要讲的是AWS怎么样让游戏开发者建立大数据分析平台。

为什么现在两个话题很热，云计算和大数据。这两个结合非常好，为什么?第一，对于大数据来讲，你需要有一个能够储存海量数据的地方，有了这样的地方才能利用高计算的量去计算这些数据，所以对云来讲它提供了无线的数据池，高扩展性的计算资源。

AWS基于云的完整大数据服务，可以看到海量数据的收集，我们有Glacier，它可以进行实时数据流采集处理、大规模存储、大集群并行计算。你存了这些数据以后需要一个分析的工具，今天会着重再讲两个地方，一个是Hadoop，另外一个是数据仓库。

为什么大数据那么重要，尤其是一些游戏开发者来讲很重要。因为大家关心的还是游戏运营的指标，所以你可以看到很常用的指标，相信在座的游戏开发者都耳熟能详，日活跃度、月活跃度、留存率，这都是非常重要的指标。有了这样的指标，你才能优化你的游戏运营，才可能提供相对应的策略，做的更精细一点，有的游戏开发者利用大数据可以细分每个不同族群的玩家、喜好，提出相对应的产品策略。

首先，你要收集不同的数据，因为有了数据你才能计算那些指标，跟踪那些指标。所以，第一个问题来了，你怎么样存储日志，可能是游戏日志，或者是一些玩家本身的数据，利用年龄、地点。甚至还有第三方的数据，需要有大量的数据存储的地方，把这些数据进行汇总。

现在我们最头疼的问题是这些数据的收集，收集完以后会有一个数据池子放这些数据，如果光收集，没有地方放，这些游戏数据对游戏开发者来讲是没有用的。目前来讲，你可以怎么样做，怎么样收集你的数据?目前，有很多开源软件，现在常常看到就是Kafka、Flunetd，你在AWS云平台上都没有问题，你可以搭建数据采集的大型集群。好处是什么呢?因为在线的人数可能几千人、几万上，甚至一百万人，你的数据收集集群可以有弹性，可以伸缩。当人数、数据量少的时候，这些集群可以不用10台机器，当人数多的时候，收集的数据量越来越多可以扩展到50台、100台、200台这样一个大集群。对于AWS来讲，你用第三方开源软件搭建收集数据平台是非常方便的，我可以提供高度伸缩很可靠的集群，你不用担心有失误和损坏，因为它是在云平台上跨区域的大集群。

第二个问题是，我收集起来的数据，目前大家第一个想法是放在本地的硬板，因为每个服务器一定会有本地的硬盘，但是你要考虑它的持久性和容量。因为硬盘在云上面不用担心，但是你想一想，如果在实体机上预测自己的容量，容量不够了还要采买一些硬盘，硬盘每年有3—5%的毁损率，所以你还要用人工替换掉硬盘。所以，我们的建议是你可以把数据收集的大集群，收集出来的日志和玩家数据直接并行的加载到S3，速度非常的快，好处是并行加载放在S3，你可以想象S3是无限容量的大的池子，而且有高持久性。我有一个比喻，你存1万个无间道S3上面，我可以保证一千万年都不会丢失。传统用硬盘存一些数据还要做备份，硬盘的毁损造成数据的丢失，对游戏开发者来讲这是非常头疼的问题，如果把所有的东西都放到S3我可以保持你的高持久性，不用担心容量，不用担心换硬盘的问题。所以，这是一个满好的实践。

数据越来越多的话，日积月累会越来越多，一个月、两个月、半年、一年，有些数据对于游戏开发者来讲，或者对运营人员来讲，很多数据其实过了几天，或者过了一个礼拜，很多数据还是热的数据，但是很多数据过了一年以后，想丢又觉得很可惜，这时候可以用Glacier冷备服务，Glacier不是次贷机的实现方法，它可以在3—4个小时，很快的把你存的数据从Glacier拿出来，拿数据的速度很快，成本也非常低，当然也有持久性，你不用担心数据的丢失。它有一个生命周期管理的功能，你可以设定S3的某些数据过多少时间点可以做一个自动的备份到Glacier，多长时间后做删除动作，因为你觉得不需要了，这是自动化的过程，对于运营人员来讲，尤其是开发人员来讲，不需要担心需要手工做这样的设定。

从数据的收集可以用开源的软件，Kafka、Flunetd，可以做数据流的处理，Kinesis等于取代刚才的步骤，用开源去搭，至少要用Kafka，去搭一个集群，去做运维，大家担心集群里面有问题。对使用AWS的游戏开发者来讲，很简单，你点一下鼠标就可以搭建起一个实时数据流的服务产品，叫Kinesis，这个东西设计完以后，你不用担心它的扩展性，因为对前端来讲，它有自动的扩展性，前面不论有多少的数据，一次就可以吃下来，做一个处理，处理完以后还可以选择后面对接什么样的AWS的产品，可以是S3，可以是Hadoop。

有人常问我，以前是比较批次性的大数据的分析，现在的要求是批次性的处理，3个小时、6个小时、半天的大数据分析已经不够用了，越来越多的人希望它是实时的数据分析。很多使用场景也看到，在AWS的平台上，很多我们的客户在使用。很多的使用场景还是开发人员想利用这个云平台可以做什么事情，对广告平台来讲需要实时性，因为每个客户，或者是每个前端使用者点击了什么东西，我是不是可以很快可以推送适当的广告，通过Kinesis可以做到实时的数据分析。对于电商也是一样，用户的行为喜好可以分析出来就可以给他推荐适合他的产品，对电商来讲可以提高更大的购买率。对于社交网络也是这样。对游戏来讲，你可以实时间知道前面几百万玩家在做什么东西，这是很重要的，假设我能够在比较实时的状况知道前面的玩家做什么东西，就可能知道目前哪一个道具可能最流行，哪些道具卖的不是那么好，如果有这样的实时数据可以实时优化数据，可以实时做市场推广。很多时候，我们也看到，如果有实时的数据进来，我们也知道玩家玩到哪个步骤停顿和宕掉，我也可以做游戏产品的修改。

我们有好几个数据，比如Glacier，收集进来放到S3，放进去以后可以做分析。K怎么做好大数据分析?主要是两部分：不同的数据进到S3以后，用两个东西可以在AWS上使用，一个是Hadoop，就是非结构化数据，或者是半结构化数据，尤其是一些日志是一些半结构化的数据，这时候可以用Hadoop的集群进行分析，它是批次的大量分析，跑一个Hadoop的分析脚本，可能都要几个小时的时间才跑得出来，所以适用于大量的批次数据的分析处理。我们还提供数据仓库，数据仓库跟一般的数据库一模一样，它是一个结构化数据，主要是以表做数据的存储。

在座的大家都很清楚，我提到了两个工具，一个是Hadoop，为什么会用Hadoop?如果是单一的机器，数据的存储是一个问题，数据计算节点有瓶颈，Hadoop解决了这两个问题。它是一个大的集群，它可以横向扩展，数据可以做扩容，当你做一个横向扩展，计算资源也会是线性增加。通过Map做一个还量的分析，会不会很快更省钱。我通过Hadoop搭一个大的集群是非常头疼的问题，看一下目前就业的市场，你会发现Hadoop大数据的工程人员其实很缺，因为这不是一件很容易的事情，如果游戏开发者没有任何的Hadoop或者大数据的经验，搭一个集群的话可能要几个礼拜的时间，还不包含要买机器，还要找空间放我的机器。所以，希望通过EMR，EMR是Hadoop推出的一个产品。你不用担心EMR不兼容开源社区。AWS的EMR就是开源的Hadoop，我跟上面所有的开源的第三方的工具是完整的集成，所以你不用担心是AWS自己做的封闭式的软件，大数据的Hadoop的东西。我们跟第三方的开源公司配合的很好，你可以看到主流的Spark、分析语言、数据管理等等，我们跟Spark有非常好的关系，他们开发出流计算的工具都在AWS上面做的。对整个开源社区Hadoop来讲，不用担心集成的问题，可以完整的支持。对于我们自己的产品来讲更没有问题了，所以如果你在用S3，你可以很容易的拿S3的数据做分析，所以对我们自己的AWS产品的整合也是没有问题。

如果你真要搭一个Hadoop集群的话，用几天、几个礼拜是很正常的事情，更不用讲，你搭起来以后软件要做优化，这不是一件那么容易的事情。对游戏开发人员来讲，你要做的事情很简单，我刚刚提到了很多数据收集的方法，把它放在S3上面，只要在我的管理平台上，你也可以用我的API做一个Hadoop的集群，你要做的东西是什么?你要的Hadoop是哪一个版本，要多少个节点，机型是什么都可以选择。因为AWS提供不同的机型，有高内存、高CPU，不同的机型，你只要选择适合的机型。然后再选择你要跑哪些脚本，大概几分钟的时间，Hadoop的集群就可能了，你就可以跑你的一些应用程序，这个非常容易，因为搭一个Hadoop应用集群，你们可以自己去试一试，5分钟就可以起一个很大的集群，跑完以后就可以把数据放到S3，是一个非常简单的流程。

我们设计的重点，或者说最佳的实践。把所有的数据都放在S3上，第一个好处是什么?它是一个单一的数据源，目前从你们的环境来讲，数据东存西存，每个地方都存了一些数据，S3提供给你的是大容量无线的池子，你把所有的东西都塞进来没问题，所有的人都拿同一个池子里面的东西。因为我有这种持久性，所以不用担心节点的丢失。如果你自己做Hadoop的集群，Hadoop的集群就有数据的节点，这些数据的节点都有可能有机会丢失，你可能还要做一些人工的运维。你也不用担心这个节点因为现在是100T的数据，没多久游戏玩家的数据量越来越多，可能会变成200T，我又要采买机器，加节点，如果放在S3就不用担心这样的问题。你可以看到我们的界面，如果你上AWS无中国的网站，你上去，其实很简单，你要起一个Hadoop的集群，你只要在上面EMR创建一个集群，你跟我讲什么样的机型，什么样的数量，要什么样的版本，执行什么样的应用程序，或者说什么脚本，你跟我讲，你这些脚本在哪里，算完以后要丢到哪个地方，这些简单的设定完以后就起了一个Hadoop的集群，就开始跑大数据的分析，看起来步骤真的非常简单。

AWS云上面起一个EMR Hadoop的好处很明显，因为云有弹性，可以随时增加、减少节点。如果你的老板说，现在要以前三个小时的数据分析，说现在就要，一个小时之内给我，你就可以加大节点，把数据跑出来，把结果跑出来。我所有的资源都放在这上面，数据和资源是隔开的，我可以让不同的业务单位，不同的开发人员可以很容易起EMR的集群，分析同样的数据。传统怎么做呢?你只有一个Hadoop的集群，不同的人，或者不同的业务部门都要争Hadoop这个资源做数据分析，所以有一些资源的竞争，一个节点，有的业务部门就要等其他业务部门跑完数据分析才会轮到他。如果利用AWS的EMR就可以好几个不同的业务部门自己起自己的业务分析的集群，去S3拿数据进行分析，没有资源的竞争。算完以后对云来讲，如果不需要再算的话就可以把它关掉，这就是云的好处。对于开发人员或者大数据分析人员来讲，可以很容易的要到资源，做完计算，停掉EMR集群。传统你买了100台机器，大了Hadoop集群，买了就买了，不用的时候就在那儿空着。

总结一下，通过很方便的包装、托管Hadoop EMR的服务，开发人员不用担心后期的运维，我就用几分钟把数据模型写好，脚本写好，让AWS EMR跑出结果，后面的很繁的问题都不用担心。

数据仓库也是我们一个很重要的大数据产品，在AWS的云平台上，它是一个很热门的产品。我们不同提供的数据库，比如说MySQL、Oracle、SQL Server和PostgreSQL。传统的数据存有一个查询的瓶颈，它没办法优化查询的速度，会越来越慢，这个架构是一个并行的MPP架构，很像一个扩展的集群，当节点越来越多，表示容量会越来越大，计算的资源会越来越大，查询的语言会越来越快，它完全兼容SQL。传统来讲，小公司或者中小型企业买不起一个PB级的大的数据仓库，比如说我买一个Oracle的数据库都是银行、电视企业去用，只有大型企业，有钱的人才能买数据仓库，存那么多数据做分析。对于AWS来讲，你不用担心钱的问题，因为对我们来讲，不用要求，你可以起2TB的数据就可以做，等业务增长的越来越大的时候，你再慢慢做扩容。对开发人员来讲，起一个小的数据仓库做分析，这是以前传统达不到的。

整个架构图很简单，刚刚提到数据仓库的设计就是MPP的架构，所以会有主节点跟计算节点，数据在计算节点上面，主节点是跟你的客户端，通过JDBC、ODBC做一个直接，这是节点的困难，标准的MPP的架构。目前用的BI的工具，或者任何SQL的查询工具、客户端，只要是通过JDBC、ODBC都可以接入到上面来，因为主节点拿到SQL的查询语句，可以做一些并行的优化，丢到下面的计算节点做一个分析，所以速度会比传统的关系型数据库还要快。

目前我们也提供固态硬盘SSD，觉得对查询的数据，IO吞吐量的要求很高的话，也可以用底层是固态硬盘，SSD硬盘的节点。

只要在AWS起任何的服务，大的集群都是几分钟的时间。我们的页面很简单，你就讲数据库的名字，管理员的名字做一个设定。你跟我讲你要几个节点，100个节点、200个节点，没问题，你设完以后，按鼠标一点，几分钟的时间就把一个大型的数据仓库建起来。对照以前，传统要花很久的时间采买一个大的数据仓库，然后做软件的部署。

另外一个好处是一个非常好的特点，是AWS数据仓库很好的特点，是传统的数据仓库的提供商没办法做到的，我可以做在线的实时的扩容，也就是现在假设有5个节点，现在发觉数据容量不够，或者是希望它跑的更快，想从5个变成10个，以前5个数据库的集群要先停机，停机以后再做迁移。对AWS来讲，我只要一个鼠标，你跟我讲你要变10个，我在后面帮你做一个实时的动态的扩容，前面的业务部用停，可以一直在跑，这是一个非常好的功能，非常简单。一个按纽，鼠标点一下就可以做动态的扩容。

目前来讲，可能你用的，已经在用的BI的工具，只要是标准的ODBC的界面，后面的对接都不用担心，你可以拿现在目前用的任何工具直接对接进来。一个工具并没有那么强大，每个不同的使用场景都可以用，所以Redshift是做传统的OLAP、分析、大量的交叉查询，可以用Redshift，它是结构化的数据。如果是在线的交易处理，OLAP是很小的在线处理的话，这时候要选择关系型数据库，或者是利用这些数据库。如果是非结构化或者是半结构化数据，Redshift不是结构化表格的内容，你要做一个预处理，处理完以后把重要的栏位处理完以后加载，你可以用EMR做数据的预处理，等于我们说的ETL。

基于AWS云平台上的大数据案例分享：可以看到这是我们的一个客户，从6个开发者开始，全球卖座第一的手游。SUPERCCLL是完全基于AWS做的，今天主要讲一下它的大数据解决方案，怎么在AWS上面做一个架构。他们几乎用我刚刚讲的所有的东西，用S3、长期归档、数据挖掘、数据仓库、实时采集。他们的卡通农场有那么多玩家，每天几百万的玩家在线上玩儿，他想做的是什么?他想记录每个玩家做了哪些动作，可以采了稻子，或者是买了虚拟的货币，或者是参加哪些活动，他希望这些事件流做实时的收集，玩家没点一个东西通过实时数据采集方式收集进来Kinesis的好处是不管是1000个玩家还是100万个玩家可以做一个扩展，只要做扩展都可以把这样的数据流采集回来。采集回来做一个很简单的处理，我们用Kinesis的数据程序做一个流数据的处理，这个时候用K就不用担心，你写一个简单的应用程序，做几个东西。你需要做数据的清洗，清洗完以后放到S3，让后面的工具做一个处理，另外也可以做一个实时的仪表板，可以实时看目前玩家在线的人数，或者是目前虚拟货币到底卖了多少，所以他在办公室里面可以有实时的仪表板，Kinesis可以实时看到目前游戏运营的状况，到底是好还是坏，前面的玩家在全球到底发生了什么样的状况，都可以通过Kinesis做实时的分析。

你可以做一个归档，利用Hadoop做数据挖掘，很多时候不只是做单独的游戏的指标，像DAU(留存率)这些指标，这是一个很简单的分析，我要做更深入的数据挖掘，做一些回归分析或者做一些分类，我想细化不同玩家的分类的话，还需要大数据，就是用Hadoop做比较深层的数据建模，做一个分析这要跑好几个小时的时间，所以我起一个EMR的集群做一个分析。如果做商务智能报表，多维度的分析，可以把S3的数据加载到Hadoop上面。

总结——典型游戏运营数据分析平台使用EMR+Redshift

要做这个也很简单，前面不同的日志有不同的栏位，收集进来放到S3里面，可以起一个EMR做数据的分析和处理，处理完以后再放到S3。有一个结构化的数据，做一个交叉的复杂的查询，再加入到Redshift，后面再用BI的工具。

今天非常高兴AWS在大数据平台上的解决方案，AWS其实在中国已经有很多客户在用了，大家有兴趣的话可以到我们的中文网站注册申请AWS云平台的帐号。我今天来也有一个很重要的目的，我知道很多游戏开发人员是初创企业，AWS也提供云创计划，就是希望扶植优秀的初创公司，当你申请云创计划的时候，审核通过以后，会给你提供服务。无论是中国的服务或者是中国海外的服务，我们都有一定的数量让你们使用。我们还提供其他一些售前的支持，技术的支持。也就是说，如果你要从1万到几百万、几千万的架构，我们有很多优秀的专家可以提供咨询。我们也有很强的售后技术支持团队，你参加云创计划可以得到免费的技术支持，我们也有培训的支持。如果你还不是很了解AWS，可以通过这些方式得到免费的培训资源。有兴趣的话，在一楼我们有展台，会后大家有兴趣可以来我们的展台跟我们多交流。谢谢大家!

张荣典：

大家好!

今天AWS专场安排的内容非常多，刚才听了费老师和庄老师讲了这么多的AWS服务，大家脑子里塞满了很多新技术、新概念、新名词，我这个阶段让大家休息一下，轻松一下，我们一起来做一个模拟实战。首先自我介绍一下，我是张，是AWS中国区这边的解决方案架构师，我的工作主要是帮助在座的各位，比如说当你有一些新的游戏需要发行，需要去中国海外部署，需要到全球部署的时候，我作为一个架构师会给你一些最佳实践，告诉你，你应该用什么样的服务，用什么样的架构，所以实际上今天我来讲这部分，大家认识我以后，当你有具体项目的时候可以来找我，我们可以一对一的给你一些咨询和架构。

今天我这部分会比较有特色，希望在座的各位一起互动参与一下。今天我按将的内容是基于AWS云平台游戏架构最佳实践。特色是什么?我们会假想一款多人在线游戏，我们模拟一款游戏，一起和在座的各位朋友来看一下，一起来思考，需要在座的很轻松的去思考，不是很费神的思考，一起来看这个架构怎么做。

这个游戏的名字是“武士对绝”，西方的武士对东方的武士。这是美国一个同事假想的一款游戏，并不是一款真的游戏。我介绍完了以后，在座的各位做游戏的如果你们觉得这款游戏很有创意，你可以放开的去实践这款游戏。这是一款多人在线游戏，当你登录这款游戏以后可以选择组一个战队，也可以选择加入一个战队，4：4。当你的战队选好了以后，进入这款游戏以后就可以有一个地图了，就像我们玩儿CS一样，4：4，大家可以PK了。因为主题是武士，所以你可以满场跑，可以用刀砍，用长矛去戳，甚至可以射箭，还可以射带火的箭，把你的敌人烧死。假设我们做好了这么一款游戏，这款游戏的后台怎么架构，怎么部署，怎么到全球部署发行呢?现在帮在座的各位模拟一个场景，模拟我们要做这款游戏全球部署有一些什么样的挑战。

第一个挑战：这款游戏要面向全球的用户，要对全球发行，首先准备选哪儿发行呢?北美、欧洲、中国，这三个地方都要首发。如果北美、欧洲、中国这边的用户反响比较好的话，我希望把这款游戏快速的发布到巴西、东南亚，发布到其他的一些地方。这是我们的CEO给这款游戏提出的要求。

第二个挑战：假如我们的CTO对AWS比较熟，因为他以前用过AWS，刚才我在门口跟在座的很多朋友聊的时候，他们以前都用过AWS，现在很多游戏都在AWS，你就想象你是CTO，对AWS很熟悉。CTO提出说，这款游戏要在北美、欧洲火了以后，希望这款游戏能够在一星期之内可以布到南美去，就可以布到东南亚，这是CTO的要求。

第三个挑战：每一款都有产品经理和产品制作人，我们对制作人说，既然CEO说这款游戏是面向全球，我希望这款游戏的玩儿法是全球大世界的玩儿法。什么概念?全世界的所有的玩儿家可以一起PK，一起来玩儿这款游戏。这款游戏是多人在线，是实时对战，从技术来讲要求这款游戏最重要的要素就是性能，网络的时延。当我们四个人跟另外四个人在游戏场地上跑来跑去，大家PK的时候，互相对砍的时候，如果网络时延非常大的话，我这边反应的时候对手已经在40米外了，你已经被砍死好几回了。所以游戏的开发人员说我的网络对时延要求非常好，希望所有的玩家能够控制在60毫秒以内，超过100毫秒这个游戏没法玩儿了。

第四个挑战：刚才很多朋友都提到我们公司不大，所以希望我们的成本控制的比较好，因为这款游戏发行的时候我也不知道有多少玩家，所以希望在AWS资源的时候，你的资源可以弹性的给我。也就是说，当我有10万用户的时候，我就为这10万用户买单，不需要预先买更多的资源，浪费我的钱。但是当我的用户涨了的时候，AWS的资源也会跟着弹性扩展，这是我们通常运维人员提出的要求。

刚才把假想的游戏从技术层面的四个目标给大家提出来了，CEO的要求全球部署，CTO要求一星期可以部署到全球任何一个角落，做人的要求是一款大世界的游戏，全球玩家可以PK，开发人员希望这款游戏玩家的体验能够非常好，非常流畅，希望我们的网络延时非常低。最后，运维人员要求资源可以弹性扩展。

下面大家动动脑子，第一个挑战来了，全球部署这样一个宏伟的目标。CEO说这款游戏要守法北美、欧洲、中国，我的问题是这款游戏应该部署在哪里?AWS在全球有11个数据中心，中国、澳大利亚、日本等等。这张图上显示的是全国网络时延，北美大陆的网络时延是41.7毫秒，就是从西海岸到东海岸，根据我的经验是40—60毫秒。从美国东部到欧洲，到西欧穿整个大西洋，网络的时延是79毫秒，欧洲那个地方网络时延11.6，这个是指西欧(英国、荷兰、法国、德国)。这里有一个关键的输入电，就是刚才提到的，你希望最终的游戏玩家的网络时延控制在60毫秒以内，这就是你的期望值。

CEO说要发北美、欧洲、中国，AWS全球有11个数据中心，我们希望网络时延控制在60毫秒以内，所以答案是放在欧洲的法兰克福没有问题，放在中国北京，在座的了解，使用过AWS的时候就知道我们在2013年终的时候，很多游戏都在中国部署了他们的后台，另外就是日本的东北亚。当你发行一款面向全球用户的一款游戏的时候，你可以充分利用AWS全球这11个数据中心，把你游戏的后台布在离你用户最近的地方去，确保用户的体验，确保用户的时延最小。CEO提的要求是全球部署，我们搞定了，可以跟老大说放心吧，AWS全球11个数据中心，你想布在哪儿就可以布在哪儿。

CTO提了一个要求说，我们想要在东南亚或者在南美做，他提出的要求是希望一周之内把整个系统布起来。这件事情在AWS的云平台上好搞吗?能不能实现?我跟大家一个小时就可以搞定。答案非常简单，AWS上以虚机为例，在布好的虚机可以打一个镜像，你装好、配好以后，几分钟就可以复制到另外一个区域，用那个镜像就可以跑起来。15分钟之内可以把在美西的一台虚机一模一样的搬到巴西去。实际上，CTO提的那个挑战不大，一个小时、两个小时就能搞定。

接下来看一下制作人提的那个要求，制作人提的那个要求是什么呢?制作人提的要求是全球大世界，从用户的角度来看全球任何一个地方的用户都可以相互之间PK，中国的一个玩家可以跟美国的玩家，巴西的玩家可以跟东南亚的玩家PK，这是不是一个特别终极的，非常美好的全球多人在线游戏。这个东西对我们做技术的人来讲的话是一个非常大的挑战，挑战在哪里?大家想一想。谁也不会想到一个俄罗斯人和一个巴西人，一个讲俄语，巴西人讲葡萄牙语或者是西班牙语，他们俩能对战吗?说不清楚，没法沟通。语言这个问题是整个架构的挑战之一，很难做。我跟大家说一个纯技术的挑战，技术上的最大的挑战是用户数据放在哪里?游戏后台可以放在AWS的11个区域的任何一个地方，没有问题，既然要全球对战的话，玩家的数据应该放在哪里呢?每个人还有道具、装备，点数、经验值，围绕用户所有的数据应该放在哪里呢?在座的很多是做游戏发行的，我相信你们经常会做这样一些讨论，你们会说我到底应该在某一个区域布一个符，玩家只限于在这个区域玩儿。所以我们定义一下这个问题，玩家的数据应该放在哪里?马上就有很多技术人员反映出来了，说简单，不是就近部署吗，我们可以在两个区域之间复制，从美国复制到欧洲，从欧洲复制到中国。结果我们发现这个事情完全行不同，别说两个区域之间复制的时延了，刚才看网络时延，我列出来的都会超过100毫秒，所以这个事情是行不通的。怎么办?还有人说，我觉得可以把美国的玩家放在美国，欧洲的玩家放在欧洲，他们就近访问非常快，没有问题。可是他们怎么对战呢?大家想知道答案吗，怎么解决这个问题?先给大家一个答案，我觉得这件事情是不靠谱儿的事情，这是一个伪命题，我觉得全球对战这件事情是伪命题，大家觉得是不是一个伪命题，根本不可能实现的任务。对不对?因为有几个问题，刚才那位美女一定经常玩儿游戏，说我平时肯定玩儿网络在线游戏的时候是跟中国朋友玩儿，不会跟俄罗斯人玩儿，也不会跟东南亚的人玩儿，因为语言不通，这是实际操作中的一个问题。在技术上真正的原因是网络时延在那儿摆着，所以你不可能做全球大世界。结论到这里，大家是不是很失望呢?费了这么多口舌，告诉我全球大世界，全世界玩家PK件事情根本实现不了。不是这样的，玩家想要的是什么?所谓的全球大世界这个模式大家要的是什么?其实你希望看到的是全球的好友的排行榜，对不对?你能在你登录游戏服务器的时候能够看到全球世界各地的玩家在怎么玩儿，他们的排行是什么样子，我在里面的排行是什么样子，真正玩儿的时候，你并不会跟其他群里的人玩儿，所以所谓的全球大世界是一种用户体验，是说我能看到全球的玩家，而不是真实在玩儿对战的时候，我真的在跟你对战。 即便如此，我们还是要把全球大世界，刚才我说的这个全球玩家，这个数据库这件事情进行到底。今天这个架构介绍完了以后，你们回去部署你们全球游戏服务，游戏架构的时候可以照着我这个来做，没有问题。

具体介绍架构怎么设计的时候，我们得看一下整个游戏流程是怎么走的，从玩家一开始怎么登录，最后到游戏结束，整个流程我们看完了以后再详细的介绍怎么做。今天是周末，是下午，我本来可以在家里玩儿会儿游戏，准备上武士对绝这款游戏砍砍人。这款游戏一定是端游，因为对性能要求比较高，当你登录这款游戏的时候，实际上你输入用户名和密码，这个时候这个游戏前端和后台交互的时候，通常你会用什么技术来实现?Http可不可以?用户登录的时候，一般来讲，刚刚登录的时候会下载一些最新的装备、道具、地图。通常你们做开发游戏，做后台的时候用Http也可以。你说我要选择对战，或者我要加入一个战队，用Http也是可以的。前面三步，当你开发游戏后台的时候，用户的体验网络时延控制在多少以内没有问题?10秒有没有问题?10秒稍微有点儿长。3秒是可以的，用户选择用户名登录，下载地图或者是察看好友，就像我们上网站一样，3秒钟没有问题，不是什么大事情，最好控制在1秒之内，用户感觉很流畅，登录、查看好友、查看排行榜、选择道具、选择对战，1秒钟没有问题。然后开始匹配，匹配到对战服务器上，就开始PK了，这个时候的时延1秒钟可不可以?显然是不行的，因为我们在地图里跑来跑去，我砍你一家，你射我一箭，我回你一个标枪，而且是贴身肉搏，这款实时对战的时延要控制在60毫秒以内。如果以前你们做端游出身的话，你们回忆一下，这时候从客户端到服务器端你们会用Http做吗?一定不会，他会用UDP做这件事情。开始对战的时候，跟朋友PK的时候，游戏后台整个技术对战完全不一样了，我们不能用Http协议，我们用API协议，我们用UDP协议，而且网络时延在60毫秒以内。最后，我砍死了很多人，我赢了，最后游戏结束了。结束以后就要写得了多少分，从别人身上抢了多少装备道具，后面的事情就轻松了，又可以用比较容忍的网络时延，往服务器上写得分，是不是抢到了装备、道具，又可以用1秒钟，很轻松了。刚才回顾整个游戏玩儿的过程，得出了一个什么结论呢?其实整个游戏的后台完全可以分成两部分：左边是Game API;右边叫游戏服务器。右边这个负责用户登录，查看好友列表，购买装备道具。右边的游戏服务器是说时延要控制在60毫秒以内，最好用UDP协议，TCPIP协议，所以整个系统分解成两部分以后看一下怎么完成第三个挑战(全球大世界)。整个系统的架构现在变成什么了?我们可以把API服务器放在最左边的美西的俄勒冈，其他的放游戏服务器。全球玩家在更路、购买装备、购买装备道具都可以去美西那个区域，这部分交互1秒钟你是可以接受的，用户不会因为这个事情抛弃这款游戏，是可以接受的。但是当把前面这些交互做完以后，真正进入对战以后，一定是美国的玩家跟美国的玩家连到一个堆栈服务器是在美国，南美的玩家是连在南美的服务器，东北亚的连到日本的游戏服务器，东南亚连到新加坡的服务器，澳大利亚连到澳大利亚，欧洲连到欧洲。这时候想一想，刚才问题的关键是全球大世界，所有的玩家在一个数据库里面，装备、道具在一个数据库，我们解了这个题以后，大家看一下这个结论，我们需要做数据同步，数据复制吗?根本不需要自己给自己找麻烦，在全世界同步用户玩家的数据，在一个库表里有全球的玩家，全球的旁排行榜，有全球所有玩家的装备和道具。所以，所谓的全球大世界游戏，当我们进去以后，仔细看这个游戏的流程，把整个系统结果开了以后，你会发现这个问题迎刃而解。在座的各位都可以回去布一个全球大世界的游戏，全球一个服务。

再花一点点时间，把刚才提出来的概念，一个是API Pod，一个是游戏服务器Pod。Game API Pod是用户登录、查看好友列表，一般是使用Http，还可以用Coche，最后玩儿家的数据可以放在DynamoDB。同样的道理，在游戏服务器这块儿可以全面的充分的利用AWS不同的服务和服务的特点，比如说对战服务，第一层的游戏服务器因为是实时对战，可以充分使用AWS上面一类机型，我们叫C系列，计算增强的虚机，处理能力非常强，你可以用它，为了保证游戏服务器上数据的结偶。

最后，还有一个挑战，需要大家动一动脑子。大家还记得刚才说的运维人员希望整个资源池是弹性的，当游戏的负载上来的时候，服务器会自动加，游戏负债下去的时候，服务器会自动减。游戏服务器可不可以呢?游戏服务器遇到挑战了，不是传统的Web网站的架构，可不可以做弹性的?也就是说晚上7点以后，开始玩儿这款对战游戏的玩家越来越多，我就多加对战的游戏服务器，早上玩家少了，我们就可以减一些对战服务器，可不可以?可以。但是需要在座的各位发挥你们的聪明才智，怎么做呢?非常简单。我们在后台做一个游戏对战服务器的调度程序，当我们每一个游戏服务器起来的时候，把这台游戏服务器注册到后台的匹配系统上，或者是维护后台的游戏服务器阵列的管理平台，注册上去。说我多了一台机器，我可以支持6组对战，可以交给它，你自己要开发自己弹性的扩展和收缩的业务逻辑。因为你在匹配系统那个地方，一定会维护一些信息，现在有多少玩家，有多少台对战服务器，每台对战服务器上的负载是什么样子。所以，有这样一个基础的话，你就可以添加一台服务器注册上去，对战玩家比较多的时候增加机器，在对战玩家数量降低的时候就可以调度。比如说有些服务器不再分配新的对战了，等那个玩家在上面的对战玩儿完了以后，那台机器就直接把它但掉了。游戏服务器也可以通过你的调度逻辑进行弹性的扩展和收缩，是基于AWS的API，基于AWS的一些特性来做的这个事情。

最后，跟大家分享几个案例。刚才说的这一套理论，全球大世界、游戏对战服务器的弹性、API Pod服务器的弹性，这些东西是AWS架构师虚构出来的吗?不是的。AWS很多架构的设计模式来自于我们的用户，我们作为架构师从他们那里学来的最佳实践。譬如说，Red5这款游戏，多人在线的对战游戏，做了好几年。这个FierFall就在后台就在AWS上，架构是什么样子呢?PPT上中间绿色部分是相当于APIServer Pod，布在AWS上，用过AWS的人知道，那是美国西部的俄勒冈那个数据中心，右边那一排，大家看一下EU，说明把对战游戏服务器放在了欧洲。这个架构就是全球部署，每个数据中心都有，但是API Sever就是在美国的俄勒冈。

Sony/Kill Zone这个游戏之后的系列大作都在AWS上，采用的架构一模一样，右上角的区域是全对战，数据库的标识是DynomoDB，下面的方框是遍布全球不同的区域。

PlayFab是一家做游戏发行的公司，他代理了十几家公司的游戏产品，其中有一款游戏是Loadout多人在线游戏，PlayFab发行了这款游戏，你要做发行得把系统给人布出来。PlayFab这家公司特别聪明，他自己做了一套类似于全球部署的架构，当他代理人和一个产品的时候，做发行的时候，都在这个架构框架上实现，也就是说有一个区域在中间这个地方，帮游戏开发的公司直接把游戏布到全球去。这个案例在座的某些朋友会比较感兴趣。

刚才这部分跟大家做了一个真实模拟在线游戏的实战，希望大家有一些收获，带走AWS最佳实践。这么短的时间，在座的各位不会把所有的东西都消化，希望大家跟我们保持联系，如果你要有新游戏发行，有新游戏发布找我们的销售，找我们的架构师，找我们的产品经理，我们会给你一些建议和想法，能够帮助在座的各位节省很多的人力和财力。

下面进入问答环节。

提问：

刚才讲了老板的几个要求，全球部署、快速部署，老板的第一个要求其实不是这个，影响是费用，整个开发费用跟国内其他的云计算提供商来比，同等的计算能力，同等的带宽能力下，AWS是什么样的费用水平?

张荣典：

为什么你觉得第一个问题是费用呢?做游戏的初创企业毕竟成本有限，甚至有些大公司的独立工作室都是独立核算的，大家都希望一开始的成本越少越好，这个问题提的非常好。先跟大家分享一件事情，大家有没有注意到费老师和我反复讲一个东西叫弹性，反复在讲AWS的弹性，其实我们在云平台上部署一个游戏，或者是一个应用，在座的各位在节省成本、节省费用这块儿，怎么才能节省?充分利用AWS的弹性，而不是去单独的用原来那种静态的模式思考整个系统。就像刚才费老师说的那个例子，一天之内如果从2台机器变到60台机器的话，大家可以算一下，你可以选很多家不同的服务商，有的人在中国海外选一些物理数据中心，选超级便宜的运维服务商。实际上，在AWS上，不是通过这个方式去省钱，而是通过弹性去省钱。

费良宏：

补充一下：

第一，云计算和游戏行业的关系大家非常清楚了，对于众多的游戏厂商来说，或者游戏开发者来说云应该是不二之选了，有太多的例子，因为在很多其他行业我们要介绍云计算的优势，其实对游戏业的从业者来说，这个不用太多讲，因为大家都已经从事实上得到了很多答案，或者说已经证实这一点了，所以云计算是首先要考虑的。

第二，我们提到了弹性的概念，弹性的潜台词就是按需付费，按照增长，按照你的使用量逐步制服呢的费用不用在开始初始阶段花费大量的投资。具体的个案有很多的技巧、策略，节省的方法。这是我们的很多同事的特点，就是在谈我们的产品的时候，不是想帮着把这个东西卖给你，让你花很多钱，而是先想如何帮你省钱，我们认为只要这样你们才会变成AWS最终使的客户，才会通过你们的口将AWS的优点传递给更多的同业人员。如果大家对省钱很感兴趣的话，线下咱们可以私下里好好聊一聊，有很多省钱的技巧和方法。

张荣典：

我这两年每天都会跟用户谈我们的主题就是怎么帮你省钱。

举个例子，大家知道AWS虚机上有一个类型特别特殊，比如说按小时付费用一个小时就是一个小时的费用，大家有没有听说过AWS竞价实力，这种实力就是像在拍卖市场里一样，我们可以去竞拍。一款机器正常一小时是1美金，但是在我们那个市场里竞价的时候有可能会是1毛钱，基本上是在1/10。所以很多用户把竞价实力用的很熟的时候，就去用竞价实力，这样的话你的成本就减少了90%。

再举个例子，我们的客户经理跟你聊的时候，经常会说你买一个预留实力，一年的预留实力三年的预留实力，很可能让你减少30—40%的成本。这只是竞价实力和预留实力，如果大家想省更多的钱，大家可以跟我聊一聊，我还有很多技术的方法可以帮大家省钱。

费良宏：

非常感谢大家利用宝贵的时间听我们介绍今天的内容。非常感谢大家!

站住~游戏爱好者！我强烈建议你下个好游快爆APP。APP里有丰富的攻略秘籍，还有时下热门的爆款新游和实用工具，动起你的手指，与志同道合的朋友一起玩这个好玩的APP吧，快快快！