摘要：
在国内外，云计算正在大步的走向商业化的道路，也得到了越来越多公司的重视。其中平台即服务（Platform-as-a-Service PaaS）已经称为业界探讨云计算的热点方式之一，采用PaaS模式来构建应用运行平台App Engine是一种重要的实现方式。本文主要是对App Engine的背景、特点、需求等进行分析整理，并据此对业界主要的App Engine进行了调研分析。最后对一个完善的App Engine进行了需求的细化分解、架构设计，并针对App Engine的部分核心技术问题提出了解决方案。
关键字：App Engine、PaaS、SAE、Nginx、scribe、Hadoop、Storm、Ptail、Scribe
1综述
1.1背景
在国内外，云计算正在大步的走向商业化的道路，也得到了越来越多公司的重视。其中平台即服务（Platform-as-a-Service PaaS）已经称为业界探讨云计算的热点方式之一，采用PaaS模式来构建应用运行平台App Engine是一种重要的实现方式，比如说国外的Google App Engine、国内的Baidu App Engine/Sina App Engine/Tencent App Engine。
云计算（Cloud Computing）是当前IT领域的热点，是继1980年大型计算机到客户端-服务器的大转变之后的又一种巨变。云计算的一个重要目标是“通过互联网，使用户更加方便、快捷、灵活地使用各种有质量保障的 IT 资源，这些资源以服务形式提供，终极的云计算环境将使得消费这些服务就像今天使用水、电和煤气等公共基础设施一样便捷”。通常来说云计算可以认为包含以下三个层次的服务：
-
- SaaS（Software-as-a-Service）：软件即服务。它是一种通过Internet提供软件的模式，用户无需购买软件，而是向提供商租用基于Web的软件，来管理企业经营活动。
- PaaS（Platform-as-a-Service）：平台即服务。PaaS实际上是指将软件研发的平台作为一种服务，以SaaS的模式提交给用户。因此，PaaS也是SaaS模式的一种应用。但是，PaaS的出现可以加快SaaS的发展，尤其是加快SaaS应用的开发速度。
- Iaas（Infrastructure-as-a-Service）：基础设施即服务。提供给消费者的服务是对所有设施的利用，包括处理、存储、网络和其它基本的计算资源，用户能够部署和运行任意软件，包括操作系统和应用程序。消费者不管理或控制任何云计算基础设施，但能控制操作系统的选择、储存空间、部署的应用，也有可能获得有限制的网络组件（例如，防火墙，负载均衡器等）的控制。
云计算三个层次的服务关系如下图所示：
![]( "1")
其中可以看出PaaS是承接Iaas和SaaS的关键点，是对底层IaaS的再次封装从而提供完善的运行平台来支撑不同的SaaS应用。PaaS的一种重要实现形式就是App Engine，本文分析的对象就是App Engine。
1.2 App Engine特点
App Engine具有PaaS平台的三个特点:
平台即服务：PaaS所提供的服务与其他的服务最根本的区别是PaaS提供的是一个基础平台，而不是某种应用。PaaS为不同的业务应用提供全流程的运行环境支持，对具体的业务应用而言，PaaS就是一个服务，一个为应用开发提供支持的平台服务。
平台及服务：一个App应用所需提供的服务，不仅仅是单纯的基础平台，而且包括针对该平台的技术支持服务，甚至针对该平台而进行的应用系统开发、优化等服务。所以一个完善的PaaS运行平台，不仅仅只能是运行环境，还需要提供各种相关服务，比如说完善的平台控制服务、自动化运维服务、弹性调度服务等等。
平台级服务：PaaS运营商对外提供的服务不同于其他的服务，这种服务的背后是强大而稳定的基础运营平台，以及专业的技术支持队伍。这种“平台级”服务能够保证支撑SaaS或其他软件服务提供商各种应用系统长时间、稳定的运行。PaaS的实质是将互联网的资源服务化为可编程接口，为第三方开发者提供有商业价值的资源和服务平台。有了PaaS平台的支撑，云计算的开发者就获得了大量的可编程元素，这些可编程元素有具体的业务逻辑，这就为开发带来了极大的方便，不但提高了开发效率，还节约了开发成本。有了PaaS平台的支持，WEB应用的开发变得更加敏捷，能够快速响应用户需求的开发能力，也为最终用户带来了实实在在的利益。
1.3 App Engine需求
App Engine将应用运行所需的 IT 资源和基础设施以服务的方式提供给用户，包括了中间件服务、资源管理服务、弹性调度服务、消息服务等多种服务形式。App Engine的目标是对应用提供完整生命周期（包括设计、开发、测试和部署等阶段）的支持，从而减少了用户在购置和管理应用生命周期内所必须的软硬件以及部署应用和IT 基础设施的成本，同时简化了以上工作的复杂度。为了确保高效地交付具备较强灵活性的平台服务，在App Engine中，平台服务通常基于自动化的技术通过虚拟化的形式交付，在运行时，自动化，自优化等技术也将被广泛应用，以确保实时动态地满足应用生命周期内的各种功能和非功能需求。
具体来说，搭建传统 IT 基础平台是一个漫长的过程，通常由申请，审计，硬件购买与运输，硬件安装与配置，软件安装与配置等步骤组成。在这个过程中繁复的手工配置工作费时费力，而且容易产成人为配置错误。同时，平台环境的升级维护也面临人为配置错误频繁产生问题，造成不必要的影响和损失。由于这些原因，搭建完成的应用运行平台，即使在一定时期内不再需要，也不会被及时释放回收，以供新项目使用。这是造成空闲硬件资源的原因之一。此外，传统基础平台提供的应用运行能力是静态的。然而在不同时间，应用负载往往是不一样的。为了确保高负载时应用的正常运行，应用运行平台必须能够提供最高运行能力，这就造成了非高峰时的众多空闲硬件资源。
云计算的产生，尤其是平台服务App Engine的理念，从产生空闲硬件资源的根本原因入手建立了快速搭建部署应用运行环境和动态调整应用运行时环境资源这两个目标。依据虚拟化与自动化技术实现应用运行环境的即时部署以及快速回收，降低了环境搭建时间，避免了手工配置错误，快速重复搭建环境，及时回收资源， 减少了低利用率硬件资源的空置。另一方面，根据应用运行时的需求对应用环境进行动态调整，实现了应用平台的弹性扩展和自优化，减少了非高峰时硬件资源的空置。
简而言之，App Engine主要目标是：Easy to maintain, Easy to scale, Easy to build。
具体来说，需求可以从三个维护来分解：
第一、 开发需求。从开发的角度来看，App Engine需要提供全流程的运行环境和全流程的开发环境。其中全流程的运行环境包含流量接入服务、运行环境、通用服务。全流程的开发环境包含：开发支持SDK、基础框架基础库、代码自动生产脚手架、单机运行环境。
第二、 运维需求。运维是App Engine最重要的目标之一，运行资源弹性调度、资源审计、预算、资源利用率、安全隔离、访问控制、实时监控等等都是重要的需求。
第三、 产品支持需求。这里面需要对开发、运维、产品提供全流程的管理支持工作，包含有开发上支持需求：业务监控、问题定位、分布式日志重建。运维上的报警、预算分析、自动调度。产品上的需求：统计分析、离线数据挖掘、在线实时计算。
2调研
主要调研分析了两个比较典型的App Engine：最近开源的CloudFoundry和国内最近比较火的Sae平台。
2.1 CloudFoundry
CloudFoundry是VMware公司在2011年4月份推出的开源PaaS平台，官方网站是http://cloudfoundry.com/。在这过去的一年发展中，CloudFoundry发展非常迅速，目前已经支持PHP/JAVA/Ruby等各种运行环境，并且很好的和各种开源框架、服务进行对接。
CloudFoundry的整体架构如下图所示：
![]( "1")
其中各个模块的工作如下：
1、 Request Router。顾名思义，是一个Router层，主要的工作是流量接入并进入路由分发请求到不同的App 执行环境中去。在CloudFoundry的具体实现中，Request Router是通过Nginx来实现的。
2、 App Exec Engine。同样通过字面上的意义可以了解到这就是CloudFoundry的App执行引擎。不同语言的执行环境都是在这里实现的，如何做到不同语言的执行环境同构化，CloudFoundry的实现方案很简单：直接对异构运行环境进行封装成一个tar包，并提供一个统一的start脚本来负责启动对应的服务。目前关于隔离性、虚拟化方面暂无详细支持计划。
3、 Services。通用服务，对通用服务的调用进行了简单的封装，并提供了服务加入流程化支持。Cloud Foundry的Service模块从源代码控制上看就知道是一个独立的、可Plugin的模块，以方便第三方把自己的服务整合入 CloudFoundry生态系统。在Github上看到service是与CloudFoundry Core项目vcap独立的一个repository，为vcap-service。Service模块其中设计原则是方便第三方服务提供商提供服务。在 这方面CloudFoundry做得很成功，从Github上看，已经有以下服务提供：a)MongoDB; b) mysql; c) neo4j; d) PostgreSql; e) RabbitMQ; f) Redis; g)vBlob。基类都是放在base文件夹中。第三方如果需要自己开发CloudFoundry的服务，需要继承改写它里面的两个基础类：Node和Gateway；而里面一些操作， 如：Provision，可以在base的provisioner.rb基础上加入自己的逻辑，同样的还有Service_Error和 Service_Message等
4、 Clond Controller。平台控制器。Clond Controller是CloudFoundry的控制管理中心，目前的主要功能有：对app的增删改读、服务的停止启动、app的部署、通用服务的部署管理。同时实现了一些简单弹性调度策略，比如说通过HealthManager来获取app应用的性能数据和健康数据，从而进行一些app实例的增加删除操作。
5、 HealthManager。监控状态管理中心。目前做的事情不复杂，简单的说是从各个App Exec Engine里面拿到运行信息，然后进行统计分析，报告等。统计数据会与Cloud Controller的设定指标进行比对，并进行相应的操作处理。HealthManager模块目前还不是十分完善，但是在CloudManage里面，自动化健康管理、分析是一个很重要 的领域，而这方面可以扩展的地方也很多，结合OrchestrationEngine可以使云自管理、自预警；而与BI方面技术结合，可以统计运营情况，合理分配资源等。
整体来说，CloudFoundry提供了比较完善运行环境支持，包含流量接入、app运行和通用服务，并实现了一定的平台控制和业务支持功能，比如说弹性自动扩容。但目前在资源管理、虚拟化、资源控制、产品支持方面还有很多工作来做。同时对于app运行环境之间的隔离性、安全控制也缺少考虑。
2.2 SAE
SAE是国内目前相对比较成熟的App Engine平台，从09年到现在已经为超过15W+的app应用提供服务。SAE主推PHP开发环境，目前也支持JAVA、Python，主要是公有云集群平台，同时也针对部分VIP客户提供了差异化的服务。
SAE的设计理念是：1、无状态对等节点，方便扩展。2、无单点。目前整体架构完整情况未知，从公开的资料来看，SAE在运行环境上的架构如下图：
![]( "1")
主要特点是：
1、 动态DNS。Isp和四层之间的工作。
2、 App Router。主要功能是反向代理、应用功能和权限配置、域名服务。是基于Nginx实现的。
3、 Runtime。实现沙箱（代码隔离、访问控制、分钟配额控制）、应用配置（appconfig）、本地IO（安全考虑不允许本地文件操作）等等。目前是应用级别的隔离。
4、 通用服务方面，目前已经支持非常多种通用服务，并且屏蔽了分布式实现细节，比如说mysql、kvdb、memcache、fetchurl等等。
5、 应用代码管理。目前支持在线编辑、代码采用svn来进行发布来提交，同时提供code deployer来实现代码的自动化发布。
在平台支持方面，目前SAE提供了统计和报表分析功能，也有部分资源审计、日志查看方面的产出，据说架构如下：
![]( "1")
3实践
从前面的描述，基本上介绍了App Engine的背景、特点和需求，也对当前一些主流的App Engine进行了调研，本章节主要关注如何能够搭建好一个完整的App Engine平台。本章节首先会明确细化分析App Engine的需求，然后给出平台的整体架构和方案，最后描述如何使用业界开源技术来搭建完成这个App Engine平台。
3.1需求
App Engine的最基本需求是能够给不同的应用提供全方面的服务，细分来说，App Engine平台的整体需求如下图：
![]( "1")
具体描述如下：
1、 流量接入。流量接入层最重要的三个功能是防攻击、流量接入、业务分流。此外还需要考虑内部隔离性等方面的需求。
2、 应用运行层。应用运行层是整个业务能够跑起来最重要也最关键的部分，包含运行基础环境、安全隔离、应用防攻击、资源管理、集群划分、授权管理。
3、 通用服务。通用服务主要是为App Engine提供各种基础服务，从而方便不同的应用来使用。此外还需要其他通用服务提供完成的服务接入流程和方案。
4、 平台控制。平台控制中心，是整个在线运行平台的中控中心。通过自动、手动想结合的方式把整个在线运行平台的各个系统协调控制起来，从而实现整个平台的正常运行。总体来说，平台控制器中心的功能会分为：业务调度、集群管理、资源审计、命令总控、代码管理、代码发布等等。
5、 日志服务。日志服务的主要作用是收集平台上应用和运行环境相关的数据，并为下游应用提供相应的数据访问接口。主要包括两个方面的工作：日志收集、日志处理。
6、 业务支持。由于所有的业务应用都统一运维，实现分布式部署、动态调度，因此一些可以在具体机器上实现的功能需求，需要通过其他手段来实现相应的分布式版本。比如说APP应用日志查看、问题定位、监控、统计。
7、 平台管理。平台管理主要是方便平台管理员来控制管理整个平台，并提供友好可用的界面。主要功能包括：平台监控、平台管理和业务管理三大块。
8、 开发支持。主要是对业务开发人员提供一系列的支持，方便业务开发人员使用ORP平台，并更好的管理好自己的业务。主要包括：业务管理平台、文档中心、反馈跟踪平台、相关SDK和工具。
3.2 整体架构
针对上述需求，整体架构如下图：
![]( "1")
其中各个模块的作用如下：
1、 App Router。对应流量接入层，主要工作是接收用户请求，并转发到不同的App Runtime。
2、 App Runtime。对应应用运行环境，为各个应用提供基本的运行引擎，从而让app能够运行起来。
3、 Code Center。对应代码中心，主要作用是完成代码存储、部署上线相关的工作。
4、 Services。对应各个通用服务，主要是对主流的服务提供通用的接入。
5、 Log Center。主要是实时收集相关系统的日志，并提供实时计算和分析平台，从而为Platform Control和Platform Support提供最基础的支持。
6、 Platform Control。平台控制层，主要作用是实现弹性扩容、资源审计、集群管理等相关工作。
7、 Platform Support。平台支持层，主要为app应用提供相关的支持，比如说app应用监控、问题定位、分布式日志重建、统计分析等基本功能。
3.3具体实现
3.3.1 App Router的实现
App Router的主要作用是流量接入 + 业务分流，从技术角度来看要满足几个点：高性能 + 完善的反向代理功能 + 足够的扩展性。据此，Nginx是一个不错的选择，Nginx有足够强劲的性能，并且在Http Proxy方面有着非常完善的支持，同时在防攻击、扩展开发方面也有着非常多的优势。此外，Nginx还能够非常方便的支持多域名多服务。具体可以参考http://blog.xiuwz.com/2011/12/08/nginx-internals/。
3.3.2 App Runtime的资源管理
在App Runtime中，需要重点关注几个点：
1、 容量评估。一个Runtime需要多少cpu、多少memcache、多少io，如何评估如何标准化。
2、 资源隔离。如何保证多个runtime在一个实体机器上不回出现相互影响是一个很值得关注的问题。
3、 安全控制。如何保证多个runtime之间是安全可控的，如何避免runtime a的程序能够读到runtime b的文件。
4、 资源的快速恢复。
其实这所有的问题结合分布式集群后，就是一个资源调度和管理的问题，如何实现分布式的资源管理，对于App Engine来说也是非常关键的一点。目前业界知名公司都在做类似的东西，比如说google的borg、腾讯的“台风”。
在简单的情况下，可以采用xen虚拟机或者cgroup方式来实现对机器资源抽象和隔离。关于cgroup可以参考这篇文章：http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/pdf/Resource_Management_Guide/Red_Hat_Enterprise_Linux-6-Resource_Management_Guide-en-US.pdf
3.3.3 Log Center的日志实时收集
平台支持和平台控制的不少需求都依赖实时的采集各个app应用数据。比如说弹性调度、资源审计、实时性能数据采集等等。
那么如何实现一个实时的日志采集呢？采用Facebook的Scribe是一个不错的选择。Scribe的整体架构如下图所示：
![]( "1")
关于Scribe相关技术可以参考以下文章：http://www.xiuwz.com/site/tech-open-scribe/。
3.3.4 Log Center的实时计算平台
平台支持和平台控制同样对实时计算有着强烈的需求，比如说弹性调度需要用到业务实时的性能数据，如何得不到就根本做不到弹性调度。对于离线计算分析，很显然采用目前成熟的hadoop平台能够完全满足需求。那么实时计算方面呢？建议直接采用twitter开源的storm实时计算框架。
Storm是一个实时流式计算框架，目前在twitter、淘宝等多个公司中都有应用，其整体架构如下：
![]( "1")
关于Storm的详细介绍可以参考官网相关资料：https://github.com/nathanmarz/storm。
3.3.5 App Engine的弹性调度
云计算最重要的特点之一就是弹性调度，从某种意义上来看，是否做到弹性调度也是平台一个App Engine平台技术成熟的关键点之一。从目前调研结果来看，完全实现弹性调度的App Engine屈指可数。
弹性调度的思想很简单：能够根据app应用的运行情况进行资源的动态调整，从而保证app应用整体的稳定性和系统资源利用率的最高。但要做好非常难，其中有几个关键问题点：
1、 app应用扩容的自动化。自动化一键扩容一个app应用是一个相当有难度的事情，需要寻找资源、部署app应用、检查效果、引入流量等等一系列操作。
2、 触发app应用扩容的时机。如何需要实时捕捉app应用的相关数据。
3、 模型。什么情况下需要进行弹性调度，是需要建立一个数学模型的。模型的好坏直接决定弹性调度的效果。如何设计不好，很有可能导致整个App Engine的不稳定。
4、 原子性。弹性调度本身是一个分布式事务，如何保证弹性调度和其他分布式操作（比如说更新业务）不冲突也是一个重要问题。否则很容易出现不一致问题。
5、 资源审计需求。如果没有资源审计，有可能出现一个app弹性调度消耗掉整体集群的资源。
那么具体如何来实现弹性计算呢？基本思路如下：
1、 基于实时计算平台和Log Center来实现对app应用数据的实时采集和分析。
2、 提供app应用扩容的服务。从业务流程角度来保证该命令的原子性。
3、 基于实时数据，建立简单的实时调度模型。
4、 引入简单的资源审计模型。
4参考文章
http://blog.xiuwz.com/2011/12/19/xldb2011%E4%BC%9A%E8%AE%AE%E6%95%B0%E6%8D%AE%E6%8C%96%E6%8E%98%E6%9E%B6%E6%9E%84%E7%B2%BE%E5%8D%8Eppt%E5%A4%A7%E5%85%A8/
http://www.oschina.net/p/paas/similar_projects
http://www.xiuwz.com/site/tech-open-scribe/
http://baike.baidu.com/view/1413359.htm
http://baike.baidu.com/view/1316082.htm
http://www.cloudguide.com.cn/newshow_177_0_bay_yes.html
http://blog.sina.com.cn/s/blog_493a84550101332d.html
http://blog.sina.com.cn/s/blog_493a8455010133l5.html
http://blog.sina.com.cn/s/blog_493a845501013ajw.html
http://blog.sina.com.cn/s/blog_493a84550101350q.html
http://blog.sina.com.cn/s/blog_493a845501012fe6.html
http://blog.sina.com.cn/s/blog_493a8455010132s6.html
http://sd.csdn.net/a/20111202/308433.html
http://news.csdn.net/a/20120202/311374.html?bsh_bid=71628880
http://www.programmer.com.cn/9818/
http://www.infoq.com/cn/presentations/cl-sae
http://www.infoq.com/cn/articles/cl-sae-datastore
http://www.chinagrid.net/show.aspx?id=8700&cid=22
http://www.infoq.com/cn/articles/clj-sae-mini-blog-app
http://www.infoq.com/cn/presentations/cl-sae-cloud-architecture
http://wiki.babel.baidu.com/twiki/bin/view/Com/Main/Bae_frontend_summary
http://sae.sina.com.cn/?m=devcenter&catId=164
by xuliqiang
本文转自百度技术51CTO博客，原文链接：http://blog.51cto.com/baidutech/1033700，如需转载请自行联系原作者
