3.3 PaaS
虽然通过IaaS实现了资源层的灵活性,但应用层的灵活性依然不够,于是在IaaS平台之上又加了两层,即PaaS(Platform as a Service,平台即服务)和SaaS(Software as a Service,软件即服务),用于解决应用灵活性问的题。相比IaaS对资源的管理,PaaS、SaaS与其有着本质的区别,它们更多的是对上层应用和服务的管理。整个云计算的服务模式如图3-7所示。
图 3-7
PaaS不但基于IaaS提供了虚拟化资源(如计算、存储、网络等资源),同时还基于虚拟化资源自动化部署了应用运行时所依赖的库、工具、服务、运行时环境等。
3.3.1 简介
有了IaaS,下一步需要做的就是在IaaS之上部署应用、服务。PaaS所能提供的服务主要包括特定编程语言的运行环境,应用运行所需的库、工具以及基础服务。PaaS的核心理念是用户只需要在 PaaS 之上部署应用,PaaS 可以确保底层的稳定性,从而使用户把更多精力投放在自己的应用中。在使用IaaS服务时,用户仍需要对操作系统、中间件、数据库等进行日常维护,这不仅加大了使用的复杂度,而且还大大增加了日常维护的工作量;而在PaaS服务模式下,用户无须关心虚拟机、操作系统、存储,可以自由地在虚拟机上安装所需的应用,如图3-8所示。通过PaaS,用户可以完成应用的构建、部署、运维管理,而不需要自己搭建计算环境。PaaS为用户提供了更高层的资源抽象,简化了用户对操作系统、中间件、数据库等的日常维护工作,从而使PaaS使用者只需要关注自己的应用,而由PaaS负责应用的部署、运维以及弹性伸缩、高可用等功能。
图 3-8
PaaS的理想工作模式是:应用开发者提交应用代码,PaaS平台的代码托管工具实现代码的编译、打包。打包后的代码,通过PaaS平台的自动化部署模块在IaaS提供的虚拟机上自动部署,此部署过程涉及整个代码运行环境的设置。一旦代码部署完毕,PaaS平台就会为该应用自动提供所有依赖的外部服务,从而确保应用正常运行。而且在应用运行过程中,PaaS平台还会自动接入日志、监控、告警等非核心业务服务,保障应用的整个运行过程。所以,一个完整的PaaS 平台包括应用的运行环境、应用的内部支撑服务、应用的外部依赖服务三部分,如图 3-9所示。
图 3-9
应用的运行环境:表示应用实际运行的计算节点上所需的运行环境,包括编程语言环境、应用框架等,以及运行环境所需的资源隔离和限制。
·资源管理:设置应用所需的 CPU、内存、磁盘空间等资源,并管控应用资源的使用情况。
·应用部署:包括代码的上传,根据开发语言将其所有的依赖和框架打包,并将打包文件部署在所选定的计算节点上。
·应用伸缩:增减应用的实例数,以应对负载的变化。此过程可以手动操作,也可以自动弹性伸缩。
应用的内部支撑服务:主要负责应用的认证授权、运维监控、日志管理等。
·认证授权:对应用的所有访问都会通过认证授权模块进行验证,以确保应用的安全性。
·运维监控:监控应用中各个模块的状态和 CPU、内存等信息,并实施对应用的运维操作,包括启动、停止、配置、升级应用等。
·日志管理:查看应用日志,方便测试和调试。
应用的外部依赖服务:为应用提供的外部服务,包括数据库、缓存、中间件等,不仅需要 PaaS 提供关系型数据库、缓存、存储服务,而且通常还需要大数据、NoSQL、机器学习等服务。
3.3.2 核心功能
PaaS的核心功能主要有自动化部署、多副本管理和弹性伸缩等,下面我们具体介绍。
1.自动化部署
PaaS提供了自动化编译、打包、部署的核心能力。基于已有的IaaS,先前主流的做法是租一批虚拟机,然后像使用物理服务器一样通过脚本或者手工的方式在这些虚拟机上部署应用。在部署过程中难免会遇到云端虚拟机和本地环境不一致的问题,而PaaS的核心目的就是解决这个问题。Cloud Foundry 是 VMware 在 2009 年推出的,也是业内首个正式定义 PaaS 的项目,它通过对应用的直接管理、编排和调度,让开发者专注于业务逻辑而非基础设施。在 Cloud Foundary中,当虚拟机创建好之后,只需要在虚拟机上部署Cloud Foundry,然后开发者执行一条命令就能把本地应用部署到虚拟机上。
像Cloud Foundry这样的PaaS项目,其最核心的组件就是一套应用的打包和分发机制,把应用的可执行文件和启动脚本打包到一个压缩包内,上传到云上Cloud Foundry的存储中。Cloud Foundry 会通过调度器选择一台可以运行这个应用的虚拟机,然后通知这台机器上的代理(Agent)把应用压缩包下载下来启动。
2.多副本管理
为了保障PaaS服务的高可用性,需要通过多副本机制实现应用的高可用性。多副本机制将应用及相关数据复制到不同的节点上,从而确保即使有部分节点损坏,也不会影响整体的PaaS服务。
因为相同的数据有多个副本同时存在,所以在数据源更新之后需要进行副本数据的同步。同步方式有推(Push)和拉(Pull)两种,其中推是指从数据源向各个副本推送更新数据;拉是指各个副本根据同步算法从数据源拉取更新数据。
3.弹性伸缩
虽然多副本机制可以保证PaaS服务的高可用性,但是无法保证PaaS有足够的能力服务于所有的用户,尤其当用户海量时。PaaS 通过垂直或水平的弹性伸缩来实现高可用性,其中垂直弹性伸缩是指通过在单节点上添加CPU、内存等资源实现伸缩;水平弹性伸缩是指通过添加节点实现伸缩。因为垂直弹性伸缩很容易达到物理资源的瓶颈,所以目前更多地采用水平弹性伸缩。
PaaS服务的弹性伸缩首先会通过负载均衡器将用户请求分发到该云服务的不同实例上。一旦负载均衡器认为负载超过了目前该云服务的上限,它就会通知云编排器。云编排器基于相同的虚拟机实例,调用相同的自动化部署工具安装、启动服务,从而实现水平弹性伸缩。前端的负载均衡器会陆续把新的请求转发到新的云服务实例上。
在对应用进行弹性伸缩时,需要考虑以下两点。
应用无状态化:实现弹性伸缩的一个重要前提是在实例上部署的应用没有状态,从而确保当负载均衡器把新的请求转发到新的实例上时,用户端不会丢失状态信息。
有状态应用分区:对于有状态的应用,例如数据库,往往采用分区模式,把状态信息分隔为一块块独立的部分,每个分区(Partition)负责一块信息。通过分区增强可扩展性,实现弹性伸缩。但是每个数据还是只有一个分区负责,所以无法实现高可用性,如图3-10所示。
图 3-10
3.3.3 微软Azure
本节以微软Azure 平台为例进行介绍。Azure 是一个集IaaS 和PaaS 于一身的平台,它于2010年推出,致力于为用户提供一个高质量的云平台,在这个平台上用户可以方便地开发出稳定、可扩展的Web应用。Azure的PaaS方案是在其IaaS服务基础之上构建的,包括计算、存储的虚拟化资源,以及SQL Azure提供的数据库等。
Azure 上的应用由不同的组件构成,而组件基于三种不同的模板(或者说开发模式)构建(在Azure中模板被称为“角色”)——Web Role、Worker Role和VM Role。其中Web Role通常用于运行 Web 应用的前端,支持.NET、Node.js(通过 IIS)、PHP、Ruby 等;Worker Role是一台已经安装了应用运行时环境的虚拟机,支持.NET以及C++、Java等编程语言;而VM Role就是一台传统的基于Hyper-V的虚拟机,具体如图3-11所示。
图 3-11
在Azure PaaS平台上,是通过为每个Role拉起多个实例来实现扩展性的,如图3-12所示。
图 3-12
3.3.4 PaaS的优缺点
前面我们从组成、功能等方面介绍了PaaS,还列举了Azure PaaS实例进行说明,下面我们总结PaaS的优缺点,以便大家更加清楚地了解PaaS。
PaaS的优点如下:
灵活性——应用自动化部署。
高可用性——通过多副本实现。
高性能——通过弹性伸缩以及自动化部署实现。
隔离性——多租户逻辑隔离或物理隔离。
PaaS的缺点如下:
传统PaaS使得应用与PaaS平台之间有着非常强的耦合性,PaaS为应用提供了专属的SDK,应用必须依赖这些 SDK,而用户必须使用 PaaS 平台提供的框架和中间件来重新开发自己的应用。此模式使开发人员失去了对底层环境和资源的控制力,并且存在较多的限制。