我们知道，应用层是运行在云平台层上应用的集合。每一个应用都对应一个业务需求，实现一组特定的业务逻辑，并且通过服务接口与用户交互。总的来说，应用层的应用可以分为三大类:第一类是面向大众的标准应用，比如Google的文档服务Google Docs、IBM的协作服务Lotus Live等;第二类是为了某个领域的客户而专门开发的客户应用，比如Salesforce CRM;第三类是由第三方的独立软件开发商在云计算平台层上开发的满足用户多元化需求的应用，比如礼品清单应用Giftag等。

　　值得注意的是，不同于基础设施层和平台层，应用层上运行的软件千变万化，新应用层出不穷，想要定义应用层的基本结构十分困难。或者说，应用层的基本功能就是要为用户提供尽可能丰富的创新应用，为企业和机构用户简化IT流程，为个人用户简化日常生活的方方面面，实现这些应用的结构和方式也灵活多变。

　　1    应用层特征

　　应用层是云中应用的集合，回顾本章开始介绍的软件即服务(SaaS)的概念，最终用户就是通过SaaS的方式获得应用层中各种应用服务的。结合SaaS的定义，云计算应用层上的应用需要具有以下三个基本特征。

　　1·这些应用能够通过测览器访问，或者具有开放的API，允许用户或者瘦客户端的调用。云应用的理想模式是不论用户身处何处，不论使用何种终端，只要有互联网连接和标准的测览器，便可以不经任何配置地访问属于自已的应用。目前，虽然互联网连接速度和Web开发技术已经使基于测览器的型不同，应该选择合适的架构即可，而不必追求最为成熟的架构。

　　图4.11中的架构(A)是一种最简单的提供SaaS服务的方式。不同租户使用SaaS平台所提供的或者迁移到SaaS平台的应用实例各不相同，即使是同一个应用也将为不同的租户运行不同的实例，每一个实例都有其不同的配置和实现。这种架构适用于快速开发的小众应用，而在开发的过程中没有过多考虑可定制、可扩展等因素。

　　应用具有了非常好的用户体验，但是距离一些在本地安装与运行的软件仍有差距，比如在图形处理方面。因此，在云计算的初期，应用层某些应用也可以通过瘦客户端来访问。这虽然影响了云应用的灵活性，但仍是一种有效的折中方案。

　　2.用户在使用云服务时，不需要进行先期投入，只需要在使用的过程中按照实际的使用情况付费。首先，用户在使用云服务时不需要购买额外的硬件，因为从处理到数据存储都在云上执行，用户端的处理能力不高也可以访问云上应用。其次，虽然从本质上讲云应用也是供用户使用的软件，但用户不需要支付软件副本的费用，只需要注册一个账号，即可开始使用核应用。最后，用户开始使用云应用后，只需按照其实际使用最付费。

　　3.云应用要求高度的整合，而且云应用之间的整合能力对于云应用的成功至关重要。云应用之间的整合能力对于完美的用户体验来说是不可或缺的，因为用户的需求往往是综合性的。如果用户所需要的多个功能是由若干个彼此之间无法整合的应用程序来实现的，那么用户体验和操作效率都会大为降低。由于应用都是运行在云中而且彼此相对独立，因此云应用整合较传统应用会相对容易实现。

　　2    应用层架构

　　应用层应用类型多样，功能各异，实现方式也各不相同。提供SaaS服务的应用架构由应用类型、服务用户的数量、对资源的消耗等因素决定。一般来说，SaaS应用架构可以有四种方式，如图4.11所示。这四种方式由是否支持可定制、可扩展和多租户三个方面的不同组合而决定。一般而言，同时支持三个方面表明应用的灵活性和可用性更强，因而更成熟，所以，如图4.11所示的从(A)到(D)四种架构也显示出不同的成熟程度，图4.11也被称为SaaS应用成熟度模型。需要指明的是，根据应用的类型不同，应该选择合适的架构即可，而不必追求最为成熟的架构。

　　图4.11中的架构(A)是一种最简单的提供SaaS服务的方式。不同租户使用SaaS平台所提供的或者迁移到SaaS平台的应用实例各不相同，即使是同一个应用也将为不同的租户运行不同的实例，每一个实例都有其不同的配置和实现。这种架构适用于快速开发的小众应用，而在开发的过程中没有过多考虑可定制、可扩展等因素。

　　为了增强应用的可定制性，从而实现应用实现代码的共享，可以将应用中可配置的点抽取出来，通过配置文件或者接口的方式开放比来。当一个租户需要这样的应用肘，提供考可以修改配置，定制成租户所需要的样式。在运行的时候，提供者为每一个租户运行一个应用实例，而不同租户的应用实例共享同样的代码，仅在配置元数据方面不同。这种情形就是如图4.11所示的架构(B)。架构(B)适用于那些被多次使用但使用者对于与其他租户共享实例和数据存储存在担忧的应用。例如用户希望自己的数据与其他租户的数据在存储上是隔离的，自己使用的应用服务性能不受其他租户负载的影响，或者需要遵循的法规要求如此等。

　　在架构(B)的基础上，不同租户可以进一步共享应用的运行实例，这就是如图4.11所示的架构(C)。在架构(C)中，每一个租户都有一套自己的特定配置，不同租户所访问的应用看起来适应自身特定所需，与其他是不同的。但实际上，这些租户所访问的应用是同一个运行实例，它通过多租户技术实现了用户的配置、数据存储等方面的隔离。与染构(B)相比，架构(C)中不同租户共享运行实例需要通过可靠的多租户技术来消除用户对于运行性能和数据安全的担忧。

　　如果使用SaaS应用的租户数最很多，或者每个租户的工作负载起伏不定，为了有效服务用户的请求，我们希望SaaS应用不仅可定制、支持多租户，而且还应该是可扩展的。也就是说，SaaS应用的运行实例运行时所使用的下层资源与当前的工作负载相适应，运行实例的规模随工作负载的变化而动态伸缩。图4.11中的架构(D)即是这种情形。在架构(D)中，运行实例的规模可以动态变化，运行实例的前端有一个租户流量均衡器。该流量均衡器除了具有通常流量均衡器平衡流量的功能外，还需了解服务请求所属的租户，按照租户的不同而实现服务请求的流量聚合和派发，从而实现花租户粒度上的SLA管理。在租户流最均衡器的后端是应用的运行实例。由于SaaS应用大多是通过Web方式访问的，为了实现可扩展性，应用的架构可以采用J2EE应用模式的三层架构，即前端是处理HTTP请求的HTTP服务器，中间是处理应用逻辑的应用服务器，而后端是实现数据存储和交换的数据库服务器。三层架构的Web应用实现了传输协议、应用逻辑和数据的分离，每一层次所需的下层资源可以灵活伸缩，从而实现了整个应用的可伸缩性。

　　SaaS应用的开发可以利用各种各样已有的软件组件和框架。前面所述的Web应用的三层架构已有多种软件框架支持。而开发SaaS应用可以采纳的另一种架构形式就是面向服务的架构(SOA)。在SOA架构下，SaaS应用之间可以实现互相通信:一个SaaS应用可以作为服务提供者将功能暴露给其他的应用;也可以作为服务的请求者从其他应用获得数据和功能。在SaaS平台中存在大量SaaS应用的情况下，SOA可以使利用已有应用开发和生成新的应用变得更为方便快捷。

　　责任编辑：scarlett

　　更多内容请关注机房360，www.jifang360.com，中国绿色数据中心