PaaS 调研 : GAE 与 AWS (下)

PaaS 调研:GAE与 AWS(上)

AWS

应用场景

按理说,AWS应该不算PaaS,而应该算IaaS。那为什么会放在这里说,其实主要有两个原因:一是AWS并不是很简单的IaaS,因为它提供了大量的配套管理服务,虽然这些服务大多数都是通过Restful API的形式提供,但确实是可以编程来调用的;二是AWS本身也一个很有特色的“可编程”服务:Lambda服务。这个服务是可以嵌入在它提供的各种服务中,提供用户自定义控制这些配套服务的能力,所以让这些服务看起来更像平台PaaS,而脱离单纯的IaaS。从嵌入Lambda的角度来看,AWS比GAE更加的激进,而不是遵循传统的Web服务存在,因此能被更广泛的互联网业务所使用,而不仅仅是互联网电商客户。据说最近一些在Steam上很火的新游戏,都有用到AWS的服务,包括Lambda。

开发支持

AWS因为核心是围绕其IaaS服务器EC2来设计的,所以并没有所谓的开发框架。而更多是针对EC2提供的各种透明的、基于网络的优化功能。比如AutoScaling,就是基于使用时间、负载情况,对EC2实例进行伸缩,这里补充一点,EC2的虚拟机也是支持Docker技术的,所以能比较方便的启动、迁移。而另外一个叫ELB的服务,则是比较传统的类似L5的负载均衡器。

能够真正对AWS“编程”的,就是他们的Lambda服务。你可以多种语言来编程,包括 Node.js/Java/C#/Python ,来编写一些触发器产生的事件处理回调。在AWS的各种服务中,有很多服务都支持Lambda,如S3/DynamoDB/Kinesis,这些服务在收到请求,或者发生状态变化的时候,都会触发很多不同种类的事件,从而调用用户自定义的这些代码。比如对象存储S3收到数据的时候,就会触发代码。这个功能就能很方便的用来做游戏的存档和读档。又或者数据库服务DynamoDB在对数据进行Put或者Get操作的时候,也可以触发你的代码。当然,像Kinesis这种流式计算服务,本身就是需要用户代码来做离线的统计或数据处理的。

把用户代码嵌入到服务当中,而不是提供一个用户代码的服务容器,这个设计也许是需要服务IaaS而产生的。但这种灵活的设计,也把使用者从“标准开发框架”中解放出来,作为服务提供者,也无需像Google那样提供各种语言和五花八门的WEB编程框架。由于游戏服务器端一般的通信模型和Web相去很远,有大量的主动通知,以及在线数据反馈的需求,所以使用Web那套框架肯定是不能满足需求的,但好像AWS这种,游戏客户就可以自己写一个简单功能的GameServer,比如只做简单的广播服务,而其他的存储功能,都以Lambda的方式把游戏逻辑和存储服务结合起来,比较的省事。

运维管理

AWS由于主要目标是卖EC2虚拟机,所以拥有很多更“通用”的运维管理工具。其中一个就是Benstalk,这是一个一个Web应用部署工具,通过集成Git来拉取和存储你的软件。对于仅仅是需要部署WEB应用的客户来说,非常方便。而另外一个工具叫OpsWorks,这个是更通用的运维部署工具,看起来非常像Chef,你可以用它来部署任何软件。这类工具都是通过先在你的虚拟机(部署目标机器)上,安装一个Agent(代理程序),然后这个代理程序就可以从一个集中的软件部署任务服务器上,接受各种部署或配置的任务。用户可以集中在一个界面上去部署软件,修改配置,而且可以通过JSON格式的数据表,记录各服务器相同或者不同的配置,通过工具或自定义的脚本,自动化的在目标机器上做任何的部署操作。

AWS把对于EC2虚拟机的弹性部署,按负载自动伸缩能力,也应用在计费上。所以有一个叫CloudTrial的服务,其实就是按需付费的功能。这对于各种还在推广开发期的业务特别友好,国外有很多独立游戏或者创业项目,都直接在AWS上开发测试。同时AWS也提供了所谓的CodePipeline工具,其实是一种持续集成工具,但部署部分就默认结合在AWS上。虽然GAE也有各种开发工具,但直接以持续集成(CI)的面貌来提供服务,并且结合云服务,还是非常值得点赞的。毕竟现在在持续集成方面,大家都还是比较繁琐的去设置各种服务器环境,结合上运维系统,才能真正的“自动化集成”。而使用CodePipeline,开发者可以直接一键就把代码部署到EC2虚拟机上,中间还经过自动化测试等等集成任务。这样就又省了折腾持续集成软件的工夫了。

最后说说CloudWatch服务,这和GAE的Analytics服务有一种重要不同,就是他主要面向的虚拟机的数据,而不是具体的服务。这个系统另外一个特色,就是可以从日志生成、搜集、监控、告警、报表一体化。可以说是一个通用的日志分析系统。用户可以向CloudWatch发送自定义的指标,然后设置监控阈值,这样CloudWatch不但会在你设置的范围内进行监控报警,而且还会存储所有的这些日志,并用以生成统计报表和图形。

所有的这些服务,给我的感觉,就是虽说AWS服务看起来没有GAE那么“有技术含量”,但由于其高度注重易用性,所以非常容易吸引人去使用。就是不管你是什么平台或者架构,似乎都能用的上它的某几个服务。而且所有的这些服务界面,都是统一接口模型、统一界面风格,让人可以触类旁通,学习起来一点不费劲。(当然这里也有可能因为本身没有提供太过复杂的功能)

关联配套

由于AWS的主力产品是IaaS的EC2虚拟机,所以其在线计算的云服务几乎是没有的。但是有丰富的其他配套服务,一点不比GAE逊色。它们大体来看分为两类:

存储产品

  • S3:对象存储服务,以二进制块的方式直接存放。一些游戏开发商直接用来存用户存档数据。
  • EFS:和古老的NFS标准兼容的分布式文件系统。
  • CloudFront:具备全球节点的CDN服务。CDN国内用户是比较熟悉的,但AWS的优势在于其全球的机房和带宽优势。
  • RDS:这一块就是“关系型数据库”的服务类,包括了MySQL \ Orcale \ SQL Server \ PostgreSQL \ Aurora这些数据库服务器。这个服务就非常典型的是PaaS平台同的类型,但是AWS同样也提供。而且最后这个Aurora数据库,是AWS自己研发的,兼容MySQL的产品,据他自己说比MySQL快很多。
  • DynamoDB:一种NoSQL数据库,属于Schemeless,也就是无需预建数据结构的。可以使用Hash搜索(大概是等于号匹配),也可以使用Range搜索(大概是大于和小于号匹配),这一点是很多NoSQL都不具备的。
  • ElastiCache:类似Memcached/Redis这样的缓存服务器集群。这里AWS直接提供集群功能,就不需要自己去想办法搭Redis集群了。这也是比较典型的PaaS服务商会提供的服务。
  • SQS:分布式消息队列服务。这个服务很特别,一般来说消息队列服务,是用于比较大规模的服务器系统,需要把计算任务分布放在多个硬件(虚拟机)上运行,而彼此之间又需要互相通讯,所以需要这种消息队列服务。如开源的有ActiveMQ或ZeroMQ这种,但直接做成分布式的,还是比较少见的。这样不用自己维护消息队列服务集群,只需要使劲买EC2来添加计算节点,还是比较爽的。问题是这个服务的接口是Restful的,也就是说基于HTTP协议的,所以其延迟性应该是一个问题。如果在游戏里面使用,估计只有一些不太在乎延迟的,触发量较少的操作,会适合用这个服务,比如用户从游戏大厅进入到游戏房间这种。

离线计算产品

  • EMR:用来分析所有AWS提供的服务的日志。是一个强大的日志统计分析系统。
  • Kinesis:一种流式计算,类似Storm/Spark Streaming这种系统。值得注意的是,它同样是可以直接调用所有的AWS服务生成的日志。这是AWS离线计算产品的一个通用特征,就是“本系统”类的服务,都可以直接调用,无需用户自己去做各种接口或格式的转换。
  • Machine Learning:著名的机器学习服务,同样可以从AWS全线服务的日志中作为学习、测试数据集。秉承AWS的易用性设计目标,这个服务内置了大量的学习模型,很多功能都不需要使用者去自己编写各种学习公式。而只是需要开发者使用其交互式视觉工具,就可以完成对机器学习任务的配置和运行。
  • Redshift:PB级别的数据仓库,属于列式存储系统(一般大容量的数据库都是这种)

总结

PaaS作为一个“云”时代非常重要的概念,在实际的业务中应用却远没有IaaS和SaaS的广泛。究其原因,我觉得无非是其灵活性受限导致的。比如GAE这种教科书式的PaaS平台,尽管提供了各种管理服务和多种语言框架,但最后还是受一个大的Web服务的框框所约束。而且后台关联服务和PaaS服务存于一个沙箱中,虽然提供了很好的自动化运维的能力,但也造成了很多不便。除了一些很简单的、典型的互联网业务,很多其他的服务,都多多少少可能需要突破这些限制。——不过话说回来,这种PaaS对于标准的Web服务,确实是非常的方便,几乎完全不需要自己去运维。

而以AWS为代表的,这种不太纯正的PaaS,提供了大量的运维工具,实际上还是需要用户自己去做很多运维的工作。但这样也提供了极大的灵活性:你可以用IaaS的模式去使用AWS。同时AWS也提供了很多PaaS的配套管理服务,使用者同样可以不去自己部署、配置这些服务。可以说AWS同时IaaS的灵活性,和PaaS的强大功能。不过AWS也不是天衣无缝,其中Lambda服务,就不属于通用的业界标准,如果你把很多业务代码用Lambda的方式来实现,那么你就无法切换到别的云服务商上去了。加上AWS服务大部分都是Restful API,所以网络造成的延迟和带宽占用,都不适合大量交互的在线服务——网络游戏。

最后展望一下PaaS的发展,个人觉得通用型PaaS应该是没前途的。因为业务模型千差万别,模型上的通用必然带来功能上的限制,以及易用性上的确实。所以PaaS还是应该按不同的业务领域具体细分下去。现在互联网业务比较大的业务领域有三类:一是电子商务类,二是游戏类,三是资源社区类(如B站、今日头条、各种FM、云音乐APP等)。这三类业务都有其非常明显的模式和需求差异。

比如电商类服务,一般所谓的“业务流”是一个重要需求,而且对于存储安全性非常重视,但对于延迟要求就很低;而游戏类则无法接受单向的HTTP协议,而且多数都要和游戏客户端引擎(Unity/Unreal什么的)结合,对于延迟的要求非常高,大多数不能忍受超过300ms,存储只要可以无限扩容,安全性无需达到金融级都可以;社区类则对于大量的文件存储很分发是硬需求,需要更广的部署地点,但业务逻辑一般不会过于复杂。

因此我们很难通过简单原始的一个Web App应用框架,就把这三个方面的业务需求都框进去,而且除了处理HTTP请求,还有大量的业务通用功能,是可以作为服务做出来卖钱的,比如电商的订单系统、游戏的同步服务、社区的基础社区功能等等。

最后的总结,就是PaaS服务必须要立足业务领域,面向业务中的通用逻辑,才能真正的做好一个PaaS云。

无耻的小广告,腾讯游戏服务,专为游戏开发服务: http://gcloud.qq.com/

【声明】以上广告本人没有一分钱广告费

本文来源于 韩大微信公众号

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

编辑于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏技术杂文

微服务:真正的架构模式

微服务的相关知识和它的神秘令我着迷。概念上的微服务就像是现代最有趣的流行架构之一。它足够功能强大,有着广泛的使用方法;也足够模糊,难以统一而论。

1583
来自专栏数据和云

恒丰银行 I MySQL MGR与Galera性能测试买家秀

作者介绍: 赵守斌,十年银行业数据库管理经验,熟悉各种Oracle数据库系统方案,对MySQL开源数据库也有涉猎。目前牵头负责恒丰银行数据库管理和各类数据库服务...

4186
来自专栏SDNLAB

SDN实战团分享(五):基于VCS技术 + NSX 控制平台实现SDDC网络架构

1.数据中心和新的网络架构需要软硬件一体化 看到前面的兄弟关于NSX架构的分享,感到收获良多,Vmware力争实现的平台是一种和硬件解耦,把大部分问题在虚拟化架...

3536
来自专栏SDNLAB

99%的私有云环境中的安全风险

随着复杂性增加,基础设施组件之间的相互依赖性以及向基于云的基础架构的迁移以降低风险和成本,IT中断服务提供商Continuity Software发布了2016...

2797
来自专栏云计算D1net

在多云策略中确保应用程序可迁移性的三种方法

为了保持竞争优势,所有主要的公共云提供商都通过其他方式扩展其基本IaaS产品的功能,例如用于数据分析、事件处理和关系数据库的一系列Web服务。

620
来自专栏数据和云

恒丰银行 I MySQL MGR与Galera性能测试买家秀

作者介绍: 赵守斌,十年银行业数据库管理经验,熟悉各种Oracle数据库系统方案,对MySQL开源数据库也有涉猎。目前牵头负责恒丰银行数据库管理和各类数据库服务...

4674
来自专栏鹅厂网事

腾讯网络应对闰秒危机之最佳实践

"鹅厂网事"由深圳市腾讯计算机系统有限公司技术工程事业群网络平台部运营,我们希望与业界各位志同道合的伙伴交流切磋最新的网络、服务器行业动态信息,同时分享腾讯在网...

1975
来自专栏架构之美

以IM为例看58同城典型技术架构演变

1394
来自专栏云计算D1net

多云管理工具:组织可能需要的6个功能

管理人员需要多云管理工具来确保资源安全,并符合适用的合规标准。他们还需要这些工具来帮助充分利用每个云平台的功能,同时最大限度地降低成本。

1774
来自专栏EAWorld

普元微服务平台EOS Platform 8全新发布

普元新一代应用平台EOS Platform 8已经全面拥抱微服务架构,支持分布式架构,为企业业务上云提供云原生应用的支撑。同时该版本完全支持Spring Boo...

1032

扫码关注云+社区