游戏云间之一 : 弹性扩展-低调大师

游戏云间之一 : 弹性扩展

2016-11-16 786

前言

云计算从几年前的概念炒作到今天各种公私有云的蓬勃发展，越来越多的用户开始接触并尝试将云作为业务运营的载体，已有不少敢于尝鲜的用户体验了云计算所带来的灵活性和成本优势。我自己也从最初对云的模糊认识到尝鲜，再到大规模的使用云平台，有很多感触，云计算技术和平台目前也处于逐步完善和稳定中，因此把一些见解写出来供参考，同时也想和大家一起探讨如何利用云计算技术更好的提升游戏开发和运营质量。

对于游戏行业来说，私有云由于其封闭性且目前并没有成熟的标准化方案，除了个别高大上的端游开发或者运营商可能会用，对大多数游戏公司并不适用，抛开成本和技术门槛不讲，就目前互联网时代的游戏行业丰富多变的特点，私有云有着很大的局限性。其实不论什么云，在底层技术上是相似的，但是由于国内对于数据中心和网络方面的政策限制，也导致了私有云的种种局限性。本系列将从开发到运维等多个角度探讨云计算技术特别是公有云平台的特点以及一些技术架构。欢迎大家踊跃讨论，分享游戏领域的云技术经验！

游戏云间之一：弹性扩展

说到云计算，大家听到的最多的两个优点就是：1. 成本优势 2. 灵活或者说叫弹性扩展。
成本问题涉及到的因素比较多，我们暂时不去讨论，先谈谈云的灵活性(弹性扩展)。那么什么是弹性扩展呢？有点像我们用自来水，用多少就开多少，按使用量付钱；而不是像以前，吃水要先计算人数，然后做规划去挖几口井打水。对于游戏开发和运营来说，云计算就像自来水，在游戏生命周期的不同阶段对于网络、计算、存储等资源的需求都不一样而且是频发变化的。在端游时代，这些都可以基于经验被准确估算，包括用户量的曲线都是可以被预测的，但是到移动互联网时代呢？游戏领域的特点是：快速开发，用户爆发量大，生命周期短。

比如去年流行的疯狂猜图游戏，刚上线就以迅雷不及掩耳之势疯狂传播，每天新增用户数超过30万，用户量的爆发是难以预料的。而现在很多游戏的开发时间也很短，特别是页游、手游等，短则几个礼拜，长也不过几个月，由于国内玩家的特点以及游戏的可玩性等因素，很多游戏的生命周期都基本在1-2年左右，用户量的爆发也基本是在游戏面市的最初一段时间里，所以整个游戏IT系统的架构都是从突增的爆发到平稳再到逐渐缩减。

想想一下没有云计算的传统做法吧，我们要先做用户数预测，然后估算同时在线的用户量及IT资源消耗情况，随着游戏推广的广告宣传，用户数迅速增加至100万，没有问题，因为两个月前我们已经把游戏服务器部署好了。可是移动互联网时代的游戏用户数预测是很难的，除了游戏本身的可玩性，很多外部因素也会对用户数有较大影响，比如流行趋势、国家政策、公共事件等。比如前一段流行的flappy bird游戏，开发时我想没有人会想到这个游戏会火到爆棚，还好这只是个单机游戏，如果换做是网游，那么传统的预先部署服务器的做法可能面临状况就是，要么是用户数不足而导致IT资源闲置，要么是用户数激增导致短时间（一两周内）服务器已经满负荷运转，即便是游戏运营反应很快，马上去采购，下单，部署，调试，至少两周时间过去了，而这两周正是决定游戏命运的关键时刻，在这两周内的任何宕机、访问延迟等事件都会导致用户的流失，并且再也不会回来。

那有了云计算会是什么样呢？
在开发阶段，只需购买几台够用的低配置云主机即可；在内测和公测阶段，根据云主机负载适量增加新的服务器；在游戏正式上线的推广阶段，可以随时根据用户数的增长和服务器负载随时调配资源，根据激增的用户量，按需扩充机器；而在游戏生命周期的后半段，随着用户量的下降，逐渐关闭一些云主机，确保在用的云主机一直保持在忙碌状态；甚至可以做到在玩游戏的高峰期比如晚上7-12点，或者城战等大访问量时间段，增加云主机或者带宽量，而在访问量低的时间段减少相应资源。

这种想法是不是很美好？确实很好，但是，硬件或者说虚拟IT资源是可以弹性扩展的，游戏软件本身如何实现弹性扩展呢？怎么能保证增加服务器后，游戏软件也可以随之扩展，并且扩容必须是在线的，对已有系统不能有任何影响呢？
自行开发分布式的游戏软件架构是一种方式，但是技术门槛太高，并且想要做的稳定和完善还是需要不小的投入。
由于游戏程序的逻辑是一样的，不管是分区还是分服，无非是数据不同。那么目前最常见的做法就是利用负载均衡设备来实现弹性扩展。负载均衡是做什么用的呢？就是对外表现出同一个IP或者访问入口，对内实际上对应多台服务器。负载均衡设备有这么几个作用：1. 轮询后端的服务器的负载，将请求分发至合理的服务器上，确保服务器的load是平均的 2. 确保业务连续性，在某一个或者几个服务器发生故障时，请求只会被转发至健康的服务器，这一点也可以用来避免game服务器的单点失败或者实现灾备功能。
那么负载均衡要怎么实现呢，可以利用开源软件自行实现，如果是使用云服务，那么国外如amazon的ELB，国内如阿里云的SLB等，有兴趣的可以google之.

有了负载均衡，就有了弹性扩展的基础，既然负载均衡后的game server都是对等的，那么在访问量增加的情况下，安装配置好一台新的game server，将其加入到负载均衡设备后面，整个系统就无缝的扩容了。那么就有同学会问，安装配置似乎也没那么容易吧，如果是传统的物理服务器，确实，至少也得需要个光盘装机吧，如果是云主机呢？有镜像就可以了，所谓镜像就有点像在pc机上的iso或者虚拟机的vmdk文件，将原有的game server 系统、软件、配置整个做一个镜像，在增加新的云主机时，直接从镜像创建，没有任何安装配置过程，新的game server分分钟就启动好了，如果通过API操作，算上启动时间，整个过程10分钟以内就可以搞定了，是不是很快？而随着云计算平台的完善，弹性扩展将来也会变成一种服务，也就是说你只需要设定策略，比如在所有服务器负载超过90%时新增服务器，当服务器负载低于60%时，释放云主机，整个系统就变得非常灵活，不用再为突增的用户量发愁了。

可能就会有同学问，负载均衡后的game server确实解决了计算层面的弹性，那么数据怎么办，如果我的数据容量或者访问出现瓶颈了如何弹性扩展？说到数据，我们就先讲下存储的问题，云存储早已是大家耳熟能详的，存储的云化是比较容易做的，因此存储这一层的虚拟化早已完成，很多云存储宣称空间无限，当然存储速度也是很重要的衡量因素。那么数据库呢，如何避免单一数据库服务器造成的瓶颈，熟悉mysql的同学应该都知道分库分表，在大规模数据量和访问量的数据库中，按照一定的规则将数据库压力分摊至多个数据库实例，比如按用户id等等，网上类似的资料很多，目前分库分表的工作还是需要自己规划。据了解有的云平台已经准备推出分布式的数据库服务，也就是说对外(应用层）看到的是一个数据库，实际上底层对应多个数据库实例。分库分表、负载分摊等都由云系统自动完成。如果这项服务推出，那数据层面的弹性话将变得非常容易，只需根据游戏数据量或访问量增减则自动调整数据库规模，这一切都会变得非常灵活和智能。这个功能将是非常激动人心的，让我们拭目以待看哪个云平台能率先推出这种分布式数据库服务。

再来简单说说带宽问题(后续会进一步讨论），很多游戏运营的苦恼是带宽，对很多游戏来说带宽是重中之重。既然是云，带宽的弹性增减就更是必不可少了，而云平台通过API可以立即调整带宽，这比IDC托管或者自建服务器带宽扩容方便的太多，云平台的带宽完全可以自由掌控，甚至自动化。

大掌门这个游戏大家都知道，用户量和收入在业内遥遥领先，可以说这个游戏的成功是离不开对于云平台的利用，正是有了云计算的各种弹性，才能很好地应对用户量的激增，同时系统的稳定性也得到了保证。再举一个小例子，就是游戏更新服务器的使用，更新服务器只有在游戏发布升级包时才需要，并且会在升级包发布时会有一个非常巨大的访问量，如果只有一台更新服务器，客户端更新的压力吃不消，用户体验会变差，那么在升级包发布时，在云平台上临时部署多台更新服务器，比如5台，随着用户升级的完成，再逐个关闭更新服务器，这些通过云平台的弹性扩展很方便的就能实现。

因此从游戏开发、推广、稳定器、衰落等各个阶段，云平台可以像自来水一样即开即用，按需使用，按用量支付费用。而能也能保证在游戏开发和运营的各个阶段的效率和资源利用率都能得到极大的提高。

微信关注我们

原文链接：https://yq.aliyun.com/articles/64368

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

openstack4j接口调试

//import java.util.List;////import org.openstack4j.api.OSClient.OSClientV3;//import org.openstack4j.openstack.OSFactory;//import org.openstack4j.model.common.Identifier;//import org.openstack4j.model.compute.Flavor;//import org.openstack4j.model.identity.v3.Project;//import org.openstack4j.model.identity.v3.User;////public class openstack {// public static void main(String[] args) {// OSClientV3 os=OSFactory.builderV3()// .endpoint("http://ahwater-cloud-controller:35357/v3")// .cr...

2016-11-16

705

目录目录 Keystone 认证流程让 Keystone 为一个新的项目 Service 提供验证功能最后 Keystone 认证流程 User 使用凭证(username/password) 到 keystone 验证并获得一个临时的 Token 和 Generic catalog(全局目录)，临时的 Token 会存储在 keystone-client(cache UUID locally) 和 keystone-backend 中。 User 使用这个临时 Token 发送给 keystone 并获得一个该 User 能访问的 Tenants 列表 User 再跟 keystone 发送一个请求，表明希望访问的 Tenants keystone 就会向 User 发送一个管理这个 Tenants 的 Services 列表和允许访问这个 Tenants 的 Token (Tenants Token) User 会通过这个 Services 和 Generic catalog(全局目录) 映射找到 Services 的 endpoint，并通过 endpoint 找到实际 S...

2016-11-16

675

资源下载

更多资源

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长，特征是大鼻子、头戴帽子、身穿背带裤，还留着胡子。与他的双胞胎兄弟路易基一起，长年担任任天堂的招牌角色。

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。

优质分享App

近一个月的开发和优化，本站点的第一个app全新上线。该app采用极致压缩，本体才4.36MB。系统里面做了大量数据访问、缓存优化。方便用户在手机上查看文章。后续会推出HarmonyOS的适配版本。