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