PaaS论文

PaaS论文（精选7篇）

PaaS论文 篇1

摘要：在分析业界云计算现有理论基础上,结合宝钢云计算建设的实践经验,对企业私有云环境下Paa S层云服务的概念提出新的诠释与内涵。阐述了私有云下三种常见的Paa S服务及其适用场景,并以基础环境Paa S服务为例详细介绍了其业务服务和技术服务的设计要点和实际运用,以此来探索私有云Paa S服务建设的最佳实践。

关键词：私有云,PaaS,业务服务,技术服务

上海宝信软件股份有限公司王磊伍治平

自2007年云计算概念提出以来,其在IT行业的关注度至今一直居高不下[1]。早期多为互联网公司在推动云计算概念和技术的普及,如:Google、 Amazon等。很快以IBM、Microsoft、HP、Oracle为代表的传统IT巨头们也加入进来,并赋予云计算更丰富的内涵与解决方案。

目前,云计算根据服务对象的不同,大致分为公有云、私有云和混合云。互联网公司比较专注于面向普通社会用户的公有云,而大多数传统企业则更看重私有云服务,解决企业内部信息化建设的问题。根据提供的服务内容不同,云计算又可以分为Iaa S、Paa S和Saa S,即:基础设施即服务、平台即服务和软件即服务。从不同的学者资料和出版书籍上看,Iaa S与Saa S服务内涵和定义比较清晰和明确, 但对于Paa S服务由于服务对象不同、服务目标不同、 服务的提供者也不同,从而其服务界线与服务内容比较模糊。本文站在企业的角度,结合宝钢私有云建设的实践经验,论述企业私有云的Paa S服务的内涵定义与内容设计。

1企业私有云PaaS服务的定义

Paa S目前比较常见的定义为:提供了基础架构, 软件开发者可以在这个基础架构之上建设新的应用, 或者扩展已有的应用,同时却不必购买开发、质量控制或生产服务器[2]。这种定义更多是面向软件的开发者或公有云服务,并且平台的提供商还会进行一些限制和约束。例如:Google App Engine只允许使用Python和Java语言,需基于Django的Web应用框架,调用Google App Engine SDK来开发在线应用服务[1]。开发出来的应用多数也只能运行在服务提供商的特定环境中,无法进行服务的迁移。

在企业私有云环境下,不同时期的不同应用系统可能是由不同开发团队或软件公司设计完成,很难完全被一套开发框架所取代。并且,企业内部不同业务特点的应用系统对实时性、可用性、并发能力、 出错容忍度等技术要求也不尽相同,需要据此选择不同的技术路线与实现方法,难以以一概全。另一方面,Iaa S为应用系统提供了所运行的基础条件和虚拟化资源,如:机房环境、计算资源、存储资源与网络资源,但并没有提供基于云技术与应用系统相结合的集成与优化,也不包括基础软件、开发框架、 通信接口等应用系统所必须的软件资源,如此也很难满足企业用户的直接使用需求。

因此,企业私有云下的Paa S服务应该是能提供企业内部各种类型应用系统稳定、高效运行的基础环境支撑平台,既适合于新应用系统采用云相关技术的技术实现,也提供将原有的应用系统迁移至云中的综合解决方案。

2企业私有云PaaS服务的类型

Paa S服务的本质是使用户无需关心计算平台的操作系统以及软件环境配置与管理,于Iaa S之外提供更高的封装服务[3]。根据企业私有云Paa S服务的定义,其作为Iaa S服务的延伸与扩展,按照不同的服务内容,大致可分为三类[4]:

(1) 基础环境服务:为企业内不同业务系统提供基础的运行环境,包括:正式投运环境、开发测试环境、验证培训环境等。与大多数互联网公司提供的Paa S服务不同,企业私有云环境下不仅仅需要一个开发平台框架,而是需要一个完整系统环境服务, 不同开发团队开发的应用都可以通过简单部署配置后投入使用。既满足应用系统通常都要使用的数据库服务、中间件服务、通信接口服务、负载均衡服务等功能性需求,也提供系统高可用性服务、运行监控服务、动态伸缩服务、数据备份恢复服务、安全防护服务、甚至远程灾备服务等,从而保障应用系统在云环境中稳定、可靠、高效地运行。当然, 对于大型企业,企业内部有必要统一开发平台框架, 此举有利于对不同时期、不同开发团队开发的系统进行统一管理与维护升级,其也作为私有云Paa S基础环境服务的一部分。但根据不同应用系统的业务特点和要求不同,所提供的开发平台框架服务将不只一种。

(2) 基础平台服务:企业内部还存在另一种特殊类型的应用服务,其本身不构成完整的业务功能, 但大部分应用系统都需要使用这些应用实现特定功能或增值服务。例如:数据交换服务;短信通知服务; 统一认证服务;移动应用服务,等。私有云Paa S基础平台服务将这些共性的业务服务逐一进行整合封装,提供标准的平台调用接口,供各应用系统进行调用使用。其自身也使用基础环境服务进行安装部署,实现弹性扩展,同时也可以根据不同应用的实际使用情况进行计量或计费。

(3) 数据平台服务:随着大数据技术的逐渐成熟, 企业也越来越重视数据的潜在价值,尤其是那些有多年信息化积淀的大型企业。发挥多年沉淀下的历史数据价值,并与在线应用系统的当前数据进行互动分析,将成为企业保持市场竞争力和创新能力的取胜之石。由于数据涉及专业的业务知识,仅凭IT专业技术人员是无法做到的,因此需要将企业的原始海量数据在安全受限的前提下直接开放给第一线的业务人员和管理人员,使其结合自身的专业知识和业务思考,第一时间在大量数据中进行分析与验证,从而为企业创造最大商业价值。而云计算Paa S数据平台服务,则是提供技术支撑与保障、安全管控与审计以及提供友好的人机交互工具,方便不懂IT技术的人员也能快速、便捷地访问和使用企业的数据。另外,数据平台服务也可以为企业内以海量数据使用为主的业务系统提供服务,如:商务智能分析、物联网应用、档案管理系统等。

3企业私有云PaaS服务的设计方法

3.1服务目录

云计算对外提供服务,需要一本服务目录,它记录了云计算中心提供的所有服务项目。企业私有云服务也不例外,根据服务目录的用途不同,又分为业务服务目录和技术服务目录。

业务服务目录,是从最终用户视角对服务目录的理解,类似于饭店“菜谱”中的各道菜名,这些菜名是直接向顾客呈现的,例如“番茄炒蛋”、“鱼香肉丝”等;

技术服务目录,则是从IT技术人员的视角理解的业务服务,类似于每道菜的菜谱和具体烧制方法, 即该道菜所需的配料、每种配料的比例及各种配料加入的时机及火候等,这部分内容仅供厨师使用, 而不向最终用户呈现的。

服务目录的设计过程中服务颗粒度是经常遇到的问题,需要服务提供商与用户间能够进行良好的沟通,避免一开始就追求过细的颗粒度。常见的做法是采用CTI法则 (Class、Type、Item),即将服务分为大类、小类和服务项,示例参见表1。

3.2业务服务设计

在业务服务目录中增加一项业务服务的过程, 就是一次完整的业务服务策划及设计的过程,大致需要考虑如下要素:

(1) 服务编号和名称,遵循企业内部代码规范, 用以唯一标识该项服务;

(2) 服务对象,描述服务所面向的用户类型;

(3) 服务内容,简要描述服务所提供的功能、特点、适用范围等;

(4) 服务等级,描述服务是否要分级,分几个等级。不同级别将代表着不同的服务质量或者服务水平协议 (SLA),在后续技术服务实现时则可能对应不同的资源类型与等级;

(5) SLA细分指标项,描述不同等级承诺用户的服务水平协议内容,具体体现为细分的服务达成指标项;

(6) 服务规格,描述服务的规格配置,类似于服装的尺寸规格。在定义服务规格之前,首先要确定服务的关键衡量指标,这些关键指标不应是纯粹的计算机标准,而应该是用户也能理解并衡量的通俗语言;

(7) 服务计量方法,描述如何计量服务的关键衡量指标,以实现对服务的量化管理,包括需要采集哪些运行数据、如何进行计算和测量等;

(8) 服务报告,描述定期向用户提供的服务履行情况的主要内容;

(9) 服务计费方式,如果企业内部也需要对各业务部门使用的IT服务和IT资源进行模拟考核, 则需要对每个服务制定一个计费模式,例如: 按量付费或者套餐模式。

另外,为了配合服务计费,业务服务策划时也需要同步制定每个服务成本测算模型。采用云计算方式后,有许多资源均为多个服务共用,为了计算每个服务实例的真实成本,需要根据服务的技术实现和履行成本进行分摊和测算,具体包括机房成本、硬件成本、 软件成本、维护成本、人工成本、固资折旧周期等因素。

3.3技术服务设计

技术服务是对业务服务的IT技术实现,通常一个业务服务会由多个技术服务组成,每个技术服务完成某一IT技术领域的服务工作。在技术服务设计之前,需要先理解一个概念——“配置项”,它是IT技术实现的最小操作单元。技术服务的本质就是一组体现了技术架构模式的配置项及其关系的集合。在技术服务设计过程中需要明确配置项类型与规格,同时也需要明确配置项之间的关系。例如: VMware(2c,6G)、Cent OS 5.5、Tomcat 7.0构成了一个“Java中间件虚拟机”技术服务,而VMware(2c, 6G) 与Cent OS 5.5之间是“宿主”关系,而Tomcat 7.0与Cent OS 5.5之间是“安装”关系。 这些关系体现了最后技术实现所需采取的IT技术操作。

另外,在某一业务服务对应的一组技术服务中, 还需标识技术服务之间的关系。某个技术服务依赖于另一个技术服务,而某些技术服务却又是合作关系,这些组合后的技术服务又可以构成一个新的技术服务。例如:多个Java虚拟机的技术服务之间是合作关系,组成一个中间件集群,实现了负载分担和可用性保障,同时它也依赖于一个“网络负载均衡” 技术服务。

单个技术服务的设计要素大致如下:

(1) 服务编号和名称,遵循企业内部代码规范, 用以唯一标识该项服务;

(2) 服务类型,描述服务所属的技术领域,以便于管理和维护;

(3) 服务内容,简单描述服务所实现的技术功能与特点;

(4) 所依赖的技术服务,描述本技术服务依赖的其他技术服务;

(5) 规格配置,描述本技术服务的规格配置,比如:虚拟机服务包括采用虚拟化软件的类型、CPU个数、内存大小、操作系统型号与版本等。

3.4标准化

在业务服务和技术服务的设计过程中,有一项工作不得不提,那就是“标准化”。标准化不仅可以屏蔽底层技术的差异,同时也能有效地归并不同用户、不同业务场景的使用需求,从而有益于云计算中心的大规模化的集中管理和自动化维护,降低运营成本。

技术服务之间存在着多种关系,明确每项技术服务的规格与配置以及相互关系,是标准化的首要步骤。其次,根据业务服务的服务等级及服务规格所产生的二维矩阵,为每一个“等级 - 规格”的服务条目建立与之对应的标准技术服务映射关系,从而避免人为主观选择而产生的差异化。最终,运用自动化流程引擎等技术手段自动履行技术服务,生成各个服务实例,从而实现业务服务的自动交付。 同时,运用监控工具对技术服务和业务服务的运行状态进行监控,并根据预设策略实现自动化维护或动态资源调整,充分发挥云计算高效、弹性、按需使用的特性。

4实际应用

根据如上设计方法,在宝钢私有云的建设过程中,已经设计出“Java类OLTP应用环境服务”、“Web网站类应用环境服务”、“通信平台数据交换服务” 等五种业务服务模板;创建了涉及虚拟机、数据库、 中间件、负载均衡、虚拟防火墙等近四十个技术服务模板;并依靠这些服务为宝钢内、外客户提供了几十套应用系统的基础环境服务和基础平台服务。 在充分虚拟化硬件设备、有效利用IT资源的基础上, 提升了IT运维服务的质量,并且大大缩短了系统环境的交付时间,由原来几十天缩短到两天,而且随着标准化逐渐成熟,目标可以在数小时内完成交付, 从而实现云计算的快速、弹性的特性。

在具体设计和实践过程中,也遇到了企业遗留系统如何迁移,众多技术路线与服务标准化如何平衡的矛盾,需要持续不断的探索和创新,真正使私有云Paa S服务为企业创造最大价值。

参考文献

[1]刘鹏.云计算[M].第二版.北京:电子工业出版社,2011:1-3.

[2]John R.Cloud Computing Explained Implementation Handbook for Enterprises[M].北京:机械工业出版社,2011:41-42.

[3]李德毅,林润华.云计算技术发展报告[M].北京:科学出版社,2011:14-16.

[4]伍治平,王磊,毛淑华.面向传统大型企业集团的私有云解决方案研究与设计[J].冶金自动化,2012,36(5):1-5.

PaaS论文 篇2

作为一家以IaaS为主要业务的云计算供应商，华云数据此前一直专注在IaaS业务，而从去年上半年开始华云数据将业务范围向PaaS领域拓展，推出了自己云应用平台，宣布要主打运营型PaaS。而就在今年9月，华云数据又将自己的云战略向前推进了一步，推出了运营型PaaS Plus平台。

“华云数据专注于运营型PaaS，通过为软件开发商和企业提供完备的底层资源和软件快速部署支持，来降低软件SaaS化的成本，帮助软件开发商和企业实现软件的‘云化’。”华云数据技术服务有限公司首席战略官郁珉告诉《计算机世界》记者。

据悉，相比去年的云应用平台，PaaS Plus在对软件开发商的技术支持上有了全面提升。郁珉介绍，华云数据新推出的运营型PaaS Plus平台联合了众多底层平台、中间件和应用开发工具厂商，改传统的一对一、独立完成的产品交付方式为云端分享型的服务交付方式，从而为企业传统IT和应用开发者把整个开发、部署与客户服务的生命周期都搬到“云”上创造了条件。

比如，在政务云应用方面，华云数据就与国内知名的中间件供应商东方通进行合作，东方通的中间件产品已入驻华云数据开放服务平台，开发者可通过API接口接入到云端开发环境，实现架构、开发、测试、部署的一体化操作，大幅度节省了时间与人力成本。

而在企业云应用方面，华云数据与韩国中间件市场厂商TmaxSoft合作，推出面向中小企业的企业级数据库产品与应用服务器产品。目前这些产品已用于支持华云PaaS平台的销售结算、管理支持和安全合规等功能，从而为软件应用的SaaS云化提供了突破性的道路。其中，双方共同研发基于云的企业级数据库，面向开发者通过API与SDK提供数据库服务，价格仅为Oracle的一半，并更可按使用周期付费。

尤为值得一提的是华云数据即将发布全新PaaS服务——Chinac App Engine （CAE）。这被华云数据称为是继云巢之后又一次重大突破。郁珉表示，CAE将为开发者提供稳定、高效的应用托管平台，有效减少开发者的维护成本，极大提升应用稳定性。未来CAE可支持Java、PHP、Python、Node.js等主流Web开发语言，支持MySQL，特别适用于网站、博客、论坛等轻量级应用服务。

PaaS的范畴及架构标准化研究 篇3

平台即服务 (Platform as a Service, PaaS) 是云计算体系中的一种典型的服务模型。它介于基础设施即服务 (Infrastructure as a Service, Iaa S) 和软件即服务 (Software as a Service, SaaS) 之间。基于PaaS提供的平台运行时, 用户 (开发者) 可以便捷地开发和部署应用程序, 将应用程序托管在PaaS管理的云基础设施中, 从而节省大量的平台搭建和维护工作, 并达到缩短应用程序开发周期、降低运行和维护成本的目的。PaaS为用户管理云基础设施, 并为用户开放平台服务, 因此它须对底层的云基础设施中的服务器、存储、网络等资源进行统一管理, 且应为用户提供标准的平台和运行时环境。标准化的PaaS架构可以使PaaS能够适应更多类型的云基础设施, 也是不同PaaS应用程序之间互操作和可移植的前提。

2 PaaS范畴

作为云计算的一种服务模型, PaaS应具备云计算的特性, 即中心化的资源共享、网络资源访问、弹性资源供应、自服务以及服务可度量。通过分析这些特性在PaaS中的体现, 可以帮助我们更加清楚地界定Paa S的范畴。

2.1 中心化的资源共享

PaaS中心化共享的资源覆盖中间件和应用程序运行时两个层次。中间件运行在操作系统层之上, 是构建集成化应用的基础。中间件按照一定的拓扑结构进行组装, 就形成了应用程序运行时环境。因此, PaaS的中心化资源共享的本质是对中间件的集中管理和共享。PaaS的中间件资源的中心化共享有以下两种方式:

一种是将中间件实例作为资源池进行集中管理和共享, 对外提供基于元数据和编程模型的运行服务, 如Google App Engine (GAE) 、Force.com等。当接收到访问请求时, PaaS会通过中心调度策略分配相应的中间件实例, 响应请求。每个中间件实例都可同时被多个用户共享, 系统在中间件层面上应用多租户技术, 隔离用户之间的数据、应用程序和用户配置信息。

另一种是将中间件以虚拟设备的形式进行集中管理和共享, 对外提供可配置的集成化平台实例。这种资源共享方式在私有云中较常见, 目前也有一些公有云提供这一层面的资源共享, 如Windows Azure、阿里云等。用户可以创建中间件虚拟设备实例, 按需将不同的虚拟设备组装成集成化平台实例, 并在其中部署集成化的应用。PaaS能够通过中心化的资源管理为用户调度所需的计算资源。每个平台实例可在多个用户之间共享其中的数据和应用程序, 系统在平台实例层面上应用多租户技术, 隔离不同平台实例。

另外, PaaS还可包含提供特定功能的公共服务群, 它是一个集中共享的服务资源池, 类似于应用程序的开发包, 包括内容分发网络 (Content Delivery Network, CDN) 、分布式共享内存、开放身份认证、电子邮件等服务。PaaS中应维护一个服务群的服务目录。服务群中的服务可在用户之间共享它的功能, 提供无状态的服务, 或通过多租户技术隔离不同用户之间的数据。

2.2 网络资源访问

用户通过网络可以访问到PaaS所提供的平台资源, 其中包括应用程序的应用平台、集成平台以及服务群等。

应用平台提供了开发平台和框架, 是PaaS中应用程序运行的容器, 它包含与应用程序开发和运行相关的标准化技术构件及服务, 如应用服务器、数据库、多语言开发工具和编程模型等。

集成平台能够在PaaS中构建云和企业之间的集成应用。用户可以使用PaaS开发集成流, 将托管于云或本地的应用程序连接起来, 并部署在平台中。集成PaaS按其集成的领域不同可分为B2B集成、云集成以及SOA集成三类。B2B集成指不同电子商务提供商之间的业务的集成, 例如某在线零售商需要在淘宝上出售其产品, 它需要将淘宝提供的电子商务接口集成到它自己的电子商务平台, 从而实现统一的库存管理。云集成是指不同云服务之间的集成, 例如将公有云平台提供的CRM服务与企业的私有云集成, 私有云可以对用户使用CRM的情况进行监管。SOA集成指的是企业服务总线、消息队列等, 用户可以在PaaS中集成应用服务。另外, 集成平台还可以提供对业务流程和工作流的支持。

PaaS的服务群可为用户提供功能性和非功能性的服务, 可包括应用服务的开放平台 (如Gmail的开放接口、淘宝的开放平台、新浪的开放平台等) , 以及利用系统资源为用户提供的性能优化服务 (如Memcached分布式共享内存、Map Reduce分布式计算模型等) 。

用户可以直接调用PaaS提供的服务接口、通过Web门户 (如WSO2 Stratos的集成门户) 或者客户端插件 (如Eclipse中的Cloud Foundry插件) 访问网络中的平台资源。

2.3 弹性资源供应与自服务

云计算能够提供弹性的计算能力, 用户可以以自服务的方式对计算能力提出要求。云计算中的弹性资源供应与自服务代表云计算的提供者和用户 (消费者) 对资源管理的责任, 这两个属性应完全覆盖云计算的资源管理范畴, 并有明确的界限。

在PaaS的服务模型中, 用户可单方面向Paa S提供者提出对平台服务的要求, PaaS应透明地为用户编排资源池中的资源和云基础设施, 满足其要求。可以认为, PaaS中的弹性资源供应与自服务的界限就是“平台”。而PaaS的应用场景和部署模式不同, 平台中包含的内容也不尽相同。

对于运行时服务来说, 提供者提供已经部署和配置好的应用程序运行时环境, 并为其中的任务动态的分配计算资源, 在不同资源实例之间迁移任务。从用户的角度, PaaS的自服务一方面体现在对平台的要求, 如平台能够提供的每分钟服务接口访问量、数据库空间、优化功能 (如为应用程序分配的共享内存的大小、CDN空间等) 、服务质量等;另一方面, 应用程序的逻辑和部署的元数据中也提出了对平台的需求, 如所需的服务类别、服务的调用方式和时机等。例如, GAE的前端服务器将访问请求 (计算任务) 分配给适当的应用服务器, 并使用主应用服务器在应用服务器之间动态地调度计算任务的分布。而它对用户开放的是一个符合其SLA的完全透明的应用开发环境。

对于集成化平台实例, PaaS的自服务属性还允许平台的管理员、用户对平台的中间件进行配置, 可根据固定的模板或自定义的方式, 对运行平台中的中间件的拓扑、中间件虚拟设备的配置以及访问策略等进行定义和调整。PaaS可提供一系列的工具和服务创建平台环境的模板、虚拟环境和数据的快照, 并允许用户导入和导出, 以及实现平台在不同提供者之间的迁移。例如IBM的Smart Cloud应用服务, 它为用户开放平台搭建的模板, 用户可使用模板快速的配置一套符合自己要求的集成化应用平台。

因此, PaaS的弹性资源供应和自服务的界限可能落在两个层面, 一是运行时服务层, 二是中间件资源 (即集成化平台实例) 层。应用平台层的自服务属用户服务管理的范围, 包括对服务质量的定义、许可证的管理等 (用户服务管理还应包含用户信息及账单的管理) 。这一层面的用户自服务还体现在应用程序部署中, 部署者选择与应用程序兼容的应用框架, 通过应用程序包 (如war) 部署的元数据定义平台的中间件、数据库等构件的拓扑结构。中间件资源层的自服务的参与者可以是用户和管理员, 包括对运行中间件的虚拟机的配置、虚拟化环境的拓扑配置等。PaaS的自服务范畴之外对资源的管理, 就是PaaS提供者的弹性资源供应范畴。

2.4 服务可度量

PaaS中的服务就是平台, 它的度量应与自服务的层次一致。在应用平台中, 由于它只对用户开放应用程序运行时服务, 服务的度量粒度应为运行时服务的使用时间。而在集成化应用平台中, 由于它允许用户对中间件以及虚拟设备进行管理和配置, 因此, 服务的度量粒度可细化到具体的中间件服务及虚拟设备实例的使用时间。

综上所述, PaaS可以通过不同级别的多租户模型向用户提供应用平台、集成平台及功能性的服务群, 支撑应用程序的开发、部署与运行。用户对PaaS资源的控制范围以及服务度量的粒度根据应用场景和部署模式不同, 可介于中间件资源和运行时环境之间。

3 PaaS架构的标准化思考

根据前文对PaaS范畴的界定和分析, Paa S可共享运行时服务和中间件层面上的资源, 提供应用平台和集成平台。PaaS中还可集成功能性的服务群为集成化应用的开发和运行提供功能上的支持。对于上述资源, PaaS应提供一体化的管理和配置工具, 为用户的自服务、系统弹性资源配置提供接口。由于PaaS是云计算的一个中间层次, 它所提供的资源、平台、服务、接口会关联到底层的云基础设施, 同时会影响到基于它构建的应用。标准化的PaaS架构就是定义其中的资源类型、平台架构、服务接口格式以及API, 使PaaS和PaaS中部署的应用具备可移植性, PaaS之间具备互操作性。

目前, 对于PaaS架构标准化的研究仍处在探索阶段。经过近几年的快速发展, PaaS产品的供应商积累了一些PaaS的参考架构, 这些参考架构虽然在架构上有一定的普遍性, 但仍与厂商的产品联系比较紧密, 不具备通用性。当前, 无论PaaS中的软件开发、PaaS的设计和实施, 几乎都在遵循着各厂商的架构标准。美国国家标准与技术研究院 (NIST) 在《云计算参考架构》以及《云计算的概要与建议》中对PaaS进行了定义, 并对PaaS供应商对资源的控制范围、关注点等提出了建议。高德纳咨询公司 (Gartner) 在2011年曾提出一个PaaS的参考架构, 并整理了一套PaaS的分类法, 将PaaS分为应用PaaS和集成PaaS两类, 将应用PaaS分为元数据PaaS、框架Paa S以及实例PaaS。Gartner同时也认为, PaaS仍处在一个发展的初期阶段, 到2014年, 各厂商提供的PaaS产品的功能才会发展健全。云标准用户协会在《云计算用例》白皮书中阐述了PaaS实施的方法, 并列举了典型的PaaS场景和用例。国内的厂商、高校和科研机构对于PaaS架构的研究也有着广泛的参与。由金蝶中间件等多家厂商, 北京大学、华南理工大学, 以及中国电子技术标准化研究院共同推动的《PaaS平台参考架构》已于2012年正式立项为国家标准, 将于2014年完成对PaaS参考架构国家标准的研制。目前, 标准编制工作组已对表1所列举的PaaS参考架构相关的文献进行了研究, 下一步将重点根据从国内外收集的PaaS案例进行研究分析, 提取标准化的需求和功能。

4 结语

PaaS论文 篇4

随着近十几年来互联网的迅猛发展, 云计算时代悄然而至。云计算是一个虚拟的计算资源池, 它通过互联网使得用户使用资源池内的计算资源[1]。完整的云计算是一整个动态的计算体系, 提供托管的应用程序环境, 能够动态部署、动态分配/重分配计算资源、实时监控资源使用情况。

国际数据公司IDC的高级副总裁兼主要分析师Frank Gens指出目前云计算服务面临的最大挑战和问题是安全问题[2,3]。云计算安全中用户的身份认证位于整个系统安全的最顶层, 用户身份及他们对于应用及数据的访问级别在业务领域处于核心位置, 因而必须对其实施高效管理。Paa S作为云计算的一种模式, 其上部署的应用急需高效灵活的身份认证方案。

1 背景

1.1 云环境下的身份爆炸

传统的身份提供方式是每个系统各自管理身份, 即本地身份, 包括创建、修改、认证、删除。在早些年很难想象可以用一个聊天工具的账号去登录另一借书网站。比较典型的情况是一个用户同时拥有多个不同服务提供商的账号, 比如e-bay, Gmail, Google, 公司账号等等。任何身份都有各自的管理域以及安全防护措施。在这样的场景下, 身份提供商和个人都承担着高代价的身份维护成本, 并面临较大风险。在云计算的环境中, 这种场景比比皆是。随着云计算的普及, 身份爆炸的问题将愈演愈烈, 这一切引起了人们对互联网时代“身份”的思考。

1.2 联合身份的思想

面对身份爆炸的问题, Register Once, Use Anywhere (一处注册, 到处使用) 的想法呼之欲出, 这也是未来身份管理的趋势。和这种想法相关的有两种概念:代理身份认证和联合身份认证。代理身份认证是指不再建立自己的认证系统, 而是外包, 或者下放到更多的知名企业, 比如Google, Facebook。联合身份认证则是一种分布式的, 不依赖于任何一个特定身份提供商的方案, 典型的协议如Open ID[4]。

1.3 平台即服务 (Paa S)

云计算服务可以分为六类[5], 分别是基础设施即服务Laa S (Infrastructure as a Service) 、网络即服务Naa S (Network as a Service) 、平台即服务Paa S (Platform as a Service) 、身份及策略管理即服务IPMaa S (Identity and Policy Management as a Service) 、数据即服务Daa S (Data as a Service) , 软件即服务Saa S (Software as a Service) 。作为其中的一种, Paa S提供给用户的能力是在云基础设施之上部署用户创建或部署应用, 这些应用使用服务商支持的编程语言或工具开发, 用户并不管理或控制底层的云基础设施, 包括网络、服务器、操作系统或存储等, 但是可以控制部署应用, 以及应用主机的某个环境配置[1]。目前互联网企业主导面向公众服务的著名公有云Paa S平台有Google App Engine[6]和Force.com[7]。

只支持本地身份的Paa S会在其业务拓展上遇到瓶颈, 让用户省去注册的步骤并直接兼容用户已有身份是未来互联网发展的趋势。认识到这点的Paa S服务提供商 (服务提供商并非等价于身份提供商) 除了接受传统的本地身份以外也开始能接受其他多样化的身份, 比如Google engine app上的应用既支持使用本地身份, 即Google账号, 进行访问, 也支持Open ID的身份进行访问。

虽然Paa S面对身份爆炸问题开始对自身进行调整以应对, 但解决方案仍不够理想, 比如Google engine app目前还不能同时兼容多种身份访问同一App。除此之外, Paa S上的各应用相对独立地认证其用户的办法较为低效。用户访问相近应用需多次进行认证, 同一位开发者的不同应用之间存在着认证协同度不够的问题。Paa S急需有种方式能够低代价地满足同一位开发者开发多个相对独立的、但却又有相同/相近身份认证的需求。

2 相关认证协议

本模型借鉴了Kerberos协议以优化认证流程, 并且参考了Open ID认证协议以兼容Open ID身份。下文中会介绍与本模型相关的这些协议。

2.1 Kerberos协议

Kerberos身份认证协议由MIT开发, 现今主流版本是Kerberos V5[9]。Kerberos V5身份认证机制主要体现在其用于访问网络服务的票据 (Ticket) , 其实就相当于现实生活中的“门票”, 资源在验证“门票”后方可访问。

Kerberos的认证流程包括三个步骤:

1) 鉴别访问交换:获得票据许可票据。

2) 票据许可服务交换:获得服务许可票据。

3) 客户/服务器鉴别交换:获得服务。

Kerberos解决的问题[10]: (1) 用户可以最小化其登录的次数以满足多次登录不同的服务需求。 (2) 不涉及口令的明文传输。

Kerberos的局限性在于Kerberos认证前假设每个用户的口令都已储存在认证服务器端, 双方的认证是基于预共享口令, 这点局限了Kerberos的应用。

2.2 Open ID

著名的开放标准Open ID实现了联合身份认证[4]。目前Google、Yahoo、Flickr、AOL、Facebook等都支持Open ID服务。

在Open ID的标准中存在两种重要的角色, 身份提供者OP (Open ID provider) 以及依赖方RP (relaying party) 。OP创造身份和其相应凭据, 并提供该身份的认证服务。RP是资源供应方, 它有认证需求, 其认证依赖于第三方 (对应OP) 的协助。一个典型的例子是Google为某用户创建了Open ID的账号, 然后该用户使用这个账号登陆了另一支持Open ID的网站sample.com的应用, 在这个例子中Google是OP, 而sample.com则RP。

Open ID的大致协议流程如下:

1) 用户向RP发起认证请求。

2) RP与OP建立一个关联, 或者说安全通道, 用于传输信息并降低交互次数。例如基于Diffie-Hellman密钥交换协议。

3) RP将用户重定向到OP, 请求OP认证用户的身份。

4) OP进行身份认证。

5) OP将用户重定向回RP, 并利用之前建立的安全连接告知该用户是否通过了认证。

6) 如果被身份提供方告知用户的身份合法, 则RP允许用户访问其服务。

上述认证过程的核心思想是RP依靠OP来对用户进行身份认证。

3 Paa S环境下的身份认证服务模型

为了满足Paa S上应用程序对身份认证的需求, 本文设计了一种身份认证服务模型, 提供Paa S服务的云计算服务商可以使用这种模型来为其上的应用提供高效、灵活、易扩展的身份认证服务。

3.1 Paa S上应用程序对认证服务的需求

应用程序App开发者在Paa S云平台上开发了自己应用程序, 例如App1和App2。应用程序在功能上相对独立, 并且使用不同的语言开发, 但通常其身份认证需求是相近的。随着身份种类的增多, 身份认证问题变得越发复杂。开发者希望Paa S平台能够提供身份认证服务, 以使得开发者只需简单调用API便能够对用户进行身份认证, 即依赖于类似IPMaa S服务[8]。

访问App的用户希望免去在Paa S提供商处注册本地账号的步骤, 直接使用已有的通用账号进行登录, 比如Open ID。用户拥有的身份爆炸性地增多, Paa S系统也应有易扩充的能力来支持更多身份类别的身份认证以拓展业务。

开发者需要配置其应用程序的访问策略, 例如:对于app1, 开发者希望只有本地身份才可以访问;对于app2, 开发者希望本地身份以及Open ID身份都可以访问。这种访问规则可以抽象为用户类别到可访问程序的映射。

对于使用应用程序的用户来说, 不管其拥有的身份如何, 总希望在访问应用时能减少认证次数。认证次数的减少意味着密钥使用频率的下降, 这一点除了能够提高系统效率, 还能够显著提高安全性。

3.2 身份认证服务模型框架

图1给出Paa S环境下身份认证模型框架。

下面是对该认证服务模型各要素的说明。

开发者:借助云平台开发应用app服务。开发者指定其应用程序的访问策略。

用户 (custom, C) :包括本地用户和Open ID用户, 还可以扩展为其他多种身份的用户。本地用户指在Paa S平台注册的用户;Open ID用户指根据Open ID协议在某OP处注册身份的用户。

Paa S云平台:对开发者提供Paa S服务以部署应用程序。

密钥分发中心:包括鉴别服务器AS (Authentication Server) 和票据许可服务器TGS (Ticket Granting Server) 。根据开发者的访问策略对用户进行认证并分发票据。

鉴别服务器AS (Authentication Server) :负责认证用户身份, 并分发票据许可票据TGT (Ticket Granting Ticket) 。在Open ID协议中, AS充当了RP的角色。

票据许可服务器TGS (Ticket Granting Server) :验证TGT并负责分发访问app的服务许可票据 (Ticket) 。

应用程序App (application) :开发者利用Paa S服务开发的应用程序, 以供用户访问。访问应用程序需要TGS分发的服务许可票据 (Ticket) 。

模型重要的交互如表1描述。

3.3 认证流程

用户认证是模型的核心部分。文章设计的认证流程借鉴了Kerberos协议, 用户访问应用程序需要经过三个步骤。

第一步 (1、2、3) 鉴别访问交换:访问KDC的AS以验证身份并获得TGT, 验证的方式根据其身份所属的协议不同而有所差异。第二步 (4、5) 票据许可服务交换:访问KDC的TGS, 用TGT换取服务许可票据。第三步 (6) 客户/服务器鉴别交换:用服务许可票据访问app的服务。

1) 鉴别访问交换

在第一步鉴别访问交换中, 用户既可以用本地身份登录也可以使用Open ID身份登录, 随着系统的扩展还可以使用更多的其他身份登录。如果使用本地身份, 那么用户类似传统方式在Paa S服务商注册, 此后用户和AS根据注册时创建的共享口令按照Kerberos v5的鉴别访问交换协议进行认证。如果使用Open ID身份, 则用户和云平台的身份认证工作需要由OP协助完成。Kereros5协议的鉴别访问交换的前提是用户和AS已共享密钥, 而在Open ID协议中却是另一种场景。用户在OP处注册Open ID身份, 使得只有OP拥有对用户进行认证的能力。此时用户访问作为RP方的Paa S服务商, RP并没有和用户共享密钥。RP对用户的身份认证必须依照Open ID协议引入OP方的协助。基于上述考虑需要对Kerberos的鉴别访问交换进行修改, 具体认证流程如下:

Step1C利用Diffie-Hellman协议生成公私钥对 (Pric, Pubc) 。

Step2 C向AS申请TicketTGS。

Step3 AS、OP、C三方依据Open ID的协议标准进行认证, 成功认证后AS信任C符合其声称的身份。

Step4 AS利用Diffie-Hellman协议生成公私钥对 (PriAS, PubAS) 。

Step5 AS分发TicketTGS。

表2是对认证过程中的符号的解释。

上述认证流程中Step 1至Step 5是对原Kerberos中鉴别访问交换的修改。Step 1和Step 4使用Diffie-Hellman协议, 以生成C和AS间的临时共享密钥KC, AS, 这点是为了弥补C和AS并未共享密钥。该密钥的意义只是在于加密票据许可票据TicketTGS, 实现了保密性, 但没有身份认证的功能。

Step 3是Open ID认证流程的概括。在这一步之前AS收到了来自C的访问请求, 并发现C使用的是Open ID身份, 随后开始启动Open ID认证。Open ID认证流程是以OP向AS传递“C身份符合其声称”的消息结束。AS信任C后开始其后的认证流程。

如果希望支持更多的身份以访问应用, 只需根据身份所参照的协议修改鉴别访问交换阶段即可, 这体现了本模型对于更多身份类别的可扩展性。

鉴别访问交换阶段结束后, C得到了票据许可票据TicketTGS。

2) 票据许可服务交换

Step 6用户向TGS提交票据许可票据并要求获取服务许可票据。

Step 7 TGS验证票据许可票据后, 返回服务许可票据。

票据许可服务交换独立于AS的鉴别过程。应用程序的开发者事先定义了访问的策略, 并由TGS存储授权该策略。在票据许可服务交换阶段, TGS依据开发者定义的授权信息来分发具体应用的服务许可票据TicketV。

3) 客户/服务器鉴别交换

Step8客户提交服务许可票据并访问服务。

通过客户/服务器鉴别交换, 用户使用服务可使用票据TicketV访问应用程序V。

3.4 模型优势

1) AS和TGS的设计使得用户多次访问同一位开发者的不同app应用时无需反复进行身份认证。用户只需通过一次身份认证以获得TGT, 随后针对不同的app用TGT换取应用程序对应的ticket, 减少了用户口令的使用频度。

2) 兼容了本地身份以及Open ID, 并对其他的身份兼容也有很好的扩展性。当系统需要支持更多的身份类别时, 只需要在鉴别访问交换阶段增加认证方式。

3) Paa S的身份认证服务使得应用程序开发者从越发复杂的身份认证问题中解脱出来, 能够专注于应用的开发。

3.5 认证方案安全性分析

主要分析认证方案中鉴别访问交换阶段的安全性, 其他阶段的安全性依赖于kerberos协议。

1) 信任链

在Open ID用户登录时, AS由于信任OP, 而OP认证了用户身份合法, 所以AS通过了Open ID用户的认证。

2) 网络钓鱼攻击

Open ID用户登录时, 攻击者伪装成OP获取用户口令。这种网络钓鱼攻击是否可行依赖于Open ID协议本身的安全性。

本地用户登录时, 攻击者伪装成票据许可服务器获取用户口令。本认证协议继承了kerberos双向认证的设计, 杜绝了这种网络钓鱼可能性。

4) 网络窃听

认证协议没有涉及到任何私钥的传输;共享密钥都以加密形式传输, 其中Open ID用户和AS交互时利用了Diffie-Hellman协议构建了安全信道;能够窃听到的公钥信息不会破坏机密性。

5) 重放攻击

时间戳的设计使得重放攻击被限制在很短的时间内。

4 结语

本文提出的身份认证模型能够在Paa S环境下很好地为开发者提供认证服务。开发者的用户可以使用包括多种身份访问应用程序, 其身份认证过程灵活高效。本文还特别论述了认证方式如何兼容Open ID。这种身份认证模型有着很好的可扩展性以及灵活性, 低代价地满足了同一位开发者开发多个相对独立的、但却又相同/相近身份认证的需求, 为优化Paa S环境下的身份认证问题提供了一种可行思路。

摘要：作为云计算的一种模式, PaaS为开发者的应用程序提供运行平台, 平台提供的服务也包括身份认证服务。在身份日益繁多的云计算时代, 身份认证问题愈发复杂。提出一种PaaS环境下的身份认证模型, 该模型使PaaS云服务提供商为其上的应用程序提供高效灵活的身份认证服务。该模型的优势在于低代价地满足同一开发者开发多个相对独立的、但却又相同/相近身份认证的需求;兼容本地身份以及代表联合身份认证趋势的OpenID身份, 并有很好的扩展性以兼容更多类别的身份;认证过程借鉴了Kerberos协议来减少用户认证次数。

关键词：云计算,身份认证,平台即服务

参考文献

[1]Melland P, Grance T.NIST definition of cloud computing[C].National Institute of Standards and Technology.October7, 2009.

[2]Shilpashree Srinivasamurthy, David Q Liu.Survey on Cloud Computing Security-Technical Report[D].Department of Computer Science, Indiana University Purdue University Fort Wayne July 2010.

[3]Archer J, Boehme A, Cullinane D, et al.Top Threats to Cloud Computing[R].Cloud Security Alliance, 2010.

[4]OpenID web site[OL].http://www.openid.net.

[5]Minqi Zhou, Rong Zhang, Dadan Zeng, et al.Services in the Cloud Computing Era:A Survey[C]//4th International Universal Communication Symposium, 2010.

[6]Google App engine[OL].http://code.google.com/appengine/.

[7]SaleForce.An overview of force.com security[EB/OL].http://wiki.developerforce.com/index.php/An_Overview_of_Force.com_Security.

[8]Emig C, Brandt F, Kreuzer S, et al.Identity as a Service-Towards a Service-Oriented Identity Management Architecture[R].Lecture Notes in Computer Science, 2007.

[9]Neuman B C, Theodore Ts'o.Kerberos:an authentication service for computer networks[J].Communications Magazine, 1994, 32 (9) :33-38.

PaaS论文 篇5

在众多的物流企业竞争角逐中，企业能否脱颖而出，主要取决于企业如何快速和高效地适应市场的变化。一个想要打造成能快速适应变化的企业迫切需要一个灵活的系统，能够最大化地接近客户，能够响应客户的动态需求，帮助企业抓住动态的商业机会。所以，企业的业务处理必须走出企业自己的范围，同多个客户和合作伙伴进行协调。例如，一个国际货运代理公司的业务，通常跨越了企业边界，它的使用角色除了企业内部的操作、单证、客服、财务、销售、管理者外，还包含整个供应链上的上下游企业，如货主、同行、车队、报关行、海外代理、收货人等。传统的IT方式下，无法在这些跨企业的业务中实现自动化服务。客户必须手动的发送订单，检查库存，并给挨个给供货商发邮件或者打电话。这一切在云计算平台下都能很好地加以自动实现。从商务人员的角度来看，云计算不是一个企业门户系统，不是一个供应链管理系统，而是一个商务圈和增值链，是一个企业与客户、企业与合作企业的社交网络。[1]

在传统的物流行业中，人们实施的物流信息管理系统，物流配送系统，进销存和库存管理系统，绝大多数都是以一种内部系统的形式进行构建。同时，部署这些应用软件是一件非常复杂，昂贵并且充满风险的事。需要自行组装每个应用程序所需的硬件，操作系统，数据库，中间件，Web服务器，和其他软件。每个物流企业都需要培养一支包括网络，数据库，系统管理方面的专家团队来保证应用软件日常的正常运行。一旦新业务的出现需要改变原有应用系统，一个漫长的开发过程就周而复始地开始了。

2. 云计算在物流领域的应用

物流领域中的云计算，可以让物流企业根据自己的实际规模和需求，动态地从因特网的云端选择相应可视化的资源和服务，从而满足本企业在日常运营过程中的各项IT服务的需要。

IBM智慧的“物流云”就提出了类似的概念。它提供了一个基于云计算技术的智慧物流方案，可以把物联网运用于物流领域，就会全面进步货物装卸、运输、仓储、检修和通关的智能化水平，实现物流业的高效、快捷、集约、透明，节约管理成本，提高管理水平。

作为云软件服务和应用开发的平台———PaaS (Platform as a serice) ，它一方面提供构建和运行软件服务的平台，同时，另一方面它负责管理所有的硬件和软件资源，通过Internet为客户提供按需的，基于Web的软件解决方案。

PaaS提供所需的所有运行在互联网应用基础设施。用户只需“打开水龙头”获取服务，他们不用担心幕后的复杂性。PaaS是基于订阅模式，所以用户只需为他所使用的功能付费。利用PaaS，独立软件开发商和企业IT部门能够更专注于创新，而不是复杂的基础设施。物流企业可以将预算更多地投入到能提供真正的商业价值的地方，而不是基础设备的购买和养护。

3．云计算系统及平台发展现状

目前，Amazon、Google、IBM、Microsoft、Sun等公司提出的云计算基础设施或云计算平台，开源组织和学术界也纷纷提出了许多云计算系统或平台方案。[2]

3.1 Google的云计算基础设施

Google的云计算基础设施[3]是在最初为搜索应用提供服务基础上逐步扩展的，主要由分布式文件系统GoogleFile System (GFS) [4]、大规模分布式数据库BigTable、程序设计模式MapReduce、分布式锁机制Chubby等几个相互独立又紧密结合的系统组成。

3.2 IBM“蓝云”计算平台

IBM的“蓝云 (blue cloud) ”计算平台[5]是由一个数据中心、IBM Tivoli监控软件 (Tivoli monitoring) 、IBM DB2数据库、IBM Tivoli部署管理软件 (Tivoli provisioning manager) 、IBM WebSphere应用服务器以及开源虚拟化软件和一些开源信息处理软件共同组成。

3.2 Sun的云基础设施

Sun提出的云基础设施体系结构包括服务、应用程序、中间件、操作系统、虚拟服务器、物理服务器等6个层次，其提出了“云计算可描述在从硬件到应用程序的任何传统层级提供的服务”的观点。[6]

3.4 微软的Azure云平台

微软的Azure云平台包括4个层次。底层是微软全球基础服务系统 (global foundation service, GFS) ，由遍布全球的第四代数据中心构成；云基础设施服务层 (cloud infrastructure service) 以Windows Azure操作系统为核心，主要从事虚拟化计算资源管理和智能化任务分配；Windows Azure之上是一个应用服务平台，它发挥着构件 (building block) 的作用，为用户提供一系列的服务[7][8]

3.5 Amazon的弹性计算云

Amazon是最早提供云计算服务的公司之一，该公司的弹性计算云 (elastic compute cloud, EC2) 平台建立在公司内部的大规模计算机、服务器集群上，平台为用户提供网络界面操作在“云端”运行的各个虚拟机实例 (instance) 。

4. 基于SOA的云计算平台框架

各个云计算平台也各自具有不同的特点．特别是在平台的使用上，透明计算平台为用户同时提供了用户实际接触的客户端节点以及无法接触的远程虚拟存储服务器。是一个半公开的环境．Google的云计算平台环境是私有的环境，除了开放有限的应用程序接口，例如GWT (GoogleWebtoolkit) ，GoogleAppEngine以及GoogleMapAPI等以外，Google并没有将云计算的内部基础设施共享给外部的用户使用．IBM的“蓝云”计算平台则是可供销售的软、硬件集合，用户基于这些软、硬件产品构建自己的云计算应用．Amazon的弹性计算云则是托管式的云计算平台，用户可以通过远端的操作界面直接操作使用，看不到实际的物理节点。从其他角度比较了各个云计算系统的不同之处．可以看出，虽然云计算系统在很多方面具有共性，但实际上各个系统之间还是有很大不同的，这也给云计算用户或者开发人员带来了不同的体验．

针对这些云计算平台，我们在设计基于SOA的云计算平台的体系结构时。将包括硬件和系统软件在内的多个层次。总体而言，大致可以分成如下三层：

4.1 硬件平台

硬件平台就是俗称的Iaas，它主要面向用户提供虚拟化的计算机资源，存储资源，网络资源。包括服务器、网络设备、存储设备等在内的所有硬件设施，它是云计算的数据中心。硬件平台首先要有可扩展性 (Scaling) ，用户可以假定硬件资源无穷多。根据自己的需要，用户动态地使用这些资源，并根据使用量来支付服务费。不需要为需要购买维护多少设备来支持当前访问量而犯愁。

在设计硬件平台的虚拟技术显得尤为重要，它可以让多个操作系统共享一个大的硬件设施，使得硬件平台的提供者能灵活地提供各类云平台的硬件需求。常见的有收费的虚拟技术（如:VMware），也有免费的开源技术（如：Xen）。

4.2 云平台

这里的云平台专指Paas，它提供服务开发工具和基础软件（如：数据库、分布式操作系统等），从而帮助云服务的开发者开发服务。另外，它也是云服务的运行平台。所以，云平台需要具有Java运行库、Web2.0应用运行库、各类中间件等。

4.3 云服务

云服务就是指可以在互联网上使用一种标准接口来访问的一个或多个软件功能。它有点类似于之前提出的“软件即服务Saas”。但是与Saas不同的是，传统的“软件即服务”的系统需要服务提供商自己提供和管理硬件平台和系统平台，而云计算平台上的云服务，不需要提供硬件平台和云平台。客户可以通过互联网随时随地访问各类服务，从而访问和管理自己的业务数据。而不需要到客户现场去安装和调试软件，配置服务器等操作。[9]

很多厂商已经提供了上述的某些平台。如IBM的Smart Business Storage Cloud和亚马逊的EC2主要是一个云计算的硬件平台（硬件作为一个服务），Google的Application Engine主要是一个云平台，Salesforce则是云服务的提供商。

总而言之，通过虚拟化的方式，云计算平台就能够极其灵活地满足各类需求，而不受硬件的局限。在实现自己的云计算硬件平台时，主要需要考虑存储结构，这不仅仅需要考虑存储的容量，更重要的是需要考虑磁盘数据的读写速度。单个磁盘的速度很有可能限制服务程序对于数据的访问，因此在实际用过程中，需要将数据分布到多个磁盘之上，并通过对于多个磁盘的同时读写以达到提高速度的目的。此外，数据如何放置也是一个非常重要的问题，GoogleFileSystem的集群文件系统和基于块设备的存储区域网络（SAN）系统提供了两种可行的存储技术。开源的Hadoop HDFS (Hadoop Distributed File System）实现了类似GoogleFileSystem的功能，提供了一个实现硬件平台的解决方案的参考。

参考文献

[1]司品超, 董超群, 吴利, 张超容.云计算:概念, 现状及关键技术.2008年全国高性能计算学术年会论文集, 2008

[2]计世资讯.2009中国云计算发展状况白皮书, 2009

[3]Luiz Andre Barroso, Jeffrey Dean, Urs Holzle.Web search for aplanet:the Google cluster architecture.In:IEEE Micro, 2003

[4]Sanjay Ghemawat, Howard Gobioff, Shun-Tak Leung.The Google file system.In:Proc of the 19th ACM SOSP, New York, ACMPress, 2003

[5]智慧的地球——IBM动态基础架构白皮书.http://www.ibm.com/cn/express/migratetoibm/dynamicinfrastructure/download/dynamicinfrastructure_whitepaper_0903.pdf

[6]SUN, Introduction to Cloud Computing architecture[EB/OL]., 2009.06.http://developers.sun.com.cn/blog/functionalca/resource/sun_353cloudcomputing_chinese.pdf

[7]Microsoft.微软云计算解决方案白皮书[EB/OL].2009.12.http://wenku.baidu.com/view/b7c6f011f18583d0496459f4.html

[8]张亚勤.与云共舞——微软云计算的新进展.中国计算机用户, 2009, (2) :12～13

PaaS论文 篇6

云计算目前还没有一个明确的定义, 但它的一些特征是大家共识的。云计算以虚拟化技术为基础, 通过网络载体提供用户基础设计架构、开发平台和服务软件等。云计算是IT产业链的一次重构, 用户就像使用自来水或煤气一样按需付费来使用“资源池”中的资源, 云计算的主要任务其实就是计算和存储, 其余工作交给不同的服务商去提供。

云计算的3种类型服务, Iaa S主要指基于传统IT基础设施提供的服务, 包括计算服务, 存储服务和网络服务。PaaS主要指开放给第三方的应用平台与运行平台, 用户通过这个环境的接口进行编程和软件测试。SaaS主要包括典型的办公软件和管理软件, 服务商以Web服务的方式向用户交付Saa S服务。

2、云计算的PaaS

PaaS (Platform as a Service平台即服务) 通过提供应用服务引擎, 互联网应用程序接口/运行平台等, 使得用户基于该服务平台, 可以为用户提供应用软件的开发、测试、部署和运行环境的服务。PaaS将软件开发人员和IT运行维护人员对设备的日常维护中解放出来, 将所有环境的部署都外包给云计算的PaaS平台, 并按需付费。

PaaS云平台一般具备四大功能:友好的开发环境、丰富的服务、自动的资源调度、精细的管理和监控。

目前有部分厂商和运营商在以上技术上有所探索, 但是尚无商业的完整产品, 相信以上关键技术的突破将对PaaS发展具有重大推动作用。

3、全球主要的PaaS云服务模式

Saleforce Force.com

Salesforce.com是最早提供软件即服务 (SaaS) 的先驱, 提供通过网络访问自动化应用软件的服务。2008年1月, Salesforce.com推出随需应变平台Force.com, 这是世界上第一个平台即服务的应用———PaaS。

作为一个提供在线服务的开发平台 (Platform as a Service) , Force.com是可供独立软件开发商 (ISV) 开发应用程序, 以Salesforce.com的Appexchange作为底层, 类似中间件。Force.com是一个随需应变的平台, 可以使构建、共享、运行业务应用程序的过程比以前更加简单。

Google App Engine

Google公司以企业搜索、托管等形式向组织或个人推出了Google App Engine。Google在Google Apps的基础上进一步发力, 于2008年推出了Google App Engine这项PaaS服务, 它让用户在自己的基本架构上运行自己编写的网络应用程序, 且基于App Engine的应用程序易于构建和维护, 并可根据用户的访问量和存储的需要经行扩展。

Google App Engine是一个典型的云计算平台, 它基于Google的全球分布式框架, 支持通用的Web应用开发语言, 具备极好的扩张性。通过SDK提供Google的各种服务, 如Google Maps、GMail和数据存储等。用户可快速、廉价 (可免费使用限定的流量和存储) 地部署自己开发的应用 (如创新的网站、游戏等) 。

Amazon AWS

Amazon是迄今为止最成功的Iaa S提供商。Amazon推出云计

算服务的起源是它为了充分利用其闲置的IT资源, 推出了AWS (Amazon Web Services) 云服务。AWS着力于Iaa S的底层建设, 在网络互联的需求之上共享出亚马逊IT基础架构, 如计算、存储、内容开发等。AWS是一个多种服务的集成平台, 但是每项服务都可以单独使用而不会相互绑定。在技术层面, 这些服务的实现都相当底层。

Microsoft Azure

Microsoft的云计算主要在PaaS和SaaS两方面。Microsoft的Bing、Windows Live、Microsoft Office 365、XBOX Live等产品属于SaaS服务。这些产品直接以服务的形式供应软件, 供最终用户使用。

Azure是继承Windows取代DOS之后, 微软的又一次重大变革, 借助使用Windows桌面和浏览器的用户, 通过互联网架构打造新的云计算平台。借助微软优越的服务器和网络基础架构, 该平台通过网络为用户提供服务。它由具有高扩展性的云操作系统、数据存储网络和相关服务组成, 同时, 平台附带Windows Azure SDK (软件开发包) 提供了一整套开发、部署和管理Windows Azure云服务所需要的工具与API。

4、云计算PaaS对IT产业的影响

PaaS服务能发挥“群众的集体智慧”, 能为更多的软件编程人员提供优良的土壤, 能促使更多更好服务企业社会的软件产生, 同时能使软件的使用成本降低, 大大激发中小IT企业的创新动力。

云计算产业链包含云计算提供商 (第一产业) 、云计算应用服务提供商 (第二产业) 、云计算延伸产业及增值服务提供商 (第一产业) 。云计算的第二产业是非常活跃的, 它的面非常广, 任何基于云计算平台的应用都可以成为第二产业。云计算第二产业是云计算核心创造力迸发的地方, 云计算的所有优势都是通过第二产业迸发出来的。云计算给中小企业提供了一个重要的战略机会, 中小企业只需要购买有限的固有资源, 其他资源只要付费向云中心申请就能来满足客户的需求。PaaS的被广泛的应用将为中国IT的创新大爆发提供强有力的动力, 大量的应用将被创造出来, 这会深刻改变目前IT产业被国外大企业控制的产业格局。

5、PaaS未来发展方向

PaaS作为云计算的关键层, 是目前云计算关注的重点, 也是个大运营商竞争的主战场。目前国内外个大运营商都在自己的PaaS方面进行研究和探索, 同时积极推进商业服务, 但其服务和我们对其要求还是有一定差距。运营商结合自己的优势打造自己风格的服务平台, Salesforce和Goolgle的PaaS主要为了丰富平台上运行的应用软件, 尽可能多的吸引用户使用其平台;而微软则希望通过云计算笼络人气, 保持其在IT界的老大地位。不管怎样, PaaS的目的就是利用服务平台聚拢软件, 为多种顾客提供服务, 所以未来PaaS在不断向用户提供软硬件资源服务接口的同时, 更应该是倡导开源精神, 提供更加便捷和经济的平台环境, 同时要降低用户的入门条件, 让更多的人来使用PaaS, 让所有程序设计的创新源泉不断聚集和更新, 让技术不断演绎精彩。

摘要：本文在定义云计算及其特点的基础上, 分析了市场上目前主流的PaaS, 并对由此产生的IT产业的变革进行了阐述, 以及对未来PaaS的发展进行了展望。

关键词：云计算,PaaS,IT产业

参考文献

[1]雷葆华, 饶少阳等.云计算解码[M].电子工业出版社, 2011.

[2]毛麾民.浅谈云计算及其发展[J].技术与市场, 2011 (10) .

[3]王鹏.问道云计算[M].人民邮电出版社, 2011.

PaaS论文 篇7

1.1 背景

随着社会经济及科学技术的飞速发展,计算机网络的逐渐普及,各行业纷纷在IT建设方面投入了大量的资金,建立起多种业务系统。目前,在构建这些业务系统时,一般都是采用“独立解决方案”来实施的。系统之间相互独立,“各自为政”,缺乏整合,业务数据交换困难,难以形成有效利用的共享资源。这既不满足企业业务需要,又彼此间不能互联,形成了所谓的“信息孤岛”。因而需要一个能够将现有各种业务系统进行整合的平台,该平台向下根据业务能力需要测算运维基础服务能力、调用安全产品、操作系统以及硬件等其他资源,向上为各业务系统提供调度中心等服务,实时监控整个网络的各种资源、并将这些资源开放给上层资源用户,来满足企业实际工作需要,进而使信息化系统在企业工作中发挥出更大的效益。

1.2 概述

本文设计了一种基于Paa S和ESB的分布式集群框架服务平台。它是基础资源和业务系统的纽带,是一种面向基础设施架构的服务框架,其核心是基础资源平台即服务(Paa S),并将这些异构环境中的服务基于中间件技术进行交互(ESB)。在分布式集群所提供的环境中,各种业务应用能够长时间稳定高效的运行。该平台主要提供集群接口服务、集群共享服务、集群调度服务、集群消息总线、集群自助服务、集群管理服务等,平台服务框架如图1所示。

2 关键技术简介

2.1 Paa S

Paa S(Platform-as-a-Service),平台即服务,是一种把服务器平台作为服务,提供企业进行定制化研发的中间件平台,它能提高Web平台上利用的资源数量,将现有各种业务能力进行整合,向下根据业务能力需要测算基础服务能力,通过Iaa S提供的API调用硬件资源,向上提供业务调度中心服务,实时监控平台的各种资源,并将这些资源通过API开放给应用软件用户。

2.2 ESB

ESB(Enterprise Service Bus)是传统中间件技术与XML、Web服务等技术相结合的阐述,用于实现企业应用不同消息和信息的准确、高效和安全传递。它能够支持服务注册以及寻址管理,确保通过企业总线互连的业务流程间的消息正确交付;提供位置透明的路由和定位服务,提供多种消息传递形式,支持广泛使用的传输协议。采用多服务集成方式,支持服务和事件管理。

2.3 负载均衡

负载均衡技术是用于解决大量的并发访问情况下,将数据流量分担到多台节点设备上分别处理,减少用户等待响应的时间,它提供了一种廉价又有效的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。

2.4 失效转移

失效转移(failover)是一种通过集群实现的备份操作模式,当连接的组件由于各类不可预测的原因失效或无法工作时,failover模式能够自动从集群中其他的组件中选择另一个来代替出现故障的组件。对于希望使系统具有更高的故障容忍力,失效转移(failover)是被经常使用的策略。

3 平台功能设计与实现

本文在功能上将着重讲解本平台的集群调度服务、集群消息总线、集群自助服务和集群共享服务等四方面主要功能的设计思路和实现原理。

3.1 集群调度服务

本平台设计了一个集群调度服务器来扮演平台指挥官的角色,它能够做到实时了解平台上所有服务模块和服务节点运行状态,对服务请求按照一定的策略进行均衡分配,避免某个服务模块调用过热或过冷,满足外界对平台服务的需求。具体实现功能如下:

3.1.1 服务节点调度

分布式集群服务框架平台的服务节点可以是虚拟机也可以是实体机,并将服务节点划分成集群接口服务器、集群服务平台、分布式文件系统节点、分布式数据库节点、集群消息总线服务器、集群文件镜像服务器、集群统一鉴权服务器。集群调度服务作为整个平台的调度中心通过注册知道每个服务节点的类型,只有注册的服务节点才能归纳到整个服务平台中来,才能被集群调度服务用于提供服务的一个节点。

3.1.2 服务节点检测

服务节点注册完毕后,调度服务对每个服务节点连接状态进行实时监控。如发现与服务节点已经失去连接,即对注册信息进行冻结,外部暂时访问不到该服务节点上的服务,同时服务节点也会接受到断开连接的通知进行重新连接;如果在规定时间内服务节点没有重新连接到调度服务器,调度服务器将删除该服务节点的注册信息,超时后服务节点再次连接到调度服务器后就是重新注册的。

3.2 ESB集群消息总线

分布式集群框架服务平台内部模块之间的通讯通过设计实现一种ESB集群消息总线功能来完成。消息总线将各个服务模块按照统一的消息协议连接起来,并在服务模块之间传递消息,它扮演着一种消息路由的角色,拥有一套完备的路由机制来决定消息传输方向。在通信中使用TLS (Transport Layer Security)协议作为通信通道的加密方法,保证通信的安全。

3.2.1 消息总线负载均衡

图2给出了该平台集群消息总线负载均衡技术的工作原理。在消息客户端和消息服务器之间,部署一个重定向服务器,如果消息客户端希望和消息服务器建立连接,首先向重定向服务器发出连接请求,重定向服务器根据预先配置策略(包括轮询、权值、负载状况等策略)决定返回最优的消息服务器地址,然后,消息客户端可以根据返回的消息服务器地址,建立与消息服务器的直接连接,并进行消息的传输。通过重定向服务器可以解决大量的并发访问情况下,将数据流量分担到多个消息服务器上分别处理,增加系统的处理能力,减少用户等待响应的时间。

3.2.2 消息总线失效转移

图3给出了平台集群消息总线失效转移技术的工作原理,消息客户端使用failover模式配置一组消息服务器地址组成消息服务器集群,failover协议首先根据策略从集群中选择一个最优的消息服务器并与之建立连接,在消息传输过程中,如果该消息服务器出现故障,能够自动从其他的消息服务器地址中选择另一个来代替出现故障的消息服务器,实现消息连接的自动迁移,有效保证了系统的稳定性和可靠性。

3.2.3 消息总线传输方式

消息总线为各个模块之间的交互提供了一个松耦合的实现方案,例如:在展现门户、分析服务器、采集服务器中传递的各类命令、通知、报告等即时信息都可以封装为消息通过消息服务器进行传输,传输方式支持消息队列和主题订阅两种模式。其中,消息队列执行路径如图4所示。

3.3 集群自助服务

分布式集群服务框架平台设计了集群自助服务,即服务提供了一种简易的编程规范,开发人员按照该规范编写的程序包就会被平台所接受,并自动发布成接口服务。同时,接口发布者还可以对接口进行开启、关闭、调试、废弃等操作。而且,平台用户还可以对发布的程序包进行版本控制,同时还可以根据每个程序包的版本来对程序包重新上传和发布。在这个过程中,平台做到了对发布服务进行全程可视化管理,收集被授权用户信息和服务调用信息,并以简洁明了的显示方式将这些信息提供给服务发布者,以便服务发布者能对自己的服务进行更好的管理。平台上的服务通过Schema和Contract发布,而不是Class和Type。图5给出了在平台上扩展加载监控组件所需的配置项。

3.4 集群共享服务

平台所提供的集群共享服务,是通过为运维基础服务的内网安全产品开放了以下接口来实现的:用户身份认证服务、用户管理服务、会话管理服务、日志管理服务、访问控制服务、监控服务、数据源管理服务、资源管理服务等。在此给出部分接口相关实体:

可见,集群共享服务是本平台的基础服务,对平台用户、平台服务、平台资源能够进行有效的管理和运作,从而达到了本平台的设计初衷。

4 平台特性

4.1 分布式运作模式

该平台上的服务模块都不是单一的服务节点,而是采用多机组成集群部署来提供服务,并能根据可用网络情况,在多网段进行服务部署。通过分布式运作模式能够允许系统发生部分故障,这些故障应当能被很好地处理而不影响其他不相关的部分或整个系统。具体该平台的容错实现方式如下:在多个节点或网络上提供重复的服务,让冗余性有助于将单节点失败的影响控制在最小范围内,这样就可以显著的提高系统在出现部分故障时的可靠性,使整个平台横向和竖向扩展成为可能。

4.2 弹性部署方式

分布式集群框架服务平台采用弹性部署方式,即默认情况下在三个服务节点上部署同样的服务模块,每个服务模块都具有相对的独立性,服务的调用都依赖调度中心来分配,每个服务模块都有自己独立的运行环境,服务把各自的信息注册到调度中心即可,服务之间没有直接的联系。具体描述为:由分布式集群框架服务平台对每个服务模块访问流量进行实时监控,当平台上的某个服务在某个时间段内访问突然增加,服务平台认定在现有的服务部署状态下不能满足目前的调用需要,服务平台将自动增加该服务模块的部署数量来满足目前的需求,并能在需要的时候恢复原来的部署数量,释放资源,把资源提供给其他需要扩大部署数量的服务。调用负荷持续走低的情况下,集群调度平台撤销掉服务模块个数,释放资源,为其他需要弹性增加服务模块的服务提供硬件资源。服务平台会维持每个服务模块的最小个数,保证正常的调用需求。

服务弹性部署能更好的利用现有硬件资源,满足平台用户的使用要求,保证平台服务的正常使用,动态调节资源,各尽其能,按需分配,最大程度的利用好平台资源。

5 平台性能指标评测

性能Performance用来评测完成服务请求的速度,用响应时间作为度量指标,该平台使用集群调度也使得页面响应速度等更加提升。根据项目需要,通过使用Load Runner(业界公认的工业级标准性能测试负载测试工具),对该平台的并发和页面响应时间进行了性能测试。录制查询操作脚本,设置应用场景,得到以下性能评测结果:

系统支持并发访问500个(图7) :加载500并发用户操作运行11分41秒,系统没有失败和错误的事务,正确执行了7,777次操作。

系统响应客户端的请求时间小于3秒(图8) :根据一般机构设置梯度,加载50并发用户对万条记录的搜索查询操作,运行12分31秒,平均响应时间为0.025秒。

系统的性能和硬件环境相关,上述结果证明,该平台支持500用户在线操作,页面响应时间小于参考值。

6 总结与展望

本文介绍了一种分布式集群框架服务平台,它提供平台级服务,通过ESB消息总线进行交互,可扩展性强,能够在其上发布多种业务应用或服务产品,同时又能够做到图形化监控、错误告警和可管理资源的远程配置,很好的充当了基础资源和上层业务应用的桥梁和纽带。随着所集成的业务应用子系统数目增多,该平台的负载均衡技术、失效转移技术和集群技术等特性效果就更加突出,各子系统通过使用平台封装好的各种服务接口促进系统间的信息共享和资源整合,形成一体化平台。进而可以灵活地扩展至丰富的应用,具有更加广阔的推广前景,这也将是信息化系统集成和发展的必然趋势。