2.3　平台即服务（PaaS）

2.3.1　PaaS概述

所谓PaaS，实际上是指将软件研发的平台（或业务基础平台）作为一种服务，以SaaS的模式提交给用户。因此，PaaS也是SaaS模式的一种应用。但是，PaaS的出现可以加快SaaS的发展，尤其是加快SaaS应用的开发速度。在2007年国内外SaaS厂商先后推出自己的PaaS平台。

PaaS之所以能够推进SaaS的发展，主要在于它能够提供企业进行定制化研发的中间件平台，同时涵盖数据库和应用服务器等。PaaS可以提高在Web平台上利用的资源数量。例如，可通过远程Web服务使用数据即服务（Data as a Service），还可以使用可视化的API，甚至像800APP（八百名CRM专家）的PaaS平台还允许混合并匹配适合应用的其他平台。用户或者厂商基于PaaS平台可以快速开发自己所需要的应用和产品。同时，PaaS平台开发的应用能更好地搭建基于SOA架构的企业应用。

此外，PaaS可以帮助SaaS运营商进行产品多元化和产品定制化。例如，Salesforce的PaaS平台让更多的ISV成为其平台的客户，从而开发出基于他们平台的多种SaaS应用，使其成为多元化软件服务供应商，而不再只是一家CRM随选服务提供商。而国内的SaaS厂商800app通过PaaS平台，改变了仅是CRM供应商的市场定位，实现了BTO（Built To Order：按订单生产）和在线交付流程。使用800app的PaaS开发平台，用户不再需要任何编程即可开发包括CRM、OA、HR、SCM、进销存管理等任何企业管理软件，而且不需要使用其他软件开发工具并立即在线运行。

面向个人的EC站点的巨头公司Amazon，把最初为了自己公司运营用的系统平台进行出租，用户可以自由选择操作系统和中间软件，以这样的方式提供硬件以及软件平台作为服务。从2006年开始Amazon EC与Amazon S3开始作为服务推向市场。

作为现代软件业霸主和新时代计算先驱的Google，以搜索引擎与新型广告模式而闻名，他们使用便宜的计算机，强有力的中间件及其先进技术装备出了世界上最强大的数据中心和超高性能的并行计算群。2008年4月发表的PaaS服务（Google App Engine）和Amazon的EC2、S3、SimpleDB等服务拥有相似的功能。这些稳定的平台上搜索引擎、GMail等服务同样也在运行。类似地，以ASP-SaaS成功的Salesforce，2007年开始用于提供SaaS的系统基盘对外公开，用Force这个名称开始进入PaaS业务。其所提供的PaaS服务里采用Java类似的语言Apex以及Eclipse开发平台，整合的开发环境也作为服务进行提供（Development as a Service）。

上述的Google/Amazon/Salesforce三个软件巨头非常重视PaaS这种新的商业模式，Amazon的PaaS服务为了用户可以自由地组合服务提供了更多的自由度，Google为了提供更多的服务使用户能够方便使用，去掉了一些烦琐的作业。Google/Salesforce的PaaS不仅是提供基础硬件和开发环境，同样把真正的平台作为一种服务（PaaS）来提供。

2.3.2　PaaS的核心功能

云计算平台层与传统的应用平台在所提供的服务方面有很多相似之处。传统的应用平台，如本地Java环境或Net环境都定义了平台的各项服务标准、元数据标准、应用模型标准等规范，并为遵循这些规范的应用提供了部署、运行和卸载等一系列流程的生命周期管理。云计算平台层是对传统应用平台在理论与实践上的一次升级，这种升级给应用的开发、运行和运营各个方面都带来了变革。平台层需要具备一系列特定的基本功能，才能满足这些变革的需求。

2.3.2.1　开发测试环境

平台层对于在其上运行的应用来说，首先扮演的是开发平台的角色。一个开发平台需要清晰地定义应用模型，具备一套API代码库，提供必要的开发测试环境。

一个完备的应用模型包括开发应用的编程语言、应用的元数据模型，以及应用的打包发布格式。一般情况下，平台层基于对传统应用平台的扩展而构建，因此应用可以使用流行的编程语言进行开发，如Google APP Engine目前只支持hon和Java这两种编程语言。即使平台层具有特殊的实现架构，开发语言也应该在语法上与现有编程语言尽量相似，从而缩短开发人员的学习时间，如Salesforce.com使用的是自有编程语言Apex，该语言在语法和符号表示上与Java类似。元数据在应用与平台层之间起着重要的接口作用，比如平台层在部署应用的时候需要根据应用的元数据对其进行配置，在应用运行时也会根据元数据中的记录为应用绑定平台层服务。应用的打包格式需要指定应用的源代码、可执行文件和其他不同格式的资源文件应该以何种方式进行组织，以及这些组织好的文件如何整合成一个文件包，从而以统一的方式发布到平台层。

平台层所提供的代码库（SDK）及其API对于应用的开发至关重要。

代码库是平台层为在其上开发应用而提供的统一服务，如界面绘制、消息机制等。定义清晰、功能丰富的代码库能够有效地减少重复工作，缩短开发周期。传统的应用平台通常提供自有的代码库，使用了这些代码库的应用只能在此唯一的平台上运行。在云计算平台中，某一个云提供商的平台层代码库可以包含由其他云提供商开发的第三方服务，这样的组合模式对用户的应用开发过程是透明的。如图2-4所示，假设某云平台提供了自有服务A与B，同时该平台也整合了来自第三方的服务D。那么，对于用户来说，看到的是该云平台提供的A、B和D三种服务程序接口，可以无差异地使用它们。可见，平台层作为一个开发平台应具有更好的开放性，为开发者提供更丰富的代码库和API。

平台层需要为用户提供应用的开发和测试环境。通常，这样的环境有两种实现方式：一是通过网络向软件开发者提供一个在线的应用开发和测试环境，即一切的开发测试任务都在服务器端完成。这样做的一个好处是开发人员不需要安装和配置开发软件，但需要平台层提供良好的开发体验，而且要求开发人员所在的网络稳定且有足够的带宽。二是提供离线的集成开发环境，为开发人员提供与真实运行环境非常类似的本地测试环境，支持开发人员在本地进行开发与调试。这种离线开发的模式更符合大多数开发人员的经验，也更容易获得良好的开发体验。在开发测试结束以后，开发人员需要将应用上传到云中，让它运行在平台层上。

2.3.2.2　运行时环境

完成开发测试工作以后，开发人员需要做的就是对应用进行部署上线。应用上线首先要将打包好的应用上传到远程的云平台上。然后，云平台通过解析元数据信息对应用进行配置，使应用能够正常访问其所依赖的平台服务。平台层的不同用户之间是完全独立的，不同的开发人员在创建应用的时候不可能对彼此应用的配置及其如何使用平台层进行提前约定，配置冲突可能导致应用不能正确运行。因此，在配置过程中需要加入必要的验证步骤，以避免冲突的发生。配置完成之后，将应用激活即可使应用进入运行状态。

以上云应用的部署激活是平台层的基本功能。此外，该层还需要具备更多的高级功能来充分利用基础设施层提供的资源，通过网络交付给客户高性能、安全可靠的应用。为此，平台层与传统的应用运行环境相比，必须具备三个重要的特性：隔离性、可伸缩性和资源的可复用性。

①隔离性具有两个方面的含义，即应用间隔离和用户间隔离。应用间隔离指的是不同应用之间在运行时不会相互干扰，包括对业务和数据的处理等各个方面。应用间隔离保证应用都运行在一个隔离的工作区内，平台层需要提供安全的管理机制对隔离的工作区进行访问控制。用户间隔离是指同一解决方案不同用户之间的相互隔离，比如对不同用户的业务数据相互隔离，或者每个用户都可以对解决方案进行自定义配置而不影响其他用户的配置。

②可伸缩性是指平台层分配给应用的处理、存储和带宽能够根据工作负载或业务规模的变化而变化，即工作负载或业务规模增大时，平台层分配给应用的处理能力能够增强；当工作负载或者业务规模下降时，平台层分配给应用的处理能力可以相应减弱。比如，当应用需要处理和保存的数据量不断增大时，平台层能够按需增强数据库的存储能力，从而满足应用对数据存储的需求。可伸缩性对于保障应用性能、避免资源浪费都是十分重要的。

③资源的可复用性是指平台层能够容纳数量众多的不同应用的通用平台，满足应用的扩展性。当用户应用业务量提高、需要更多的资源时，可以向平台层提出请求，让平台层为其分配更多的资源。当然，这并不是说平台层所拥有的资源是无限的，而是通过统计复用的办法使得资源足够充裕，能够保证应用在不同负载下可靠运行，使其感觉平台层拥有的资源仿佛是无限的，用户可以随时按需索取。这就需要平台层所能使用的资源数量本身是充足的，并要求平台层能够高效利用各种资源，对不同应用所占有的资源根据其工作负载变化来进行实时动态的调整和整合。

2.3.2.3　运营环境

随着业务和客户需求的变化，开发人员往往需要改变现有系统从而产生新的应用版本。云计算环境简化了开发人员对应用的升级任务，因为平台层提供了升级流程自动化向导。为了提供这一功能，云平台要定义出应用的升级补丁模型及一套内部的应用自动化升级流程。当应用需要更新时，开发人员需要按照平台层定义的升级补丁模型制作应用升级补丁，使用平台层提供的应用升级脚本上传升级补丁、提交升级请求。平台层在接收到升级请求后，解析升级补丁并执行自动化的升级过程。应用的升级过程需要考虑两个重要问题：一是升级操作的类型对应用可用性的影响，即在升级过程中客户是否还可以使用老版本的应用处理业务；二是升级失败时如何恢复，即如何回应升级操作对现有版本应用的影响。

在应用运行过程中，平台层需要对应用进行监控。一方面，用户通常需要实时了解应用的运行状态，比如应用当前的工作负载及是否发生了错误或出现异常状态等；另一方面，平台层需要监控解决方案在某段时间内所消耗的系统资源。不同目的的监控所依赖的技术是不同的。对于应用运行状态的监控，平台层可以直接检测到响应时间、吞吐量和工作负载等实时信息，从而判断应用的运行状态。比如，可以通过网络监控来跟踪不同时间段内应用所处理的请求量，并由此来绘制工作负载变化曲线，并根据相应的请求响应时间来评估应用的性能。

对于资源消耗的监控，可以通过调用基础设施层就服务来查询应用的资源消耗状态，这是因为平台层为应用分配的资源都是通过基础设施层获得的。比如通过使用基础设施层服务为某应用进行初次存储分配。在运行时，该应用同样通过调用基础设施层服务来存储数据。这样，基础设施层就记录了所有与该应用存储相关的细节，以供平台层查询。

用户所需的应用不可能是一成不变的，市场会随着时间推移不断改变，总会有一些新的应用出现，也会有老的应用被淘汰。平台层需要提供卸载功能帮助用户淘汰过时的应用。平台层除了需要在卸载过程中删除应用程序，还需要合理地处理该应用所产生的业务数据。通常，平台层可以按照用户的需求选择不同的处理策略，如直接删除或备份后删除等。平台层需要明确应用卸载操作对用户业务和数据的影响，在必要的情况下与客户签署书面协议，对卸载操作的功能范围和工作方式做出清楚说明，避免造成业务上的损失和不必要的纠纷。

平台层运营环境还应该具备统计计费功能。这个计费功能包括了两个方面：一是根据应用的资源使用情况，对使用了云平台资源的ISV计费，这一点前面在基础设施层的资源监控功能中有所提及；二是根据应用的访问情况，帮助ISV对最终用户进行计费。通常，平台层会提供诸如用户注册登录、ID管理等平台层服务，通过整合这些服务，ISV可以便捷地获取最终用户对应用的使用情况，并在这些信息的基础上，加入自己的业务逻辑，对最终用户进行细粒度的计费管理。