• 云计算弹性

    2019-05-03 00:49:57
    云计算最大的优势就在于弹性。目前,阿里云已拥有在数分钟内开出一家中型互联网公司所需要的IT资源的能力,这就能够保证大部分企业在云上所构建的业务都能够承受巨大的业务量压力。 计算弹性 纵向的弹性,即单个...

    云计算最大的优势就在于弹性。目前,阿里云已拥有在数分钟内开出一家中型互联网公司所需要的IT资源的能力,这就能够保证大部分企业在云上所构建的业务都能够承受巨大的业务量压力。

    计算弹性

    纵向的弹性,即单个服务器的配置变更。传统IDC模式下,很难做到对单个服务器进行变更配置。而对于阿里云,当您购买了云服务器或者存储的容量后,可以根据业务量的增长或者减少自由变更自己的配置。关于纵向弹性的具体应用,详情请参考升降配

    横向的弹性。对于游戏应用或直播平台出现的高峰期,若在传统的IDC模式下,您根本无法立即准备资源;而云计算却可以使用弹性的方式帮助客户度过这样的高峰。当业务高峰消失时,您可以将多余的资源释放掉,以减少业务成本的开支。利用横向的扩展和缩减,配合阿里云的弹性伸缩,完全可以做到定时定量的伸缩,或者按照业务的负载进行伸缩。关于横向弹性的具体应用,详情请参考弹性伸缩

    存储弹性

    阿里云拥有很强的存储弹性。当存储量增多时,对于传统的IDC方案,您只能不断去增加服务器,而这样扩展的服务器数量是有限的。在云计算模式下,将为您提供海量的存储,当您需要时可以直接购买,为存储提供最大保障。关于存储弹性的具体应用,详情请参考磁盘扩容

    网络弹性

    云上的网络也具有非常大的灵活性。只要您购买了阿里云的专有网络,那么所有的网络配置与线下IDC机房配置可以是完全相同的,并且可以拥有更多的可能性。可以实现各个机房之间的互联互通,各个机房之间的安全域隔离,对于专有网络内所有的网络配置和规划都会非常灵活。关于网络弹性的具体应用,详情请参考专有网络

    总之,对于阿里云的弹性而言,是计算的弹性、存储的弹性、网络的弹性以及您对于业务架构重新规划的弹性。您可以使用任意方式去组合自己的业务,阿里云都能够满足您的需求。


    本文转自 baishuchao 51CTO博客,原文链接:http://blog.51cto.com/baishuchao/1930859


    展开全文
  • 云计算弹性伸缩

    2019-04-11 21:02:02
    案例1: 2009年,第一次淘宝双十一活动,每秒订单只有400笔,支付达到极限每秒200笔。 2015年淘宝双十一,每秒订单创建24万笔,支付达到了每秒18.59万笔。 每秒订单提升了350倍,支付能力提升了430倍。...

    案例1:
    2009年,第一次淘宝双十一活动,每秒订单只有400笔,支付达到极限每秒200笔。
    2015年淘宝双十一,每秒订单创建24万笔,支付达到了每秒18.59万笔。
    每秒订单提升了350倍,支付能力提升了430倍。从后台来看,每年淘宝在双十一这个时候,后台服务器的数量都要比平时运维要多三到四倍。来保障双十一活动,双十一活动结束后,假如不做处理,这批机器的利用率将大大降低,直到次年的双十一活动。
    案例2:
    2016年除夕之夜“咻一咻”抢红包,全民参与3245亿次,最高峰值每分钟210亿次。每秒3.5亿次峰值。当活动结束后,后台大量的服务器将会处于限制的状态。

    如上述案例,这些闲置机器怎么处理,怎么回收,次年活动开始时,服务器如何分配,这是一个大问题。

    还有其他场景,比如视频直播公司,无法预估业务负载情况,需要根据CPU利用率,load、贷款利用率、自动线性伸缩。如游戏公司,每天中午12点,每天晚上6点到九点,这时候处于业务高峰期,需要定时扩容。
    弹性伸缩介绍:
    弹性伸缩是更具用户的业务需求和策略,自动调整其弹性计算资源的管理服务
    在这里插入图片描述
    弹性伸缩产品特点:
    随需应变——根据需求“恰到好处”的分配资源,无需担心需求预测的准确性,无需担心突增的业务变化
    自动化——无需人工干预,自动创建和释放ESC实例。自动配置负载均衡SLB
    伸缩模式丰富——多模式兼容,课同时配置定时、动态、自定义、健康模式。
    智能——智能调节应对各种复杂场景,根据设定策略自动调整弹性资源。

    伸缩模式:

    1. 定时模式,固定时间增加或减少ECS
    2. 动态模式 ,根据CPU、带宽、等资源使用率增加减少ECS
    3. 固定数量模式,手动添加
    4. 健康模式,将不健康的服务器移除,加入健康的服务器
    5. 自定义模式。
    6. 多模式并行

    阿里云的弹性伸缩方案
    伸缩组创建
    伸缩组是具有相同应用场景的ECS实例的集合,伸缩组定义了组内ECS实例数的最大值、最小值及其相关的SLB实例和RDS实例等属性。

    弹性伸缩一定要搭配SLB、云监控、RDS才能使用吗? 答案是否定的

    冷却时间


    在这里插入图片描述
    伸缩组——

    移出策略

    在这里插入图片描述

    伸缩配置

    ——创建
    在这里插入图片描述

    伸缩规则

    ——创建
    在这里插入图片描述
    如果伸缩规则的执行会照成伸缩组的ECS实例数低于MinSIze或高于MaxSize时,
    则ESS会自动调整需要加入或移除的ECS实例数,使之按照“将伸缩组的实例数调整到minSize”或调整到MAXsize。

    流程在这里插入图片描述

    定时任务

    每个用户最多能创建二十个定时任务
    在这里插入图片描述

    自动扩展流程
    在这里插入图片描述

    展开全文
  • 一、什么是弹性扩展  弹性扩展最早是亚马逊提出的概念,弹性扩展针对的是云应用本身的一种动态的扩展,在云应用运行期间实现支撑云应用的虚拟机实例个数的动态增加或者减少,通俗点就是在负载较高的时候启动较多的...

    一、什么是弹性扩展

      弹性扩展最早是亚马逊提出的概念,弹性扩展针对的是云应用本身的一种动态的扩展,在云应用运行期间实现支撑云应用的虚拟机实例个数的动态增加或者减少,通俗点就是在负载较高的时候启动较多的实例,负载较低的情况停止一些实例。弹性扩展为云应用实现了真正意义上的资源按需分配。弹性扩展并不是简简单单的凭空复制,对于应用服务来说,增加服务器个数只是增加资源计算能力,还需要传统意义上的“集群”技术将它联合成一个整体对外提供服务。对于IaaS来说,它不会因为特殊的业务规则对应用进行限制,导致应用做相应的更改,这违背了它产生的本意,它更多的是关注整体行为,无论什么应用都可以在其运行,并享受它一致各种服务。由此可见弹性扩展中对应用部署所需的虚拟机是预先创建的,并由应用实施者通过内网组建一个集群,这些虚拟机放入到一个pool中,按照策略进行启动所需的虚拟机实例,说白了IaaS管理服务只关注池里面有多少虚拟机,然后按策略停止或者启动这些虚拟机。

      二、弹性扩展实现

      首先云用户通过管理portal,可以定义一个pool,将需要实现弹性扩展的虚拟机加入到pool,原则上是一个应用对应一个pool,并设置弹性扩展策略,主要是IaaS管理服务调度算法涉及的参数有关,如下所示:

      Pool max size:这与云用户加入的虚拟机个数有关;

      Pool min size:该值缺省为1,表示最小运行情况下的虚拟机个数;

      High load limit:表示整体运行负载超过该值时,就需要投运新虚拟机;

      Lower load limit:表示整体运行负载低于该值时,就需要停运虚拟机,将虚拟机放入到闲置的pool中。

      Step start count:该值缺省为1,表示每次投运的个数

      Step stop count: 该值缺省为1,表示每次停运的个数

      然后对于云用户来说还需要一个动态监控的界面,监控该pool动态变化。

      对于IaaS平台来说要实现弹性扩展,首先要实现性能监控模块,对池中的投运的虚拟机进行性能监控,根据监控数据,实时的cpu利用率计算整体运行负载,然后按策略进行调度。下面我讲详细的讲解弹性扩展算法。

      三、 弹性扩展算法

      假设前提:

      闲置池:freePool={V1,V2,……}

      投运池:usedPool={…}

      池中虚拟机:V1,V2,……

      物理机:P1,P2,……,Pn

      按照物理机性能设置每个物理机权值:LD1,LD2,……,LDn

      平均化计算周期:T

      High load limit:HLL

      Lower load limit:LLL

      弹性计算资源调度周期:T1

      算法描述:

      1、 平均法去掉瞬时尖峰值计算所有物理机,以及虚拟机某段时长的平均cpu利用率;

      注:平均法要防止因为瞬时峰值引起云计算内部频繁调度,导致云计算内部的“颤动”

      计算方式如下:每个资源(物理机或者虚拟机)拥有一个队列,保存T周期的m个性能数据,每次新的监控数据cpu利用率进入后,将最久的监控数据移出,将新数据加入到队列里,计算队列中剩余值,计算公式如下:资源负载=(SUMi-1+DATAnew-DATAlast)/m;

      注:如果队列中没有保存一个T周期的数据不做计算,不列入本次计算范围内。

      2、 计算所有投运虚拟机的实际占有负载:

      计算方式:虚拟机的性能监控数据代表的相对计算能力,因此需要通过物理机性能数据折算成绝对的负载值,计算公式如下:

      其中Vcpu表示虚拟创建时cpu个数;

      表示虚拟机相对负载;

      该计算公式表示该物理机上运行m个虚拟机

      3、 选择一个需要调度的pool,综合虚拟机负载计算整个投运的所用虚拟机平均负载:

      其计算公式如下:

      m表示该pool中已投运的虚拟机个数。

      4、 计算该pool中是否需要投运或者停运:

      n Pool整体负载〉HLL,表示需要投运新的虚拟机,从free pool中选择Step start count个虚拟加入到待启动队列中,如果free pool中虚拟机个数不足,则将剩余的全部取出。

      n Pool整体负载

      如果Pool中虚拟机个数-Step stop count>=Pool min size,则从used pool中选择Step stop count个负载最低的虚拟机加入到待停止队列中;

      如果Pool中虚拟机个数-Step stop count

      n 否则:该虚拟机不做任何调度

      5、 从待启动中依次启动虚拟机或则从待停止队列中依次停止虚拟机,并清除pool中所有虚拟机T1周期的数据,防止该pool在T1周期不被再次调度。

      6、 依次从poollist取一个pool,按照3-5进行操作。

      算法其他说明:

      该算法只关注对于pool需要启动多少个虚拟机,在理论上虚拟机多少代表其应用在IaaS上占有的计算能力,从而改善应用性能,并使应用按需被分配资源。但实际资源分配还包含了很多因素,例如物理机资源群还剩余多少计算资源,资源利用是否被均分到各个物理机上(这个需要资源均衡的智能迁移进行支撑)。

     

    展开全文
  •  不过归根结底,云计算的理念还是“让用户像用水用电那样使用计算资源,按需获取,按量计费”——以服务的方式提供计算资源——因为用户的计算需求是弹性的,因此真正弹性云计算,才会帮助用户最大限度地降低计算...
    这些年,云计算从概念逐步发展到大势,又从大势逐步落地。这个“落地”的过程,又被公有云、私有云、混合云等等概念演绎得五花八门。
      
      不过归根结底,云计算的理念还是“让用户像用水用电那样使用计算资源,按需获取,按量计费”——以服务的方式提供计算资源——因为用户的计算需求是弹性的,因此真正弹性的云计算,才会帮助用户最大限度地降低计算资源的总体拥有和使用成本。
      
      弹性究竟意味着什么?
      
      什么是弹性?首先,整合计算资源,将计算资源池化,通过虚拟机按需使用计算资源;其次,按量计费,让用户能够根据使用量按月按时甚至按秒来进行付费。
      
      不过,光有了这两条还不够。为什么?我举个例子:
      
      很多做运维的朋友都深有体会,比如因为一个系统的警告,你就得立即去调度更多的资源,哪怕是深更半夜也得爬起来。
      
      应对的解决方案有很多种,比如加大冗余,让计算资源不至于因为突发性的访问量激增或计算负载的激增而宕机。但是,这样做就和传统的物理机区别不大了。因为云计算的核心优势之一就是客户弹性适应计算需求的变化。
      
      为什么云计算最早是亚马逊做出来的,而不是IBM、惠普、Oracle、SAP这些IT巨头?就是因为亚马逊为了应对圣诞节网上购物需求的激增,不得不一再扩容其数据中心,而除了圣诞节、感恩节这些购物高峰季节,平时的购物请求仅仅是峰值的1/5,大量闲置的计算资源不得不让亚马逊思考是否能够将其出租给其他零散计算中心级需求的中小企业。
      
      如果仅仅是满足零散需求的用户,其实前两个弹性也就足够了。但关键是,亚马逊需要对自己的弹性计算需求进行近乎实时的加载和释放,这样才能完全清楚能够有多少计算资源进行出租。于是,亚马逊开发了自动伸缩(AutoScaling)功能,不过这一功能主要是针对主机,毕竟,满足亚马逊自身的需求是第一位的。
      
      或许亚马逊当初开发这一功能的架构师是因为离职还是什么别的原因,没有将自动伸缩功能延伸到更多领域,我们不得而知。但公有云提供商如果不是对这一功能有着深刻理解,真正为弹性的用户需求,减轻用户的运维负担,或许连主机的AutoScaling也不会做。即便做了,如果只是照搬,创新也就无从谈起,譬如阿里。
      
      不止是AutoScaling?
      
      笔者认同“一个做了15年的运维老兵对公有云的深度剖析”那篇文章里所阐述的观点:“青云之后,再难有大的创新,IaaS的创业门槛一下就提高了很多,甚至可以说大门都快关上了。”
      
      很显然,在公有云基础架构层面最具创新精神的创业公司当属青云。这次也不例外——事实上,与其他云服务商推出的有限的自动伸缩功能不同,青云QingCloud的AutoScaling能够自动调整所有基于QingCloud之上的云资源,包括IP带宽、数据库存储空间、负载均衡器的后端数量等一切可以监控到的数据。
      
      应该说,青云的做法大大拓展了我们作为普通用户的视野。为此,笔者专门采访了青云AutoScaling的开发者罗夕(Simon Luo)。他解释说,用户在公有云上建个账户,然后把物理资源搬到云上,需要部署资源,或者新添一些业务,也要对主机、存储和网络资源进行部署。除了部署之外,对于互联网企业来说,更重要的是接下来的监控,让系统资源能够满足访问量的变化。
      
      其实,互联网企业不止是亚马逊这样的电商,在各种大促,特别是圣诞、感恩节、双十一这些时期,可以预见访问量激增的情况,提前做出充足冗余。举个例子,就在三个月前,App“足记”突然席卷朋友圈,有点像去年的疯狂猜图、魔漫相机、脸萌这类的App,访问量突然呈爆发式增长——最高峰每天PV过亿,每天新增用户上百万!结果呢,足记宕机了——一周7天有4天宕机,除了一再跟用户道歉,只能向云计算服务商发出求救信号。
      
      这种情况下,一个好的足够弹性的架构当然非常关键,比如业务层面的扩展、网络层面的扩展、数据层面的扩展等等,其中也包括比如自动伸缩(AutoScaling)和定时器(Scheduler)这类自动化运维工具的合理使用,至少可以在一定程度上,为工程师人工介入进行紧急处理提供相对充足的修复时间。
      
      比如有了自动伸缩功能,并且有监控告警服务做支撑,可以给负载均衡器后面扩充更多的主机、调高带宽;当然也可以做下调,就是在访问量长期处于低谷的时候,可以自动减少资源,调低带宽,这带来得好处就是成本降低。而且不管上调、下调都不需要人为的参与,所以在人力成本上也会有一定的节省。
      
      据罗夕介绍,AutoScaling可以动态地调节用户的访问压力,调节有两个方向,一是扩大或者上调,给负载均衡器后面扩充更多的主机、调高带宽;二是也可以下调,在访问量长期处于低谷的时候,可以自动减少资源,调低带宽——这样带来的好处一是占有资源更合理,资源占用成本降低;二是不需要人为过多参与,节省人力成本,让企业将运维人员的大部分精力放到业务发展上面。
      
      值得一提的是,青云AutoScaling是免费的工具,而且执行是基于脚本的,目前QingCloud会自动帮助用户生成脚本,并且可以在控制台浏览。未来QingCloud还会开放脚本的编辑功能,让用户可以通过编写脚本的形式自定义操作行为,满足更复杂、更个性化的需求。
      
      青云的“弹性”RoadMap
      
      当然,青云能够开发超越亚马逊跟阿里的AutoScaling,除了执着于云计算的“弹性”理念之外,还在于其扎实的基础。
      
      据罗夕介绍,青云最底层的Collection是监控数据采集服务,它会采集主机的监控,也会采集流量的监控,每层都是上一层的基础,采集完之后会把它收集起来。而AutoScaling是基于Alarm监控告警做的触发,Alarm则是从Collection里面读取数据。这样一个基础,使得AutoScaling在执行的时候利用青云开放的API和已开发的很多项功能,最终实现对青云所有资源的AutoScaling。
      
      在青云的RoadMap里,目前服务器、存储、网络、安全这四大IaaS层的拼图已经基本完整,包括主机的映像、硬盘、内网DNS等,后续还会持续进行优化,以及针对私有云一些特殊的要求,进行功能的补充。实际上,今年青云的重点是放在了所谓的Technical PaaS层面——比如AutoScaling和Scheduler。
      
      这两个功能当然很重要,因为他们可以大大减轻传统IT运维日常重复的工作。但更为重要的是,像AutoScaling会进一步助力青云后续推出的Technical PaaS,比如对象存储,和之后的大数据分析服务。
      
      “像对象存储和大数据分析,它们本身都是一些集群服务,这些服务本身就有弹性伸缩的需求,我们研发的同事就可以直接在AutoScaling的基础上满足他们服务的弹性。”罗夕解释说。
      
      很明显,青云的产品路线从一开始就在刻意减少资源浪费,并且规避弯路,这无疑是聪明人的做法,前提是,你要对云计算构建有着极为深刻的洞察和理解。在笔者看来,这也是为什么青云能够以最为精炼的人力资源,打造国内最为创新的云计算平台的重要原因之一。
    展开全文
  • 云计算从几年前的概念炒作到今天各种公私有云的蓬勃发展,越来越多的用户开始接触并尝试将云作为业务运营的载体,已有不少敢于尝鲜的用户体验了云计算所带来的灵活性和成本优势。我自己也从最初对云的模糊认识到尝鲜...

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


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


    游戏云间之一:弹性扩展


    说到云计算,大家听到的最多的两个优点就是: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台,随着用户升级的完成,再逐个关闭更新服务器,这些通过云平台的弹性扩展很方便的就能实现。


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


    (接下去会逐个探讨游戏领域的网络、运维、安全、服务等在云平台上的特点和架构。时间仓促,如有不当之处还请大家提出,也欢迎大家对游戏系统、软件架构及技术细节进行探讨。)


    展开全文
  • 弹性云计算的一个基本特性,关于弹性描述最准确的是? A 能够快速的通知你云资源的使用限制,你可以快速手动修复 B 在造成最低的影响情况下,能够快速的将云资源扩展与收缩 C 可以快速创建所需服务,而不需要...
  • 弹性计算云EC2主要特性 灵活性:EC2允许用户对运行实例类型、数量自行配置,还可以选择实例运行的地理位置,根据用户的需求随时改变实例的使用数量  低成本:EC2使得企业不必为暂时的业务增长而购买额外的服务器...
  •  弹性云计算其实就是云计算的一种,它与云计算唯一的区别就是可弹性扩展的资源用量,为客户业务在高峰期的顺畅保驾护航。此外,它还有灵活多样的计费方式,较为特别的的就是用户只需要为所使用的资源付费,运行结束...
  • EC2系统中包含多个地理区域,而每个地理区域中又包含多个可用区域。为了确保系统的稳定性,用户最好将自己的多个实例分布在不同的可用区域和地理区域中。
  • 摘要:很多用户非常想了解云计算弹性体现在哪些方面?本文中云计算布道师倪波(花名:竹雾)就为大家进行答疑解惑,谈一谈云计算所提供的计算、存储以及网络方面的弹性。 想要看视频版?请点击这里:【知云】...
  • 什么是云服务器的弹性伸缩?弹性伸缩(Auto Scaling)根据您的业务需求和伸缩策略,为您自动调整计算资源。您可设置定时、周期或监控策略,恰到好处地增加或减少实例,并...
  • 现如今,云计算已成为IT领域标配,甚至有趋势作为基础服务成为未来IT领域的水和电。当业务规模蓬勃增长,面对数以万计的请求量,庞大的业务流量,高并发的数据访问量,仅靠人工看守,时刻准备着当“救火员”,哪儿有...
  • 1、Amazon Web Services - Amazon的云计算服务 2、Simple Storage Service - S3简单的存储服务 3、Elastic Compute Cloud - EC2,弹性可扩展的云计算服务器 4、Simple Queuing Service - 一种...
  • 云计算的五大特征

    2018-11-23 09:06:38
    但是云计算和网格计算等传统的分布式计算也有着较明显的区别:首先云计算弹性的,即云计算能根据工作负载大小动态分配资源,而部署于云计算平台上的应用需要适应资源的变化,并能根据变化做出响应,其次,相对于...
  • All things are difficult before they are easy.
  • 购买是不用担心后续业务的扩展,因为云计算弹性大,随时可以升级服务器配置,避免前期选购配置高造成资源的浪费。曾经有人在一个小时里面租用几百台服务器来进行数据处理。当然,他只需要支付1个小时...
  • 感受云计算,从弹性计算开始 作者: baiyuzhong分类:CTO视点, 云计算 阅读:1,006 次添加评论 文 / 刘江 说起弹性计算,相信没有人怀疑亚马逊EC2(Elastic Compute Cloud)是目前的业界翘楚:...
  • 此方案优势:阿里云结合云计算弹性计算的特点以及自己在互联网上的成功经验,规划了一整套完善的软件负载均衡解决方案,能更好的满足弹性计算平台负载均衡的需求,成功的解决了硬件负载均衡在达到性能上限后扩展性...
1 2 3 4 5 ... 20
收藏数 24,151
精华内容 9,660