gae PaaS调研：GAE与AWS哪家强？

作者简介

韩伟，腾讯互动娱乐R&D部的设计师，在网易工作了8年，担任无线事业部产品总监。从事技术开发多年，擅长开发高性能系统，有丰富的软件架构设计经验。个人的技术兴趣，比如设计模式，软件架构等等，提高软件开发的效率。个人微信官方账号:handa1740168。

一.原因

PaaS作为“云”的概念，已经流行了很长时间。从使用的角度看，好像是:写一个PHP，然后直接发送到服务器，让用户通过某个URL访问你的PHP。——这样真的节省了开发和运维的工作量，因为几乎完全不需要部署安装任何服务器端软件，甚至数据库都是为你安装的。

但由于各种原因，PaaS在国内没有得到广泛应用，可能是因为没有好的服务商(部分服务因长城而无法进入)。另外，作为一个游戏服务器开发者，我也尝试从PaaS的概念来学习如何提高游戏开发和运营的效率。所以有以下研究。

本文的主要研究对象是Google生产的App Engine和Amazone生产的AWS。其实微软和IBM也有类似的PaaS(Azure)，只是粗略浏览，由于时间和精力的原因并不深入。此外，国内也有一些类似于PaaS的服务，比如阿里巴巴云，但是因为口碑不高，这里就不描述了。

作为一个PaaS，我们可以注意到它可以分为几个层次，可以准确把握其特点。否则众多的技术术语和各种支持方案会让人眼花缭乱。这些级别是:

应用场景:PaaS希望解决的一个关键问题。

开发支持:PaaS是一个允许用户运行自己代码的服务，那么可以运行什么样的代码，如何方便用户上传自己的代码(或程序)，如何管理这些代码是重要的问题。

运维管理:PaaS最方便的是自动化运维，几乎总是被称为“无用户干预”，不需要用户自行部署服务器和配置软件。但是，这个能力也是很重要的一部分。

关联匹配:一个运行在PaaS上的程序不能完成太多任务，至少需要一个数据库等存储软件。其实在商业应用中，除了数据库，可能还需要大量的其他支持程序才能让你的业务逻辑程序完整运行，比如Memcache，甚至Crontab。由于PaaS被称为“帮助您运营和维护一切”，许多这些服务都是直接安装和部署供您使用的。您只需要使用服务提供商提供的访问参数，并直接使用它们。那么，服务提供商提供什么样的支持服务，他们拥有什么样的能力，就是PaaS服务的一个至关重要的特征，也是各种服务提供商相互竞争的主战场。

GAE(谷歌应用引擎)

应用场景

谷歌自己的Web服务有一套完整的“基础设施”，包括Web应用的运行框架(如PHP)、BigTable、GFS等知名的服务器端软件。所以Google App Engine的设计目标是让用户能够方便地使用这套“基础设施”。

从某种意义上说，为了使用谷歌的支持服务，可能比托管和运行自己的Web应用更有吸引力。Google的基础设施一般是“分布式”作为卖点，提供大承载能力和高可用性。普通公司几乎不可能自己重建整个系统。但实际上，真正需要使用这么大承载能力的，大概不是“普通公司”。但是对于来这里的用户来说，在Google的保证下获得信心安慰也是一个重要的价值。

发展支持

谷歌以其技术而闻名。其运行容器支持几乎所有主流编程语言如Python/Java/PHP/Go，以及这些编程语言在Web应用中的标准框架，如针对Java的Servlet。看到这里，我不禁感叹游戏领域没有“应用框架标准”——所以游戏服务器程序的模型真的是五花八门，使得游戏服务的提供变得极其复杂和困难。

GAE提供的开发工具可以帮助开发人员方便地测试和部署代码到PaaS。这些开发工具包括一套与Eclipse结合的IDE插件和一套命令上传和部署工具。用户可以像开发和测试本地程序一样使用这些工具。当然，在使用之前，您仍然需要在GAE上配置您自己的帐号。

GAE的另一个特点(也许是一个缺点)是开发人员只能在“沙盒”中运行他们自己的程序，所以你不能用代码来操作“本地资源”，比如套接字、本地文件和线程。由于这个约束，开发者上传的应用可以被认为是“无损”的，可以自动部署到不同的硬件和网络环境中。同时，GAE还提供大量配套服务，弥补沙盒环境造成的功能缺失。

运行和维护管理

GAE的运维管理是从代码部署开始的。首先，它支持部署从Maven这样的代码管理的库拉fetch程序，其次，它可以部署到Google提供的全局机房，在此期间提供自动扩展和负载平衡。值得注意的是，其运维环境还支持负载灰度和资源配额，即可以设置各种参数来限制cache 空、实例数、最大线程数、存储量空、带宽使用等。这些配额不是简单地从IaaS功能继承而来的，而是可以为应用程序容器或各种支持服务设置的。

GAE的另一大特色是所谓的谷歌分析功能。几乎所有的云服务提供商都会有统计功能，但Google Anlytics可以获得很多详细的服务统计指标，而不仅仅是操作系统层面的CPU、内存、带宽等大宗商品，因为它为完全托管的沙盒服务GAE做统计分析。如果我们自己部署任何服务，我们还需要特定服务流程的详细统计分析数据来监控问题。如果使用GAE，这些服务是由谷歌提供的，统计当然是它的职责。

作为Web App的容器，GAE提供了一套完整的Web界面操作软件——Google云平台控制台，可以配置URL、静态资源、MIME类型、根目录、SSL等几乎所有的WebServer配置内容。使用多年的网络服务器配置文件终于可以搁置了。

当然，其他管理服务也提供WEB配置管理工具。如果不想手动配置这些服务，也可以使用GAE提供的Restful接口，用代码操作这些服务配置，这样就可以编写自己喜欢的管理软件，或者编写自动化工具来做这种配置工作。

关联匹配

GAE提供的支持服务是众所周知的谷歌基本服务，分为两种类型和几十个子类别:

1.存储服务

应用引擎数据存储:NoSQL对象存储服务

GAE的MySQL不能自动扩展，因为它是一个关系数据库

谷歌云存储:使用Restful界面的分布式文件系统

2.辅助服务

定时任务:如crontab

最常见的网络后端缓存服务

Blobstore:一种“块”存储服务

身份验证服务

各种消息服务，包括电子邮件、短信、语音等...

全文搜索服务

图形处理应用编程接口库

各种常用的服务器端编程库

从以上来看，最值得注意的是存储服务。毕竟谷歌是互联网处理大数据的鼻祖。由于一般的商业互联网服务依赖于一个大容量、方便扩展的数据存储层，Google非常有价值。可惜作为游戏场，数据量大，也就是其数据关系一般比较简单，只是玩家的存档数据。所以，如果游戏开发者使用这些基于BigTable和GFS的服务，从延迟和成本上看，似乎并不是特别必要。

另外，从辅助服务的角度来说，连crontab都提供了细节，更别说各种服务器开发库了，只有你想不到的，没有他没准备的。这对于开发者来说是一个非常方便的地方，因为他们不需要到处找各种开源库，也不需要费心去和同事统一各种开发库，用GAE就可以了。

自动警报系统

应用场景

按理说，AWS不应该是PaaS，应该是IaaS。那你为什么放在这里？事实上，主要有两个原因:

首先，AWS不是简单的IaaS，因为它提供了大量的支持管理服务。虽然这些服务大部分是以Restful API的形式提供的，但是可以通过编程的方式调用；

第二，AWS本身就是一个非常有特色的“可编程”服务:Lambda服务。这种服务可以嵌入到它提供的各种服务中，为用户提供定制和控制这些支持服务的能力，所以这些服务看起来更像平台PaaS，而不是纯粹的IaaS。从嵌入Lambda的角度来看，AWS比GAE更激进，而不是沿袭Web服务的传统存在，因此可以被更广泛的互联网商家使用，而不仅仅是互联网电商客户。据说包括Lambda在内的AWS服务，在最近Steam上流行的一些新游戏中都有使用。

发展支持

AWS没有所谓的开发框架，因为它的核心是围绕其IaaS服务器EC2设计的。但更多的是针对EC2提供的各种透明的、基于网络的优化功能。例如，自动缩放是基于使用时间和负载条件来缩放EC2实例。这里补充一点，EC2虚拟机也支持Docker技术，可以方便的启动和迁移。另一个叫ELB的服务是类似L5的传统负载平衡器。

真正能“编程”AWS的是他们的Lambda服务。你可以用多种语言编程，包括Node.js/Java/C#/Python,写一些由触发器生成的事件处理回调。在AWS服务中，很多服务都支持Lambda，比如S3/dynamo db/运动学。当这些服务收到一个请求或改变它们的状态时，它们会触发许多不同种类的事件，从而调用这些用户定义的代码。

例如，当对象存储S3接收数据时，它将触发代码。这个功能很容易用来存档和阅读游戏。或者数据库服务DynamoDB可以在放入或获取数据时触发您的代码。当然，像驱动程序这样的流式计算服务本身需要用户代码来进行离线统计或数据处理。

将用户代码嵌入到服务中，而不是为用户代码提供服务容器，可能是服务于IaaS的需要的结果。但是这种灵活的设计也将用户从“标准开发框架”中解放出来，作为服务提供者，不需要像Google那样提供各种语言和各种WEB编程框架。因为GameServer的通用通信模型离Web很远，而且有很多主动通知和在线数据反馈的要求，所以使用Web框架肯定是不够的。但是游戏客户和AWS一样，可以自己编写一个简单的游戏服务器，比如只做简单的广播服务，而其他的存储功能是通过Lambda的方式将游戏逻辑和存储服务结合起来，相对来说比较容易。

运行和维护管理

AWS有更多“通用”的操作和维护管理工具，因为它的主要目标是销售EC2虚拟机。其中一个就是Benstalk，它是一个Web应用部署工具，通过集成Git来拉存储你的软件。对于只需要部署WEB应用的客户来说非常方便。而另一个工具叫做OpsWorks，是一个比较通用的运维部署工具。它看起来很像厨师，你可以用它来部署任何软件。

这种工具是在您的虚拟机(部署目标机器)上安装一个代理，然后该代理可以接受来自集中式软件部署任务服务器的各种部署或配置任务。用户可以集中在一个界面上部署软件和修改配置，可以通过JSON数据表记录每台服务器相同或不同的配置，并通过工具或自定义脚本自动在目标机上做任何部署操作。

AWS应用EC2虚拟机的灵活部署和根据负载自动扩展到计费的能力。所以有个服务叫CloudTrial，其实就是一个按需付费的功能。这对于各种还在推广发展期的商家来说，尤其友好。国外有很多独立游戏或者创业项目，直接在AWS上开发测试。同时，AWS还提供了所谓的CodePipeline工具，这其实是一个持续的集成工具，但是部署部分默认与AWS结合。

虽然GAE也有各种开发工具，但是直接面对持续集成(CI)提供服务，与云服务结合，是值得称道的。毕竟在持续集成方面，大家还是比较繁琐的去设置各种服务器环境，并结合运维系统，才能真正做到“自动化集成”。有了CodePipeline，开发人员可以一键直接将代码部署到EC2虚拟机上，中间经过自动测试等集成任务。这样就省去了不断集成软件的麻烦。

最后，我们来谈谈CloudWatch服务，它与GAE的Analytics服务的不同之处在于，它主要面向虚拟机的数据，而不是特定的服务。该系统的另一个特点是可以集成日志生成、收集、监控、报警和报告。可以说是一个通用的日志分析系统。用户可以向CloudWatch发送自定义指标，然后设置监控阈值，这样CloudWatch不仅可以在您设置的范围内进行监控和报警，还可以存储所有这些日志，并使用它们生成统计报告和图表。

所有这些服务给我的印象是，虽然AWS服务似乎不像GAE那样“技术性”，但它非常容易吸引人们使用，因为它非常重视易用性。不管你是什么平台，什么架构，似乎都可以使用它的一些服务。而且这些服务接口都是统一的接口模型和风格，让人可以毫无困难的类比学习。(当然，这里也有可能，因为它没有提供太复杂的功能)

关联匹配

由于AWS的主要产品是IaaS的EC2虚拟机，在线计算几乎没有云服务。但是还有很多其他的配套服务，一点也不比GAE差。它们通常分为两类:

1.存储产品

S3:对象存储服务直接以二进制块的形式存储。一些游戏开发者直接用它来存储用户存档数据。

EFS:与老NFS标准兼容的分布式文件系统。

CloudFront:带有全局节点的CDN服务。CDN国内用户比较熟悉，但AWS的优势在于全球机房和带宽优势。

RDS:这个块是“关系数据库”的服务类，包括MySQL ORCALE SQL Server PostgreSQL Aurora。这项服务通常与PaaS平台属于同一类型，但AWS也提供这项服务。而且最后这个极光数据库，是AWS自己开发的，和MySQL兼容，据他自己说比MySQL快很多。

DynamoDB:一个NoSQL数据库，属于Schemeless，也就是不需要提前建立数据结构。您可以使用哈希搜索(可能等于符号匹配)或范围搜索(可能大于和小于符号匹配)，这在许多NoSQL是不可用的。

弹性缓存:像Memcached/Redis这样的缓存服务器集群。AWS直接在这里提供集群功能，不需要想办法搭建Redis集群。这也是PaaS服务提供商提供的典型服务。

SQS:分布式消息队列服务。这项服务很特别。一般来说，消息队列服务用于相对大型的服务器系统。需要将计算任务分布在多个硬件(虚拟机)上并相互通信，因此需要这种消息队列服务。比如有ActiveMQ或者ZeroMQ作为开源，但是直接做分布式的比较少见。这样就不需要自己维护消息队列服务集群，只需要买EC2添加计算节点就可以了，挺酷的。问题是这个服务的接口是Restful，也就是基于HTTP协议的，所以它的延迟应该是个问题。如果在游戏中使用的话，估计只有一些不太在意延迟，触发较少的操作，会适合使用这个服务，比如用户从游戏厅进入游戏室。

2.离线计算产品

EMR:用于分析AWS提供的所有服务的日志。这是一个功能强大的日志统计分析系统。

驱动:一个类似风暴/火花流的流计算系统。值得注意的是，它也是直接调用所有AWS服务生成的日志。这是AWS离线计算产品的一个共同特点，即“本系统”的服务可以直接调用，用户无需自行转换各种接口或格式。

机器学习:著名的机器学习服务，也可以从AWS服务的日志中作为学习和测试数据集。秉承AWS易用的设计目标，该服务内置了大量的学习模型，很多功能不需要用户自己编写各种学习公式。只有开发人员需要使用他们的交互式可视化工具来完成机器学习任务的配置和操作。红移:PB级数据仓库，属于列存储系统(通常用于大容量数据库)

总结

作为“云”时代的一个非常重要的概念，平台即服务在实际业务中的应用远不如IaaS和SaaS广泛。我认为，原因无非是它的灵活性有限。例如，虽然教科书式的PaaS平台GAE提供了各种管理服务和多语言框架，但它仍然受到大型网络服务的限制。而且后台关联服务和PaaS服务都存储在一个沙箱中，提供了很好的自动化操作和维护能力，但也造成了很多不便。除了一些简单而典型的互联网服务，很多其他服务可能需要在一定程度上突破这些限制。不过话说回来，这种PaaS对于标准Web服务来说真的非常方便，几乎完全不需要自己操作维护。

AWS作为代表，并不是一个纯粹的PaaS，它提供了大量的运维工具，但实际上用户还是需要自己做大量的运维工作。但是它也提供了很大的灵活性:你可以在IaaS模式下使用AWS。同时，AWS还为PaaS提供了大量的支持管理服务，用户也不能自行部署和配置这些服务。可以说AWS既有IaaS的灵活性，又有PaaS的强大功能。但是AWS并不完美，Lambda服务也不是一个通用的行业标准。如果你用Lambda的方式实现了很多业务代码，就不能切换到其他云服务提供商。此外，AWS服务大多是Restful API，因此网络带来的延迟和带宽占用并不适合大量的交互式在线服务——网络游戏。

前景

最后，展望PaaS的发展，我个人认为一般的PaaS应该是没有前途的。因为业务模型差别很大，模型的普适性必然导致功能的局限性和可用性的确定性。因此，PaaS应该根据不同的业务领域进行细分。目前互联网业务主要有三大业务领域:电子商务、游戏和资源社区(如bilibili、今日头条、各种FM和云音乐应用等。).这三种类型的服务在模式和需求上有明显的差异。

比如电子商务服务，所谓的“业务流”是一个重要的要求，它非常重视存储安全，但是延迟要求很低；但是游戏类不能接受单向的HTTP协议，大部分都要结合游戏客户端引擎(Unity/虚幻什么的)。延迟要求很高，大部分不能超过300 ms，只要存储可以无限扩展，安全性不需要达到财务级别；社区类是大量文件存储和分发的硬性要求，需要更广的部署站点，但业务逻辑一般不会太复杂。

因此，我们很难通过一个简单而原始的Web App应用框架来框架这三个方面的所有业务需求。除了处理HTTP请求之外，还有大量可以做为服务出售的业务通用功能，如电子商务订单系统、游戏同步服务、社区基本社区功能等。

最后得出的结论是，PaaS服务必须立足于业务领域，面对业务中的共同逻辑，才能真正打造一个PaaS云。