云计算平台层是能够容纳数量众多的不同应用的通用平台。不同应用的动态伸缩导致对相关下层资源的占用和释放频繁发生。为了保证应用在需要时能够及时得到所需资源，也为了提高资源的利用率减少平台层运维的成本，平台层的一个重要特性是对资源的高效复用。一般来说，平台层将资源维护为资源池，当应用需要时，就从资源池中取出相应的资源，当应用不再需要时，对应资源又回收至资源池，以备他用。通过这样的方式，平台层能够高效利用各种资源，对不同应用所占有的资源根据工作负载的变化来进行实时动态的调整和整合。
2.5.2.3运维环境
在应用部署和开始运行之后，云平台必须提供相应的管理工具和环境对应用程序进行运行时的管理，比如应用性能的监控、配置的动态修改等。除此之外，针对整个平台，也需要进行相应的管理工作，保证平台的健康运行和对资源的高效使用。云平台的管理环境的主要功能是支持不同角色的用户对云平台层进行管理。一个典型的运维环境包括两类角色：平台管理员和应用管理员。平台管理员与应用管理员在管理方式、管理内容和管理权限方面都有着很多的差别。
在管理方式方面，平台管理员更加侧重以一种层级的方式对云平台中主要的软件资源进行监控和管理；应用管理员采取的则是一种以应用为中心的管理方式，着重对应用的SLA方面进行管理。在管理内容方面，平台管理员关心的是平台中资源的整体使用状况和效率，以及不同资源之间的相关性等问题；而应用管理员则对应用相关的资源进行纵向的管理，比如，应用的数据库或者某些软件模块的配置，多层应用在不同层次间的访问性能等。在管理权限方面，平台管理员不能对应用内部的软件模块进行配置或者查看应用的业务数据；应用管理员的管理权限则不能超过应用本身，在应用内部可以对各个软件模块和业务数据进行管理。总体来说，平台层的管理主要包含了应用版本控制、应用配置和监控、应用的上线/下线以及计费方面的支持等。
随着业务和客户需求的变化，开发人员往往需要改变现有系统从而产生新的应用版本。云计算环境简化了开发人员对应用的升级任务，因为平台层提供了升级流程自动化向导。为了提供这一功能，云平台要定义出应用的升级补丁模型及一套内部的应用自动化升级流程。当应用需要更新时，开发人员需要按照平台层定义的升级补丁模型制作应用升级补丁，使用平台层提供的应用升级脚本上传升级补丁、提交升级请求。平台层在接收到升级请求后，解析升级补丁并执行自动化的升级过程。应用的升级过程需要考虑两个重要问题：（1）升级操作的类型对应用可用性的影响，即在升级过程中客户是否还可以使用老版本的应用处理业务；（2）升级失败时如何恢复，即如何回滚升级操作对现有版本应用的影响。
在应用运行过程中，平台层需要对应用进行监控。一方面，用户通常需要实时了解应用的运行状态，比如应用当前的工作负载及是否发生了错误或出现异常状况等。另一方面，平台层需要监控解决方案在某段时间内所消耗的系统资源，不同目的的监控所依赖的技术是不同的。对于应用运行状态的监控，平台层可以直接检测到诸如响应时间、吞吐量和工作负载等实时信息，从而判断应用的运行状态。比如，可以通过网络监控来跟踪不同时间段内应用所处理的请求量，并由此来绘制工作负载变化曲线，并根据相应的请求响应时间来评估应用的性能。对于资源消耗的监控，可以通过调用基础设施层服务来查询应用的资源消耗状态，这是因为平台层为应用分配的资源都是通过基础设施层获得的。比如，在应用部署时，通过使用基础设施层服务为其分配存储空间。在应用运行时同样通过调用基础设施层服务来存储数据。这样，基础设施层记录了所有与该应用存储相关的细节，这些记录可供平台层查询。
用户所需的应用不可能是一成不变的，市场会随着时间推移不断改变，总会有一些新的应用出现，也会有老的应用被淘汰。因此，平台层需要提供应用的上线、下线功能。平台层除了需要在卸载过程中删除应用程序，还需要合理地处理该应用所产生的业务数据。通常，平台层可以按照用户的需求选择不同的处理策略，如直接删除或备份后删除等。平台层需要明确应用卸载操作对用户业务和数据的影响，在必要的情况下与客户签署书面协议，对卸载操作的功能范围和工作方式做出清楚说明，避免造成业务上的损失和不必要的纠纷。
在应用运行过程中，应用管理员通常需要对应用进行配置或者运行策略的修改，比如更换应用的名称和域名，修改应用的持久化配置等等。在传统的环境中，这些配置和策略的修改经常牵涉到底层中间件甚至硬件环境的更改，因而是一个繁琐而且高风险的过程。云平台则通过自动化管理系统，保证了应用的快速的部署，以及底层支撑的软硬件资源的动态配置和重新分配。自动化管理系统在接收到应用管理员的配置或策略更改请求之后，会根据请求，制订相应的执行计划，将应用管理员针对应用的请求转化为底层支撑软、硬件资源的请求而进行相应的更改和配置，并且在重新配置的过程中，自动化管理系统会保证应用的正常运行。
平台层通常也需要对应用的统计和计费提供支持。简单来说，这个计费功能包括了两个方面。一方面是根据应用的资源使用情况，对使用了云平台资源的ISV计费，这一点我们在基础设施层的资源监控功能中有所提及。另一方面是根据应用的访问情况，帮助ISV对最终用户进行计费。通常，平台层会提供诸如用户注册登录、ID管理等平台层服务，通过整合这些服务，ISV可以便捷地获取最终用户对应用的使用情况，并在这些信息的基础上，加入自己的业务逻辑，对最终用户进行细粒度的计费管理。
2.6应用层
应用层是运行在云平台层上应用的集合。每一个应用都对应一个业务需求，实现一组特定的业务逻辑，并且通过服务接口与用户交互。总的来说，应用层的应用可以分为三大类：第一类是面向大众的标准应用，比如，Google的文档服务Google Docs、IBM的协作服务Lotus Live等；第二类是为了某个领域的客户而专门开发的客户应用，比如，Salesforce CRM；第三类是由第三方的独立软件开发商在云计算平台层上开发的满足用户多元化需求的应用，比如，礼品清单应用Giftag等。
值得注意的是，不同于基础设施层和平台层，应用层上运行的软件千变万化，新应用层出不穷，想要定义应用层的基本结构十分困难。或者说，应用层的基本功能就是要为用户提供尽可能丰富的创新应用，为企业和机构用户简化IT流程，为个人用户简化日常生活的方方面面，实现这些应用的结构和方式也灵活多变。本节我们首先总结应用层的特征，然后介绍应用层的基本实现架构。
2.6.1应用层特征
应用层是云中应用的集合，回顾前面介绍的软件即服务（SaaS）的概念，最终用户就是通过SaaS的方式获得应用层中各种应用服务的。
结合SaaS的定义，云计算应用层上的应用需要具有以下3个基本特征：
（1）这些应用能够通过浏览器访问，或者具有开放的API，允许用户或者授予客户端的调用。云应用的理想模式是不论用户身处何方，不论使用何种终端，只要有互联网连接和标准的浏览器，便可以不经任何配置地访问属于自己的应用。目前，虽然互联网连接速度和Web开发技术已经使浏览器的应用具有了非常好的用户体验，但是距离一些在本地安装与运行的软件仍有差距，比如在图形处理方面。因此，在云计算的初期，应用层某些应用也可以通过瘦客户端来访问。这虽然影响了云应用的灵活性，但仍是一种有效的折中方案。
（2）用户在使用云服务时，不需要进行先期投入，只需要在使用的过程中按照实际的使用情况付费。首先，用户在使用云服务时不需要购买额外的硬件，因为从处理到数据存储都在云上执行，用户端的处理能力不高也可以访问云上应用。其次，虽然从本质上讲云应用也是供用户使用的软件，但用户不需要支付软件副本的费用，只需要注册一个账号，即可开始使用该应用。最后，用户开始使用云应用后，只需按照其实际使用量付费。
（3）云应用要求高度的整合，而且云应用之间的整合能力对于云应用的成功至关重要。云应用之间的整合能力对于完美的用户体验来说是不可或缺的，因为用户的需求往往是综合性的。如果用户所需要的多个功能是由若干个彼此之间无法整合的应用程序来实现的，那么用户体验和操作效率都会大大降低。由于应用都是运行在云中而且彼此相对独立，因此，云应用整合较传统应用会相对容易实现。
2.6.2应用层架构
应用层应用类型多样，功能各异，实现方式也给不相同。提供SaaS服务的应用架构由应用类型、服务用户的数量、对资源的消耗等因素决定。一般来说，SaaS应用架构可以有4种方式，这4种方式由是否支持可定制、可扩展和多租户3个方面的不同组合而决定。一般而言，同时支持3个方面表明应用的灵活性和可用性更强，因而更成熟。需要指明的是，根据应用的类型不同，应该选择合适的架构即可，而不必追求最为成熟的架构。
为了增强应用的可定制性，达到应用实现代码的共享目的，可以将应用中可配置的点抽取出来，通过配置文件或者接口的方式开放出来。当一个租户需要这样的应用时，提供者可以修改配置，定制成租户所需要的样式。在运行的时候，提供者为每一个租户运行一个应用实例，而不同租户的应用实例共享同样的代码，仅在配置元数据方面不同。例如，用户希望自己的数据与其他租户的数据在存储上是隔离的，自己使用的应用服务性能不受其他租户负载的影响，或者需要遵循的法规要求如此等。
如果使用SaaS应用的租户数量很多，或者每个租户的工作负载起伏不定，为了有效服务用户的请求，我们希望SaaS应用不仅可定制、支持多租户，而且还应该是可扩展的。也就是说，SaaS应用的运行实例运行时所使用的下层资源与当前的工作负载相适应，运行实例的规模随工作负载的变化而动态伸缩。由于SaaS应用大多是通过Web方式访问的，为了实现可扩展性，应用的架构可以采用J2EE应用模式的三层架构，即前端是处理HTTP请求的HTTP服务器，中间是处理应用逻辑的应用服务器，而后端是实现数据存储和交换的数据库服务器。三层架构的Web应用实现了传输协议、应用逻辑和数据的分离，每一层次所需的下层资源可以灵活伸缩，从而实现了整个应用的可伸缩性。
