随着互联网技术及其应用的快速发展，互联网业务提供者越来越呈现小团队、草根化的趋势．这些小型的业务提供者往往具备新颖的技术和业务理念，但由于规模不足、资本薄弱，需要面对应用访问网络能力困难和应用提供成本高、风险大等挑战．这些挑战严重影响了“草根”开发者业务创新能力的发挥．近年来，高速发展的云计算技术［1］为解决上述困境提供了可能．在云计算的3种应用形式［2］中，PaaS是云计算技术与业务提供平台相结合的产物，它不但可以为更高可用性、更具扩展性的应用提供基础平台，还可以提高硬件资源的利用率，降低业务运营成本，被认为是解放“草根”开发者业务创新能力行之有效的解决方案． 笔者首先从对工业界有影响的PaaS平台的分析和比较入手，深入研究了PaaS平台的体系结构，抽象出PaaS平台的通用概念模型;然后针对互联网应用的特殊需求，提出了面向互联网应用的PaaS平台体系结构;最后通过对具体项目中该体系结构的实现和测试，进一步说明了该体系结构的有效性和高效性． 1相关工作 目前，以Google、新浪为代表的众多互联网公司都推出了基于云计算技术的PaaS平台［3］，如GAE(googleappengine)和SAE(sinaappengine)［4］． GAE是Google管理的数据中心用于web应用程序的开发和托管平台，是互联网应用服务的一个引擎，支持Python和Java开发．SAE是由新浪公司开发运营的开放云计算平台的核心组成部分，其目标是为应用开发者提供稳定、快捷、透明、可控的服务化平台，支持Java和PHP5运行环境．有了GAE和SAE这样的PaaS平台，用户不用再为建设一个小型网站而去租用主机并选择托管商．用户只需要利用PaaS平台，就能创建、测试和部署应用与服务，与传统的软件开发相比，费用要低得多． 通过对常见PaaS平台的分析可以看出，PaaS平台应具备如下功能特性［5］．首先，PaaS平台为应用开发提供了一系列非功能属性支持，具体包含以下3点:第一，平台提供了应用程序的开发和运行环境，开发者不再需要租用和维护软硬件设备，同时免去了繁琐复杂的应用部署过程;第二，平台提供了应用程序的运行维护能力，开发者通过平台可以得知应用的运行状态和访问统计信息，全面掌握用户对应用的使用情况;第三，平台提供了应用的高可用性和高可扩展性，开发者无需关注底层硬件的规模和处理能力，平台会根据应用负载自动调整服务规模［6］．其次，PaaS平台提供了大量的网络能力，开发者可以便捷地在其应用中调用这些能力． 然而，现有的PaaS平台也存在一些不足［7］．第一，应用托管环境单一化，仅提供特定编程语言或脚本语言的运行环境．由于应用往往对相应的运行环境配置有较高的依赖，这种单一化的运行环境将导致应用兼容性低，需要引入应用迁移成本．第二，能力组件封闭化．虽然PaaS平台向应用提供一系列能力已经成为PaaS平台的标准做法，但是仅依靠平台提供商提供能力的做法显然大大限制了平台能力的丰富性，无法满足应用开发者对能力多样化的需求． 因此，提出的互联网应用PaaS平台将重点关注和解决如下问题:第一，为各种应用提供运行环境，不仅支持常用编程语言和脚本语言，还可以提供兼容性更强的、更为通用的运行环境，即将虚拟机也作为一种运行环境提供给应用;第二，提供开放式的能力组件机制，平台本身不但可以向应用提供能力，而且允许第三方基于此平台提供能力． 2PaaS平台概念模型 PaaS平台概念模型如图1所示．PaaS平台概念模型采用分层结构，由用户平面(UP)、应用平面(AP)、资源平面(RP)、物理平面(PP)和管理平面(MP)组成． CUP反映了PaaS平台的目标使用者，即应用开发者(Dev/Developer)．应用开发者可以开发多个应用，并将其部署到平台中． AP反映了应用开发者所开发的大量的不同类型的应用(APP/Application)，每个应用可以包含多个应用实例(AI)．这些应用具有不同的资源消耗和用户访问模型，包括应用逻辑、应用的计算和通信资源开销以及用户请求的分布情况．这些信息将作为MP对应用进行管理的依据． RP反映了AI运行的逻辑环境，由一系列不同类型的容器(CT/container)组成．这些容器将PP所提供的以主机为单位的分散物理资源汇聚在一起，形成资源池．在该平面中，不同类型的AI运行于相应的容器中，使用容器所提供的计算、存储和连接等资源．因容器中承载的应用类型不同，容器可以分为多种类型，如Javaweb服务器容器(JavaWS-contain-er)、虚拟机容器(VM-container)等．鉴于容器是一个相对独立的逻辑运行环境，容器中既可以运行第三方应用，也可以运行平台的自建应用．同时，第三方应用也可以作为平台的能力成为其他第三方应用可调用的组件，从而使得PaaS平台支持能力具有高的可扩充性． PP反映了PaaS平台底层的物理资源，由一系列物理实体(PE)组成，包括物理主机(HS/host)、存储器(ST/storage)和交换机(SW/switch)等硬件设备，为平台提供了底层的计算、存储和通信能力． MP负责完成对其他各平面的调度和控制．该平面包含2个组件:资源调度组件(RA)和任务调度组件(TS)．RA定义了应用经过多层映射最终分布到物理主机上的部署关系，即应用与AI的对应关系(APP-AI)、AI与容器的对应关系(AI-CT)以及容器与主机的对应关系(CT-HS)．TS定义了应用访问请求(REQ/request)到达平台后的转发规则，即为此请求选择合适的AI规则(REQ-AI)． 3面向互联网应用PaaS平台 3.1体系结构 PaaS平台概念模型提供了面向互联网应用的PaaS平台的设计思路．基于此PaaS平台概念模型，面向互联网应用的PaaS平台体系结构如图2所示．该体系结构主要包含3个组件，分别是应用集群管理(AppMaster)、智能应用路由器(AppRouter)和应用服务器集群(AppServer)．#p#分页标题#e# AppMaster是PaaS平台的控制核心，它负责加载RA以完成整个平台的资源调度工作，包括应用的部署和动态伸缩、收集平台的运行状态和统计信息等．AppMaster支持开放式的资源调度算法，即资源调度算法以组件的形式插入AppMaster中．App-Master根据平台规模大小等因素动态加载不同的ra，完成资源调度工作．AppRouter位于应用访问的前端，其内部维护一份全局路由表，负责加载ts，完成对应用访问请求的路由和转发，同时调整应用副本间的负载均衡．Ap-pRouter也支持开放式的任务调度算法．此外，为了提高应用访问的效率和可靠性，平台入口处前置一组反向，对应用请求进行分发，即应用的访问请求经由网关，通过反向路由至相应的处理节点． AppServer是包含大量主机的服务器集群，用于部署应用程序和处理应用请求．每台主机上运行着一个节点和若干容器．节点负责执行来自AppMaster的指令，并向AppMaster报告主机和容器的负载情况以及应用运行状态．容器用于承载部署到平台上的应用，包含Javaweb服务器容器和虚拟机容器2类，分别用于运行Javaweb应用和虚拟机应用． 3.2部署模型 物理主机通过交换机连接，每个物理主机承载多个不同类型的容器，不同类型的容器内运行相应类型的AI．其中，一部分容器面向应用开发者，运行第三方应用;另一部分容器面向平台，运行平台自建应用，完成对平台的管理和控制，如资源调度和任务调度等． 3.3关键技术 面向互联网应用PaaS平台的实现涉及如下一系列关键技术． 3.3.1通用容器 通用容器(GC)技术将包括Javaweb服务器和虚拟机在内的各类应用运行环境加以封装，对外提供统一的管理和操作接口，以达到统一承载多种类型应用的目的，从而提高PaaS平台提供应用运行环境的灵活性． 根据应用种类的不同，GC可以分为Javaweb服务器容器和虚拟机容器等，前者用于运行Javaweb服务器，部署Javaweb应用，其粒度低，针对性强，但兼容性较低;后者用于运行第三方虚拟机软件，向用户提供虚拟主机环境，其通用性强，具备更好的兼容性．根据应用性质的不同，GC还可以分为平台自建容器和第三方容器．前者用于运行PaaS平台自身的部分应用组件，如能力开放网关就是作为应用运行在GC当中的;后者用于运行应用开发者所开发的第三方应用程序． GC的核心在于对容器接口的抽象，即不论内部包含哪种运行环境，容器总是对外提供统一的接口． 3.3.2资源调度资源调度［8］ 技术是指PaaS平台能自动检测应用负载，调整资源的分配和伸缩，以实现负载均衡并提高资源的利用率，从而保障对应用提供透明的高可扩展性．具体来说就是主动完成AI副本的“创建/激活”和“去激活/撤销”，从而保证应用处理能力的平滑扩展． 根据平台规模和应用类型等因素的不同，资源调度算法的侧重点亦有所不同［9］．例如，当平台规模较小时，调度算法应重点关注资源利用率;当平台规模较大时，调度算法则应该更加关注集群的能耗情况等．因此，面向互联网应用的PaaS平台支持插件式的开放调度算法(见图2)，新的调度算法可以通过引入新的调度算法组件来实现． 目前，面向互联网应用的PaaS平台实现了一种多粒度的资源调度方案，即基于主机粒度判断集群负载情况，基于GC粒度完成应用的动态调度．该方案划分为2个阶段:第1阶段是数据准备阶段，完成主机负载信息的收集，从而判断主机负载高低;第2阶段是动态调度阶段，基于负载信息完成应用的动态扩容和收缩．4结束语基于提出的面向互联网应用的PaaS平台体系结构，项目组完成了相应的设计和实现工作．PaaS平台部署于4台联想R510G7服务器(CPU:2×4核英特尔?至强?处理器E5606;内存:4×4GBR-ECCDDR3-1333)，AppMaster等内部实体运行在2台服务器上，同时4台服务器均可作为AppServer承载应用开发者的第三方应用．PaaS平台的运行结果表明，该平台可以成功完成对Java应用和虚拟机的托管，切实提高平台的应用兼容性． 此外，项目组还针对PaaS平台的各项功能做了一系列测试．这些测试包括应用的高可用性测试、根据业务量的动态应用处理能力进行扩展测试等． 应用的高可用性测试是指当应用的某个副本所在服务器宕机之后，平台是否能正常处理后续的应用访问请求，并尽快完成应用副本的恢复．测试结果表明，由于平台支持应用的多副本部署，所以当某台或某些服务器宕机之后，平台可以继续正常处理相关应用的访问请求，并可以在30s(约3个心跳周期)内完成宕机服务器上全部应用的副本恢复． 应用处理能力扩展测试是指平台是否能根据应用访问量动态调整应用副本的数量，以实现平台资源利用率最大化．测试结果表明，应用访问量的持续激增会导致服务器长时间负载过高，平台的RA可以在10s(约1个心跳周期)内检测到访问量的激增，并在观察若干心跳周期后完成应用副本的扩充，扩充时延不超过15s(约1个调度周期)． 通过这一系列测试可以看出，所提出的PaaS平台体系结构不但能提供对应用透明的高可用性和高可扩展性支持，而且在应用兼容性和扩充性方面有较大优势．下一步工作将对面向互联网应用的PaaS平台与业界现有的PaaS平台进行比较，并考察平台在不同调度算法下的性能，以验证和调整当前的互联网应用PaaS平台体系结构．